Server Quality Checklist

Tool Scores

• ncloud_cdss_upgrade_precheckC
  2.3/5.0
  Behavior1/5

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

  Annotations are empty, so the description carries full responsibility for behavioral disclosure. It only says 'pre-check' without explaining what is validated, whether it is read-only, any required permissions, or how results are returned.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single short sentence, making it concise. However, it is under-specification rather than effectively informative, as it provides minimal detail beyond the tool name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and no behavioral details, the description is incomplete for a 3-parameter tool. It does not explain what the pre-check returns, what a successful check looks like, or how it relates to the upgrade workflow.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (all three parameters have descriptions in the schema). The description adds no extra parameter context, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool performs a pre-check before upgrading Kafka version, which is a clear verb+resource. However, it is vague about what the pre-check involves and does not distinguish from related precheck tools like ncloud_cdss_rolling_restart_precheck.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. It does not mention that it should be run before ncloud_cdss_upgrade_version, nor any exclusions or prerequisites.

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

• ncloud_run_pipelineC
  2.6/5.0
  Behavior1/5

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

  With no annotations present, the description carries full responsibility for behavioral disclosure. It only says 'Execute a SourcePipeline pipeline' – it does not indicate whether the operation is synchronous, whether it returns a run ID, whether it is idempotent, or any side effects (e.g., creating history entries). This is essentially a tautology of the tool name, offering no behavioral transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise at only four words, with no fluff or redundancy. It front-loads the action and resource. However, it is so terse that it sacrifices necessary detail, but for what it contains, every word earns its place. A longer description would be needed to improve other dimensions, but this is appropriately sized for the minimal information given.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is an execution/mutation operation with no output schema and no annotations to clarify behavior. The description does not explain the execution semantics, what happens after running, how to check results, or any potential side effects. Given that sibling tools like list_pipeline_history and cancel_pipeline exist, the description should at least reference related operations. This is completely inadequate for a tool that triggers a pipeline.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, and the parameter 'projectId' is described as 'Pipeline ID to run'. Since the schema already fully documents the parameter, the description does not need to add much. The tool description adds no extra parameter meaning, but the baseline is 3 due to high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Execute') on a specific resource ('a SourcePipeline pipeline'). This distinguishes it from sibling tools like create_pipeline, update_pipeline, delete_pipeline, and cancel_pipeline, as 'execute/run' is a distinct operation. However, it lacks any detail about what execution entails (e.g., triggering a build or deployment), so it's not maximally explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or how this relates to cancel_pipeline or list_pipeline_history. The verb 'Execute' implies triggering a run, but there is no explicit 'use this to...' or 'instead of...' guidance.

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

• ncloud_sourcedeploy_edit_scenarioC
  2.6/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries the full burden of disclosing behavioral traits. 'Edit deployment scenario settings' says nothing about side effects, required permissions, reversibility, or what changes are applied. For a mutation tool, this is a significant gap in transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no wasted words. It is front-loaded and easy to parse, but its brevity borders on under-specification. Still, it does not repeat schema information or include fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 4 required parameters, a nested config object, and no output schema, the description must compensate by explaining what the configuration should contain and what the tool returns. It provides none of that. The tool edits scenario settings, but the nature of the settings, validation rules, or effects are unaddressed, making the description insufficient for a complex mutation tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all four parameters, so the baseline is 3. The description itself adds no parameter semantics; the schema's descriptions like 'Updated scenario configuration' and 'ID of the deployment stage' are the only sources of meaning. The config object's structure is left as additionalProperties without explanation, but the schema already covers it minimally.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Edit deployment scenario settings' is a verb+resource statement, but it is vague about what 'settings' entails and does not distinguish this tool from siblings like ncloud_sourcedeploy_edit_stage. It essentially restates the tool name with only the word 'settings' added, offering no scope or specifics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives such as create_scenario, delete_scenario, or get_scenario. The description gives no context, prerequisites, or exclusions, leaving the agent without decision-making information.

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

• ncloud_export_logsC
  2.7/5.0
  Behavior1/5

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

  The description says 'Export searched logs' which implies a write operation to Object Storage, but the annotations declare readOnlyHint=true. This is a direct contradiction. Additionally, the description fails to disclose important behavior such as whether the export is asynchronous, overwrites existing objects, or requires specific permissions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is easy to parse. It is appropriately short but lacks any structural elements like examples or context blocks, making it functional but not exemplary.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that this tool has 7 parameters, no output schema, and performs a side-effecting export, the description is incomplete. It doesn't explain how search criteria are supplied, what the timestamps should look like, or what the result of the export is. It also doesn't reference related tools for export history or bucket listing, leaving significant gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter already has a basic description. The tool description adds no additional semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Export searched logs') and a destination ('Object Storage bucket'), which clearly identifies the tool's purpose. However, 'searched logs' is somewhat ambiguous and doesn't fully distinguish it from related log tools like ncloud_search_logs or ncloud_get_log_export_history.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention that it works with the search parameters described in the schema or how it relates to ncloud_search_logs and ncloud_list_export_buckets, leaving the agent without clear direction.

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

• ncloud_ses_run_importC
  2.7/5.0
  Behavior1/5

  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 merely states the action 'Run data import' without revealing side effects, such as whether existing data is overwritten, if the operation is asynchronous, or if the index must already exist. This is a significant gap for a mutation-like operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 12 words that front-loads the key action and resources. Every word contributes to the core meaning, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a run/mutation tool with no output schema and no annotations, yet the description is minimal. It does not mention how to check import status, whether the operation is asynchronous, expected response, or any prerequisites. Given the 4 required parameters and the potential impact on the cluster, the description is far from complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema descriptions cover 100% of parameters (e.g., 'Cluster instance number', 'Object Storage bucket name'), so the baseline is 3. The description adds context by linking the parameters to the source (Object Storage) and destination (SES cluster), but it does not enhance the meaning of individual parameters beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Run data import') with a specific source ('Object Storage') and destination ('Search Engine Service cluster'). It distinguishes from sibling tools like get_import_history and stop_import by naming the operation. However, it doesn't elaborate on what 'data import' entails, so it stops short of full specificity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description implies its purpose but does not contextualize it within the import workflow or contrast with related tools like ncloud_ses_get_import_history or ncloud_ses_stop_import.

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

• ncloud_functions_get_action_activationsC
  2.8/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the readOnlyHint annotation, such as pagination defaults, max page size, ordering of results, or platform dependency. It does not contradict the read-only annotation, but it fails to disclose any additional behavioral traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one succinct sentence with no filler words. It clearly communicates the core function in eight words, earning a high score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the presence of multiple similar sibling tools and the absence of an output schema, the description is too sparse to fully orient an agent. It does not explain what data is returned, default time window, pagination behavior, or how it differs from get_activations and get_trigger_activations, leaving a significant gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage, the schema already documents all 7 parameters thoroughly. The description adds no extra meaning to the parameters, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get activation (execution) history for a specific action' clearly identifies the verb (get), resource (activation history), and scope (specific action). It distinguishes from sibling tools like ncloud_functions_get_action_activation_detail by focusing on history rather than a single activation, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool instead of the related ncloud_functions_get_activations, ncloud_functions_get_trigger_activations, or ncloud_functions_get_action_activation_detail. The description lacks context about prerequisites, time filtering behavior, or how this differs from other history endpoints.

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

• ncloud_add_network_acl_outboundC
  2.9/5.0
  Behavior2/5

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

  Annotation destructiveHint: false tells the agent this is not destructive, but the description adds no further behavioral context. It does not mention whether rules are inserted with priorities, whether duplicates are allowed, or what happens on success. The description relies entirely on the annotation for safety disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that gets straight to the point with no filler. It is appropriately sized for the tool's simple purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with 8 parameters, no output schema, and minimal annotation, the description is too sparse. It does not hint at expected response content, any ordering constraints, or typical usage prerequisites. The one-line description leaves significant contextual gaps for an agent to make informed decisions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — all 8 parameters have individual descriptions (e.g., protocolTypeCode, ruleActionCode, ipBlock). The tool description itself adds no parameter meaning, so the baseline of 3 applies as the schema carries the semantic load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Add' and the resource 'outbound rule to a Network ACL', which distinguishes it from the inbound variant at a basic level. However, it does not explicitly reference sibling tools or provide additional context about what an outbound rule entails.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool as opposed to alternatives like ncloud_add_network_acl_inbound or ncloud_remove_network_acl_outbound. Usage is only implied by the tool name and the word 'outbound'.

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

• ncloud_cdss_apply_config_groupC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate idempotentHint=true and destructiveHint=false, but the description adds no behavioral detail beyond what the annotations provide. It does not mention side effects like cluster restart, rollout behavior, or whether existing configurations are overwritten, which is critical for a config-application action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no fluff. It is concise and readable, though it could have used the space to include a bit more semantic detail without becoming verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a configuration operation that may have operational consequences, the description is too sparse. It lacks context about what applying a config group does (e.g., triggers rolling restart), any prerequisites, or expected results. With no output schema, the agent is left without important information for successful invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% description coverage for both parameters (configGroupNo and serviceGroupInstanceNo), each with clear descriptions. The tool description adds no additional parameter context, but the schema already fully documents them, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Apply a Config Group to a CDSS cluster' uses a clear verb and resource, and is distinct from sibling tools like create_config_group or delete_config_group. However, it lacks specificity about what 'apply' entails (e.g., activate, propagate) and could be slightly clearer about the scope of the operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives, such as ncloud_cdss_change_kafka_config or ncloud_cdss_create_config_group. The description only states the action without indicating prerequisites, conditions, or exclusions.

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

• ncloud_cdss_get_cluster_acgC
  2.9/5.0
  Behavior2/5

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

  The description simply restates the tool name with no additional behavioral context. The readOnlyHint annotation is present, but the description adds no extra information about pagination, return format, or permission requirements beyond what the annotation already implies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded and contains no unnecessary words. It efficiently communicates the core function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple getter with no output schema, the description is minimal and does not explain what the response contains, what ACG rules are, or any relevant details. The presence of a readOnlyHint annotation helps somewhat, but the description does not fully cover the context needed for an agent to understand the tool's behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the single parameter serviceGroupInstanceNo with a description 'Cluster instance number', giving 100% schema coverage. The tool description adds no additional meaning or context about the parameter, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource 'ACG rules for a CDSS cluster', which is specific and unambiguous. It distinguishes from similar tools like ncloud_ses_get_cluster_acg by explicitly scoping to CDSS clusters, though it does not explicitly mention alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives, no prerequisites, and no context about cluster access or configuration. The description only states what it does, leaving the agent to infer usage.

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

• ncloud_cdss_list_clustersC
  2.9/5.0
  Behavior2/5

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

  The annotation readOnlyHint=true already indicates a safe read operation, so the description does not need to restate that. However, the description adds no additional behavioral information such as pagination, response structure, or any limits. It simply restates the tool's purpose without disclosing side effects or context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence containing only necessary information. It concisely states the verb, resource, and capability without any fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  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 should explain what the tool returns (e.g., cluster summaries, paginated list). It does not. It also does not mention that results are paginated, which is implied by the pageNo and pageSize parameters. For a list tool with no output schema, the description is incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all four parameters with descriptions that already include defaults (pageNo, pageSize) and match types (exact match for vpcName, partial match for inputText). The tool description adds no additional parameter meaning beyond saying 'optional filtering', so it does not compensate beyond the schema's high coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List) and resource (Cloud Data Streaming Service (Kafka) clusters), and adds the scope 'with optional filtering'. It distinguishes from siblings by naming the specific service, though it could more explicitly differentiate from related tools like get_cluster_detail or get_cluster_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. It implies usage for listing clusters but does not mention that get_cluster_detail is for a single cluster or that this tool returns a summary list. No exclusions or alternative tool names are provided.

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

• ncloud_create_custom_resourceC
  2.9/5.0
  Behavior2/5

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

  The description only says 'Create', implying a mutation, but does not disclose side effects, required permissions, or whether resourceId is auto-generated (though this is in the schema). The annotation destructiveHint=false adds minimal safety info, but the description itself does not enrich behavioral understanding beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no wasted words, making it easy to scan. However, it is almost too sparse; a few more details could be included without losing conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create tool with four parameters, a nested object, and no output schema, this description is minimal. It lacks context about Cloud Insight's custom resource model, how this tool fits with related custom resource operations, or any expectations about resource data fields. The schema covers parameter details, but the description leaves the operational context largely unexplained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 adds no additional parameter semantics; it doesn't explain the structure of resourceData or the relationship between resourceTypeId and resourceName. The schema itself carries the parameter documentation burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Create' and the resource 'user-defined custom resource in Cloud Insight', which differentiates it from sibling tools like list/get/update/delete. However, it doesn't clarify what a 'custom resource' is or how it relates to custom schemas, leaving some ambiguity about the exact entity being created.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_create_custom_schema or ncloud_update_custom_resource. There is no mention of prerequisites (e.g., needing an existing schema) or exclusions, so the agent lacks context for selecting this tool.

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

• ncloud_create_init_scriptC
  2.9/5.0
  Behavior2/5

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

  The annotation destructiveHint=false is the only behavioral signal, and the description adds no additional context such as what the tool returns, whether it requires specific permissions, or any side effects. For a creation tool, the lack of disclosure beyond the annotation is insufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that names the verb and resource directly. It contains no unnecessary words or repetition, making it highly concise and well-structured for a simple CRUD operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool creates a resource and has four parameters, the description is too sparse. It does not mention return values, whether the operation is synchronous, or any constraints beyond what the schema already provides. The combination of description, schema, and annotations is only minimally adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all four parameters, so the baseline is 3. The description itself adds no further parameter meaning, but the schema adequately documents each parameter, including the required initScriptContent and the allowed values for osTypeCode.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create') and the resource ('init script'), matching the tool's name. It is unambiguous, but it does not explicitly differentiate from sibling tools like ncloud_list_init_scripts or ncloud_delete_init_scripts, though the name itself implies the distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, no prerequisites, and no context about whether this is the appropriate tool for a given scenario. It only states what it does, not when or why to use it.

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

• ncloud_hadoop_list_bucketsC
  2.9/5.0
  Behavior2/5

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

  With readOnlyHint=true, the agent knows this is a safe read operation. The description adds the 'available for Cloud Hadoop' scope, but does not disclose whether it returns only buckets linked to a specific instance, what happens if cloudHadoopInstanceNo is omitted, or any details about the returned data. This goes little beyond what the annotation already conveys.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no wasted words. It is front-loaded with the verb and resource, making it easy to scan and parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, so the description should compensate by explaining what is returned, but it does not. It also does not address optional parameters or behavior when no Cloud Hadoop instance is specified. While simple, it leaves important gaps for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (both parameters have descriptions: 'Region code' and 'Cloud Hadoop instance number'), so the schema carries the load. The description does not add any parameter-specific meaning beyond that, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List'), the resource ('Object Storage buckets'), and the context ('for Cloud Hadoop'). This differentiates it from generic bucket-listing tools like ncloud_list_buckets, though the scope 'available for Cloud Hadoop' is somewhat broad and could be more specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not say when to use this tool versus alternatives such as ncloud_list_buckets or ncloud_ses_get_snapshot_buckets. There is no mention of prerequisites, filtering scenarios, or when to prefer this tool over siblings. The only usage signal is the name and brief 'for Cloud Hadoop' context.

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

• ncloud_hadoop_save_hive_metastoreC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavioral traits on its own. It only states the action without revealing side effects (e.g., whether it overwrites existing configuration), validation behavior, or prerequisites. This is insufficient for a mutation operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no wasted words. It is appropriately front-loaded and easy to parse, though it could potentially add more useful context without losing conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 6 parameters and no output schema, the description is minimal. It lacks context about what 'save' entails (e.g., updating existing config, verification steps, relationship to the 'test_hive_metastore' tool), making it incomplete for an agent to know when and how to use it safely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 parameters. The description itself adds no additional parameter semantics beyond implying they relate to the Hive metastore configuration. Baseline 3 is appropriate when schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Save external Hive metastore configuration to Cloud Hadoop cluster' uses a specific verb ('save') and identifies the resource ('external Hive metastore configuration') and destination ('Cloud Hadoop cluster'). It clearly states the operation, though it does not explicitly distinguish itself from the sibling tool 'ncloud_hadoop_test_hive_metastore', which seems related.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 prerequisites, typical scenarios, or contrast with sibling tools like 'test_hive_metastore' or 'backup_config'.

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

• ncloud_issue_private_certificateC
  2.9/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries full responsibility for disclosing side effects. It only says 'Issue' which implies a creation operation, but it does not explain consequences (e.g., costs, private key storage, validity period behavior, or whether the operation is irreversible). No output schema exists, and the description offers no post-issuance behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences and 20 words, front-loading the core purpose and a key prerequisite. Every word carries meaning; there is no fluff or repetition of schema content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 16 parameters and no output schema or annotations, the description is minimal. It fails to explain what the tool returns after issuance, what the agent should do with the result, or any important behavioral context such as the effect of registPrivateKey. For such a complex operation, this is insufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all 16 parameters and their constraints. The description's mention of 'caTag' requirements adds nothing beyond the schema's own description. Per the baseline rule for high schema coverage, a score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Issue') and resource ('private SSL/TLS certificate from a Private CA'), with a specific reference to Certificate Manager (gov). It distinguishes from many sibling tools by specifying the private CA context, though it does not explicitly contrast with similar tools like ncloud_pca_issue_end_cert.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description mentions the prerequisite 'Requires a caTag from the Private CA list', which gives some context, but it provides no guidance on when to choose this tool over alternatives, nor any exclusions or conditions. With multiple cert-related sibling tools, this is a significant gap.

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

• ncloud_list_mssql_backupsC
  2.9/5.0
  Behavior2/5

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

  The description simply restates the operation 'List backups' and adds no behavioral detail such as pagination, return format, or response structure. The readOnlyHint annotation already conveys the safety profile, but the description offers no additional context beyond what the annotation implies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no filler, front-loading the action and resource. Every word earns its place, making it appropriately concise for a simple list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description fails to describe what the returned backup list contains or how it is structured. The tool has a small parameter set and a readOnly annotation, but the description still leaves the agent without information about return values or potential limitations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single required parameter cloudMssqlInstanceNo is fully described in the schema as 'Cloud MSSQL instance number', achieving 100% schema description coverage. The description adds no further semantic information about the parameter, so the high schema coverage supports a baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and identifies the resource 'backups' for a Cloud DB for MSSQL instance, clearly stating the core operation. However, it does not differentiate from the sibling tool ncloud_list_mssql_backup_details, which could create ambiguity about which backup-related listing tool to invoke.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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. There is no mention of ncloud_list_mssql_backup_details or any exclusions, prerequisites, or scenarios that would help an agent select this tool over others.

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

• ncloud_nks_get_access_entryC
  2.9/5.0
  Behavior2/5

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

  The readOnlyHint annotation already declares this a safe read operation. The description adds no additional behavioral details such as return contents, required permissions, or how to obtain the accessEntryNo. It does not contradict annotations but provides no value beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence, front-loaded with the action and resource. There is no wasted text or repetition of what annotations/schema already provide.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description should explain what the tool returns or provide context on how to get identifiers. It does neither, and it does not point to the list access entries tool for finding accessEntryNo, leaving the agent under-informed for a get operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers both parameters with descriptions ('UUID of the cluster' and 'Access entry number'), so baseline is 3. The description adds no extra parameter semantics, but the schema is sufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' with a clear resource ('IAM access entry') and scope ('for an NKS cluster'). It distinguishes from sibling list/create/update/delete tools by emphasizing 'specific', though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus list_access_entries or other access entry tools. The description simply states the action without context or exclusions.

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

• ncloud_remove_resource_from_rulesC
  2.9/5.0
  Behavior2/5

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

  Annotations already declare destructiveHint=true and idempotentHint=true. The description only restates destructiveness with a warning emoji, adding no context about the scope of removal (e.g., whether it removes the target from all rules or a specific rule), side effects, or the requirement for confirm. It does not contradict annotations, but it also fails to add behavioral value beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with a front-loaded destructive warning. It is appropriately sized, contains no redundant information, and clearly earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive operation with no output schema, the description omits the scope of the removal (affects all rules?), the mandatory confirm parameter (only in schema), and any post-conditions or effect on remaining rules. Annotations cover safety but not operational completeness, leaving the agent with insufficient understanding of the tool's full impact.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 prodKey, resourceId, and confirm. The description adds no additional parameter meaning, such as how prodKey relates to Cloud Insight or the exact format of resourceId. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Remove') and the resource ('a specific monitoring target') within the domain ('Cloud Insight event rules'). It distinguishes from sibling removal tools by specifying the Cloud Insight context, though 'monitoring target' could be more explicit about what entity it refers to.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, no prerequisites, and no exclusions. The destructive warning implies caution but does not help the agent decide between this and related tools like ncloud_delete_rule_group or ncloud_remove_* variants.

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

• ncloud_search_eventsC
  2.9/5.0
  Behavior2/5

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

  The description adds minimal behavioral context beyond the readOnlyHint annotation. It does not disclose pagination behavior, default page size, time range constraints, return format, or any other side effects or operational nuances. The phrase 'with filtering options' is generic and does not provide practical insight into how the tool behaves.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that efficiently conveys the core purpose. It is front-loaded with the action and resource, and every word contributes to the meaning. There is no fluff or repetition of schema details, making it appropriately sized for a tool description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 7 parameters, required startTime/endTime, no output schema, and only a readOnlyHint annotation, the description is too sparse. It does not mention required time range, pagination, event severity levels, or any operational context. The schema covers parameter names but not the overall behavior or constraints (e.g., maximum date range, how filtering options combine). The description fails to fill in these gaps, leaving the tool under-specified for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides complete descriptions for all 7 parameters with 100% coverage, so the baseline is 3. The description's mention of 'filtering options' is redundant and does not add any extra meaning beyond the schema. It does not clarify parameter interactions, default values beyond what the schema states (e.g., pageNum default 1, pageSize default 20), or value formats, but the schema already handles these adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's function: 'Search and get monitoring events from Cloud Insight with filtering options.' It specifies a verb ('search and get'), a resource ('monitoring events'), and a source ('Cloud Insight'). It does not explicitly distinguish from sibling tools like ncloud_search_event_by_id or ncloud_search_event_count, but the plural 'events' and the mention of filtering implies a list operation, making it reasonably distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or comparisons to sibling tools like ncloud_search_event_by_id, ncloud_search_event_count, or the various ncloud_list_*_events tools. The description simply states the action without contextualizing it.

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

• ncloud_search_logsC
  2.9/5.0
  Behavior2/5

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

  The description only restates the action 'search' which is consistent with the readOnlyHint annotation, but adds no extra behavioral context such as search scope, default time windows, or pagination behavior. The annotation already covers safety, so the description contributes little beyond the tool name.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no filler or redundant information. It is appropriately front-loaded, offering the core purpose immediately, though it could benefit from a few more details without becoming verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 8 parameters, no output schema, and minimal description, the tool is under-documented. The description does not explain return values, pagination results, or any limitations on what logs can be searched, leaving the agent without essential information to correctly invoke and interpret the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema coverage is 100%, with every parameter having a description including defaults (pageNo, pageSize), examples (interval '5m/1h/1d'), and allowed values (regionCode 'kr, krs'). The description itself adds no parameter detail, but the schema fully documents the parameters, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Search') and the resource ('collected logs in Cloud Log Analytics'). It distinguishes this from many sibling tools by focusing on searching logs rather than exporting, counting, or listing them, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like ncloud_export_logs, ncloud_get_log_count_total, or ncloud_search_events. Given the large set of related log and event tools, this lack of direction leaves the agent to guess which tool fits the task.

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

• ncloud_ses_change_node_specC
  2.9/5.0
  Behavior2/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false, but the description adds no behavioral context beyond what the tool name conveys. It does not disclose whether this is a long-running operation, if nodes are restarted, or if there is any service impact. The description is not contradictory but provides no extra value over 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the action and resource. It contains no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite a complete schema and useful annotations, the description is too terse for a change operation on a cluster. It does not mention the need for node instance numbers or product codes, nor does it indicate whether the operation is asynchronous or what the outcome/return value looks like. Given no output schema, the description should provide more operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of the three parameters with clear descriptions for each. The description adds no additional meaning beyond what already exists in the schema, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Change server specifications') and the resource ('nodes in a Search Engine Service cluster'). It is specific enough to distinguish from sibling tools like ncloud_ses_change_disk_size or ncloud_ses_change_node_type, though it does not explicitly differentiate 'specifications' from 'type'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_ses_change_node_type or ncloud_ses_change_disk_size. There are no prerequisites mentioned (e.g., retrieving product codes via ncloud_ses_get_node_products) and no exclusions or conditional scenarios.

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

• ncloud_ses_change_node_typeC
  2.9/5.0
  Behavior2/5

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

  Annotations declare idempotentHint=true and destructiveHint=false, but the description adds no context about side effects such as potential rolling restarts, cluster downtime, cost changes, or whether the operation is synchronous. It also doesn't describe the response format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence (13 words) that directly states the core purpose without any filler or redundancy. It is perfectly front-loaded and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a mutation operation on a cluster with potential operational impact, but the description lacks usage guidance, side-effect disclosure, and output expectations. It doesn't differentiate from sibling tools or mention the response, making it incomplete for an agent to invoke confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides descriptions for all three parameters (serviceGroupInstanceNo, hotDataNodeCount, warmDataNodeCount), achieving 100% coverage. The description merely mentions 'Hot/Warm' which aligns with parameter names but doesn't add extra semantics like relationships or constraints beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Change' and the resource 'data node type (Hot/Warm)' for a Search Engine Service cluster. It specifies the type values (Hot/Warm) which distinguishes it from generic node operations, though it doesn't explicitly differentiate from the sibling ncloud_ses_change_node_spec.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 like ncloud_ses_change_node_spec or ncloud_ses_add_node. There is no mention of prerequisites, cluster state requirements, or conditions under which this operation is appropriate.

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

• ncloud_ses_get_monitoringC
  2.9/5.0
  Behavior2/5

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

  The readOnlyHint annotation already indicates a safe read operation, and the description adds the cluster/node scope. However, it provides no details about response format, date-range behavior, or why 'node' is mentioned when the schema lacks a node parameter. This creates potential ambiguity without enrichment 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler words. It is concise but somewhat under-specified; the 'or node' phrase adds scope without explaining how that scope is selected.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and only a minimal description, the agent lacks information about return values, time-range handling, or how this monitoring data differs from OS-level monitoring. Given the rich sibling context, this is insufficient for confident invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions (endDateTime, startDateTime, serviceGroupInstanceNo). The tool description adds no parameter-level meaning, so it neither improves nor harms the schema's clarity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource 'monitoring data for a Search Engine Service cluster or node'. It identifies the general purpose but does not explicitly differentiate from closely related siblings like ncloud_ses_get_os_monitoring or ncloud_cdss_get_monitoring.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus the many sibling monitoring tools (e.g., ncloud_ses_get_os_monitoring, ncloud_query_monitoring_data). There are no usage contexts, prerequisites, or exclusions.

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

• ncloud_ses_upgrade_versionC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions 'upgrade' implying mutation, but it fails to state any side effects, destructive potential, required permissions, or whether the operation is safe to repeat. Minimal transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, front-loaded with the verb and resource. There is zero wasted content, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutating operation with no output schema and no annotations, the description is thin. It lacks context about how to obtain the target version code, whether a precheck is recommended, and what the upgrade entails. More context is needed for an agent to safely invoke this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of the parameters with clear descriptions ('Cluster instance number', 'Target version code'), so the schema does the heavy lifting. The description adds nothing about how to find valid version codes or the relationship between parameters, which is acceptable but not enhanced.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear action ('Upgrade Search Engine version') and the target resource ('a cluster'). It's specific enough to distinguish from other SES tools like precheck or progress, though it doesn't explicitly differentiate from similar upgrade tools on other services.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool vs alternatives, no prerequisites, and no mention of preconditions like running precheck or checking progress. The description is purely a one-liner without context.

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

• ncloud_set_nas_volume_access_controlC
  2.9/5.0
  Behavior2/5

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

  Annotations (idempotentHint=true, destructiveHint=false) are consistent with the description, but the description adds no extra behavioral context. It does not disclose whether this overwrites the entire access control list, what happens to existing rules, or any side effects. Given the 'set' semantics, this is a significant omission.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with a clarifying parenthetical. It is front-loaded and contains no fluff or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no output schema and optional parameters, the description is too brief. It fails to explain the full replacement behavior, usage context, or expected response. The existence of sibling add/remove tools makes the 'set' semantics ambiguous without further explanation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so each parameter already has a description. The description's phrase 'server-based or custom IP-based' maps to the two list parameters but adds minimal extra meaning. It does not clarify whether at least one list is required or if both can be combined, which would be valuable given neither is explicitly required.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Set') and the resource ('NAS volume instance'), and distinguishes the two access control types (server-based or custom IP-based). However, it does not explicitly differentiate from sibling tools like ncloud_add_nas_volume_access_control or ncloud_remove_nas_volume_access_control, leaving the 'set' vs 'add/remove' ambiguity unresolved.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 compared to the add/remove variants. There is no mention of whether this replaces existing rules, whether both lists can be used together, or any prerequisites or conditions. The agent is left to infer usage from the tool name and sibling tools.

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

• ncloud_sourcebuild_list_branchesC
  2.9/5.0
  Behavior2/5

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

  Annotations declare readOnlyHint=true, but the description adds no behavioral context such as return format, pagination, rate limits, or additional constraints. It merely restates the action and resource, providing no value beyond what the annotation already indicates.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, succinct sentence that immediately conveys the tool's purpose. It contains no redundant information and is appropriately sized for a simple, one-parameter read-only operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description should explain what the response contains (e.g., a list of branch names or objects). It does not, and it also fails to clarify the SourceBuild-specific context or differentiate from sibling tools. The minimal description is incomplete for an agent to fully understand the tool's behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers the sole repositoryName parameter with a helpful description ('Repository name (from list_repositories)'), achieving 100% schema description coverage. The tool description adds no additional parameter semantics, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List) and resource (branches of a SourceCommit repository), with a specific verb and object. However, it does not distinguish this SourceBuild-specific tool from the sibling ncloud_sourcecommit_list_branches, which likely serves the same core function, so it misses the full 5 for sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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. Sibling tools like ncloud_sourcecommit_list_branches and ncloud_sourcedeploy_get_sourcecommit_branches offer similar branch-listing capabilities, but no context or exclusions are given, leaving the agent without decision support.

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

• ncloud_sourcecommit_edit_repoC
  2.9/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries the full burden of behavioral disclosure. The term 'Edit' implies a mutation, but the description does not mention side effects, permission requirements, whether unspecified settings are preserved, or any output/return behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant phrases. It is concise, though arguably too terse for a mutation tool with several parameters and a sibling tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no annotations and no output schema, yet the description does not explain that it operates by repository name (vs. ID), how the boolean integration parameters affect behavior, or what happens to unspecified settings. It is incomplete for a mutation operation with multiple parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already described. The description adds little beyond echoing schema fields ('description, service integrations'), so it provides no substantial extra meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource ('Edit SourceCommit repository settings') and lists the editable fields ('description, service integrations'). It is clear but does not distinguish from the sibling tool ncloud_sourcecommit_edit_repo_by_id, which is similarly named and could cause ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as edit_repo_by_id. The description does not mention any prerequisites, exclusions, or conditions for selecting this tool over others.

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

• ncloud_sourcecommit_edit_repo_by_idC
  2.9/5.0
  Behavior2/5

  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 merely states the edit action without explaining whether updates are partial or full, whether permissions are required, or how unspecified fields are handled. This is a significant gap for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that directly states the action and target. It is concise with no unnecessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is inadequate for a mutation tool with no annotations or output schema. It omits critical behavioral details, such as whether unspecified settings are preserved, and provides no usage context or comparison with sibling tools. An agent would struggle to anticipate the tool's full effects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides descriptions for all parameters, so the baseline is 3. The description's mention of 'description, service integrations' aligns with the schema but adds no new semantics beyond what the schema already documents.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool edits SourceCommit repository settings by ID, and lists the specific settings (description, service integrations). The 'by ID' phrasing helps distinguish it from the name-based sibling edit_repo, though it doesn't explicitly compare them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus ncloud_sourcecommit_edit_repo or other alternatives. The 'by ID' implication is the only hint, but there is no explicit context or exclusions.

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

• ncloud_sourcedeploy_edit_stageC
  2.9/5.0
  Behavior2/5

  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 states the tool 'Edits' (implying mutation) but does not disclose whether omitted fields are preserved, how the 'config' object is merged or replaced, permissions required, or what the response contains. As a mutation 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence: 'Edit deployment stage settings (name, type, or config)'. No redundant words, front-loaded with the action and entity, and every token earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the presence of a nested 'config' object with arbitrary properties, no output schema, and no annotations, the description is too sparse. It does not clarify how the 'config' parameter interacts with existing settings, whether edits are incremental or replace the entire stage, or what result to expect. This leaves the agent without enough context to confidently invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already documents all five parameters. The description adds nothing beyond listing 'name, type, or config', which is already in the schema. It does not explain the nested 'config' structure or relationships between parameters, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Edit') and the resource ('deployment stage settings'), and explicitly lists the editable fields (name, type, config). This distinguishes it from sibling tools like create_stage and delete_stage, though it does not explicitly mention the required scoping IDs (projectId, stageId) which are only in the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, such as create_stage or get_stage. There are no stated prerequisites, exclusions, or mention of partial update behavior. The context is only implied by the verb 'Edit'.

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

• ncloud_sourcedeploy_get_deploy_history_detailC
  2.9/5.0
  Behavior2/5

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

  The readOnlyHint annotation correctly indicates a read operation, and the description does not contradict it. However, the description adds no behavioral context beyond the annotation—no mention of return format, potential errors, or what 'detailed' entails.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple read operation, though it lacks informative detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description does not explain what 'detailed information' includes, leaving the agent uncertain about the response structure. The tool is simple, but complete guidance is missing for a detail endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters (projectId, historyId) described in the schema. The description adds no extra semantic value, but the baseline for full schema coverage is 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('Get') and resource ('detailed information about a specific deployment history entry'). It distinguishes from the sibling list tool by emphasizing 'specific' and 'detailed', though it does not explicitly name the alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus ncloud_sourcedeploy_get_deploy_history or other siblings. There are no stated prerequisites, exclusions, or context for choosing this tool.

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

• ncloud_sourcedeploy_request_deploy_approvalC
  2.9/5.0
  Behavior2/5

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

  Annotations only declare destructiveHint=false, and the description adds no additional behavioral context. It does not explain whether the action is asynchronous, whether it creates a pending approval record, what permissions are required, or what effects it has on the deployment process. The sparse description leaves the agent to infer implementation details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, minimally sized sentence that immediately states the action and resource. It is front-loaded with the key verb and object, containing no filler or redundant phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With three required parameters and no output schema, the description is too minimal to fully contextualize the tool. It does not clarify the relationship to 'approve_deploy' or 'start_deploy', nor does it mention the approval workflow context or what happens after the request is made. This leaves significant gaps for an agent deciding when to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions for all three parameters (projectId, stageId, scenarioId) are present and clear, giving 100% coverage. The tool description itself adds no extra parameter-level meaning, but the baseline of 3 applies when the schema fully documents parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Request approval') on a specific resource ('a scenario deployment'), which distinguishes it from the sibling tool 'approve_deploy' by emphasizing the request step rather than the approval action itself. However, it could more explicitly contrast with related deployment tools to eliminate ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as 'ncloud_sourcedeploy_approve_deploy' or 'ncloud_sourcedeploy_start_deploy'. The description does not mention lifecycle context, prerequisites, or differentiation from other sourcedeploy operations.

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

• ncloud_sourcedeploy_start_deployC
  2.9/5.0
  Behavior2/5

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

  Annotations declare idempotentHint=true and destructiveHint=false, which covers safety. However, the description adds no additional behavioral context such as whether the deployment starts synchronously, creates a deployment record, or can be invoked while another deployment is in progress. It does not contradict annotations, but it fails to enrich the agent's understanding of the operation's effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no fluff. It is very concise and easy to parse. The phrase 'for a specific scenario' is slightly redundant given the 'scenarioId' parameter, but overall it is appropriately sized for the minimal content it provides.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a deployment-initiating action with 3 required parameters and no output schema, the description is too thin. It does not explain the overall workflow, such as whether approval steps are needed, how to track the deployment after starting, or what side effects to expect. The sibling tools suggest a complex lifecycle, but this description leaves the agent without enough context to confidently use the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with clear descriptions for projectId, stageId, and scenarioId. The description itself does not add any parameter-specific meaning, but the schema already documents all parameters adequately. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Start a deployment for a specific scenario.' It uses a specific verb and resource, and the scope is clear enough. However, it does not explicitly differentiate from sibling tools like cancel_deploy or approve_deploy, though the verb 'start' is distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 vs alternatives. It does not mention prerequisites (e.g., scenario must exist), whether approval is required, or how this relates to other deployment lifecycle tools. The context signals and sibling list suggest a workflow, but the description itself gives no usage direction.

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

• ncloud_export_mongodb_backupB
  3/5.0
  Behavior1/5

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

  The description states 'Export MongoDB backup files to Object Storage,' which implies writing files to Object Storage—a side effect. However, annotations declare readOnlyHint: true, creating a direct contradiction. No additional behavioral traits such as asynchronous execution or permission requirements are disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that directly conveys the tool's purpose with no extraneous content. It is efficiently front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is minimal and omits critical operational context, such as whether the export is asynchronous, how to monitor progress, required permissions, or what the API response contains. The contradiction between the description's implied side effect and readOnlyHint further complicates the agent's understanding of the tool's behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are fully documented in the schema. The description does not add extra meaning about parameters beyond what the schema already provides, which is the baseline for this dimension.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Export') and clearly identifies the resource ('MongoDB backup files') and destination ('Object Storage'). It distinguishes the tool from siblings like ncloud_export_mongodb_log and ncloud_export_mysql_backup by focusing on MongoDB backups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 compared to alternatives. It does not mention prerequisites, exclusions, or why one might choose export over other MongoDB operations. There is no contextual information about when this operation is appropriate.

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

• ncloud_export_mongodb_logB
  3/5.0
  Behavior1/5

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

  The annotations declare readOnlyHint=true, but the description states the tool exports logs to Object Storage, which creates new objects and implies a write side effect. This contradicts the read-only hint, as the operation modifies the destination bucket state.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action and destination. No unnecessary words or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 5 parameters and no output schema, but the description provides no context about return values, asynchronous behavior, or required permissions. It is too minimal to fully inform an agent about the operation's lifecycle.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter described (e.g., bucketName, folderPath, cloudMongoDbInstanceNo). The description adds no additional parameter semantics, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Export' with a clear resource ('MongoDB server logs') and destination ('Object Storage'). This clearly distinguishes it from siblings like ncloud_export_mongodb_backup and ncloud_list_mongodb_logs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or related tools, leaving the agent to infer usage from the name alone.

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

• ncloud_sourcedeploy_reject_canaryB
  3/5.0
  Behavior1/5

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

  Annotations are empty, so the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects, whether the rejection is irreversible, required permissions, or what happens after rejection. No such context is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no redundant words. It is front-loaded and efficiently conveys the core action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of annotations and output schema, the description is too terse to provide complete operational context. It does not explain the canary deployment lifecycle, expected outcomes, or prerequisites, leaving the agent with incomplete information.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 required parameters (projectId, stageId, scenarioId). The description adds no extra parameter-specific meaning, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Reject') and a clear resource ('manually analyzed canary version deployment'), which distinguishes it from sibling tools like approve_canary and reject_deploy. It unambiguously states what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives like approve_canary or reject_deploy. The word 'manually analyzed' implies a particular workflow phase, but no exclusions or alternative tool references are given.

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

• ncloud_add_nas_volume_access_controlB
  3.1/5.0
  Behavior2/5

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

  The annotations only include destructiveHint: false, and the description adds only the 'NFS protocol' context. It does not disclose whether the operation is additive/overwriting, whether it requires special permissions, or what side effects it may have on existing access rules. With minimal annotation coverage, the description carries a heavier burden that it does not meet.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the action verb and resource. There is no unnecessary information, making it efficient and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter operation with full schema coverage, the description is mostly adequate. However, it lacks guidance on usage context and behavioral details (e.g., whether this appends to existing rules, whether it's idempotent). These gaps make it only minimally complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters well-described in the schema ('NAS volume instance number' and 'List of server instance numbers to grant access'). The description text adds no additional parameter meaning beyond the schema, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Add') and the resource ('server instance access control to a NAS volume'), and specifies the protocol (NFS). However, it does not explicitly distinguish itself from the sibling tool 'ncloud_set_nas_volume_access_control', so it falls 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.

  Usage Guidelines2/5

  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 such as 'set_nas_volume_access_control' or 'remove_nas_volume_access_control'. It does not mention any preconditions, limitations, or context for when this operation is appropriate.

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

• ncloud_cdnplus_request_purgeB
  3.1/5.0
  Behavior1/5

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

  The description explicitly calls the operation 'purge (invalidation),' which contradicts the annotation destructiveHint=false. This is a clear inconsistency, and the description fails to disclose the destructive nature of the operation beyond the schema. The annotation contradiction undermines trust.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, with two focused sentences that front-load the core action and scope. Every word contributes to the purpose, making it efficient and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 100% schema coverage and lack of output schema, the description is minimally adequate for parameter understanding. However, the contradiction between the description and the destructiveHint annotation creates a significant gap in behavioral context, making it incomplete for safe usage. More explanation of side effects or confirmation steps would be needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 parameters. The description adds minimal context by mentioning 'isWholeDomain/isWholePurge select scope,' which marginally clarifies the boolean flags but does not explain relationships between parameters (e.g., domainIdList vs isWholeDomain). This fits the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Request a CDN+ cache purge (invalidation)' with specific scope options ('whole content or specific files/directory'). It distinguishes from siblings by naming CDN+, differentiating it from Global CDN purge tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives some context (CDN+ purge, whole or specific scope) but does not provide explicit guidance on when to use this tool versus alternatives like ncloud_globalcdn_request_purge. No exclusions or alternative recommendations are mentioned.

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

• ncloud_cdss_add_nodesB
  3.1/5.0
  Behavior2/5

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

  Annotations only include destructiveHint: false, so the description must disclose behavioral traits. It does not mention whether the operation is asynchronous, has side effects, requires permissions, or is reversible. The description only states the action without any context about how it behaves.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one short sentence with no fluff, making it efficient and front-loaded. However, it is under-specified, but that is more a completeness issue than a conciseness issue.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that this is a mutating operation on a cluster and there is no output schema, the description is incomplete. It does not explain what a CDSS cluster is, any prerequisites, potential impacts, or operation semantics. The agent lacks enough context to use it confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters (newBrokerNodeCount, serviceGroupInstanceNo) already documented in the input schema. The description adds no additional parameter semantics, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Add') and resource ('broker nodes to a CDSS cluster'), clearly distinguishing it from sibling tools like ncloud_cdss_change_node_spec (which modifies existing nodes) and ncloud_ses_add_node (for a different service). It is unambiguous about the action being performed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, no prerequisites (e.g., cluster must exist), and no exclusions or caveats. It is a bare statement of the action, leaving the agent to infer context.

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

• ncloud_change_fabric_cluster_descriptionB
  3.1/5.0
  Behavior2/5

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

  The description simply says 'Change a fabric cluster's description' and adds no behavioral context beyond what the annotations (idempotentHint, destructiveHint) already indicate. It does not mention the optional clear behavior or byte limit, though these are present in the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no extraneous words, making it highly concise and appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is minimal but sufficient for a simple mutation tool given the rich schema and annotations. It could mention that the description is optional and clearing, but that is already in the schema. Overall, it is adequate but lacks contextual depth.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with fabricClusterNo and fabricClusterDescription already described. The description adds no additional parameter semantics, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (change) and resource (fabric cluster's description), distinguishing it from sibling tools like ncloud_change_fabric_cluster_name. However, it adds little beyond the tool name itself and lacks explicit scope or alternative references.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, such as ncloud_change_fabric_cluster_name for name updates. It does not mention any prerequisites, exclusions, or context for when this tool is appropriate.

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

• ncloud_change_fabric_cluster_serversB
  3.1/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, which cover the core safety profile. The description adds no further behavioral context, such as whether the operation replaces the entire server list, performs an incremental update, or has side effects. It essentially restates the tool's purpose without elaborating on consequences.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no wasted words. It is appropriately front-loaded and easy to scan. However, it could have used a second sentence to add usage or behavior context without losing its tight structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no output schema and only minimal annotations, the description is incomplete. It does not explain whether the server list is replaced wholesale or merged, nor does it describe the return value or any constraints. This leaves the agent uncertain about critical operational semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions, so the schema carries the semantic load. The description adds no additional parameter information. Baseline of 3 is appropriate given the strong schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Change') and the resource ('server instances assigned to a fabric cluster'). It is specific enough to distinguish from sibling tools like change_fabric_cluster_name and change_fabric_cluster_description, which target different aspects of a fabric cluster.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. While the tool name and sibling context imply it is the appropriate tool for changing server assignments, the description itself lacks any usage direction.

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

• ncloud_change_postgresql_usersB
  3.1/5.0
  Behavior2/5

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

  The description simply restates the operation without adding behavioral context beyond the annotations. Annotations already declare idempotentHint and destructiveHint, but the description adds no practical details such as whether changing a password affects active connections, requires admin rights, or fails for nonexistent users.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core purpose without padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with annotations and a complete schema, the description is minimally viable but leaves gaps. It doesn't mention that this tool only modifies existing users or that the instance number can be obtained via listing tools, so an agent may not have full operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both cloudPostgresqlInstanceNo and cloudPostgresqlUserList clearly described. The description's phrase 'user information (password)' aligns with the password field but adds negligible extra meaning, matching the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('Change') and the resource ('user information (password) for a Cloud DB for PostgreSQL instance'), distinguishing it from sibling tools like ncloud_add_postgresql_users or ncloud_delete_postgresql_users. However, it doesn't explicitly state that it modifies existing users only, leaving slight ambiguity about scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention that adding new users should use ncloud_add_postgresql_users or that listing existing users is available via ncloud_list_postgresql_users, so the agent gets no decision support.

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

• ncloud_create_lb_listenerB
  3.1/5.0
  Behavior2/5

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

  The annotation destructiveHint=false indicates it is not destructive, but the description adds no further behavioral context. It does not mention what the operation returns (no output schema), whether it requires existing resources (load balancer, target group), or potential side effects like port conflicts. For a create operation with no output schema, the description should disclose more, resulting in a score of 2.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear, and efficient sentence with no fluff. It front-loads the core purpose. While it is very short, it is appropriately sized for a simple action statement, though it could have included more detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 8 parameters, 4 required, no output schema, and minimal annotations, the description is markedly incomplete. It fails to explain what a listener is, what parameters are essential, what the response will be, or any dependencies/constraints. The agent is left to infer most context from the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides descriptions for all 8 parameters (100% coverage), so the baseline is 3. The description itself does not add any parameter information beyond what the schema already contains, so it cannot be scored higher.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create') and the resource ('a new listener for a load balancer'), making it easy to distinguish from sibling operations that list, change, or delete listeners. However, it does not explicitly differentiate from these alternatives by stating what not to use it for, 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: it is for creating a new listener, rather than modifying (change_lb_listener_config), deleting (delete_lb_listeners), or listing (list_lb_listeners). There is no explicit mention of when to use it versus alternatives, nor any prerequisites like requiring an existing load balancer or target group, so it only provides implied context.

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

• ncloud_create_server_imageB
  3.1/5.0
  Behavior2/5

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

  The annotations only include destructiveHint=false. The description does not disclose any additional behavioral traits such as permissions required, whether the server is affected, asynchronous nature, or side effects. It adds no context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no extraneous information. It clearly conveys the core function in ten words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple create operation with schema-covered parameters, the description is minimally sufficient. However, there is no output schema and no mention of return values, prerequisites, or potential side effects, and it does not differentiate from similar create-image tools, leaving some contextual gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for all three parameters. The description does not add any extra parameter details or clarify relationships, but the schema already documents them, so baseline score is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Create) and resource (server image) from a source (existing server instance). It does not explicitly distinguish from sibling tools like ncloud_create_member_server_image or ncloud_create_server_image_from_snapshot, so it lacks sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No information about when to use this tool versus alternatives, any prerequisites (e.g., server instance must be stopped or running), or exclusions. The description provides no usage context beyond the basic action.

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

• ncloud_create_subnetB
  3.1/5.0
  Behavior2/5

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

  The description repeats the dryRun behavior already documented in the schema parameter. With destructiveHint=false provided in annotations, the description adds no new behavioral transparency beyond what structured data already communicates.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the primary purpose and a useful dryRun tip. 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema fully documents parameters, but the description does not mention return values, prerequisites (e.g., existing VPC, CIDR constraints), or failure behavior. For a simple create tool with rich schema, this is adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all 8 parameters (100% coverage), so the description does not need to add parameter details. The baseline of 3 applies because the schema already carries the full explanatory burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Create), the resource (subnet), and the context (in a VPC), making the tool's purpose immediately obvious. It does not explicitly contrast with sibling tools like ncloud_nks_add_subnet, but the core intent is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The only usage guidance is the dryRun tip, which explains how to preview without creating. There is no mention of when to prefer this tool over alternatives, prerequisites like an existing VPC, or scenarios where it should not be used.

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

• ncloud_delete_metrics_group_by_idB
  3.1/5.0
  Behavior2/5

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

  The description's 'Destructive' warning merely duplicates the destructiveHint annotation. It adds no additional behavioral context such as irreversibility, cascading effects on related resources, or confirmation requirements. With annotations already covering safety, the description contributes minimal extra transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that includes a warning icon and clearly states the action and key parameters. No superfluous content, making it highly efficient for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with annotations covering destructive behavior and schema covering parameters, the description is minimally adequate. However, it lacks context about related tools, the relationship between rule templates and metrics groups, and any side effects beyond the deletion itself, which limits its completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 parameters. The description's mention of 'product key and metrics group ID' aligns with the schema but adds no new semantic detail. The confirm parameter's crucial requirement ('Must be true to execute deletion') is only in the schema, not echoed in the description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Delete), the resource type (Cloud Insight rule template), and the identifying fields (product key and metrics group ID). It is specific and distinguishes itself from the basic 'delete_metrics_group' by including 'by_id', though it could more explicitly mention related force-delete variants.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided regarding when to use this tool versus alternatives like ncloud_delete_metrics_group_force or ncloud_delete_metrics_group. The description does not mention prerequisites, conditions, or exclusions, leaving the agent to infer context from the name alone.

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

• ncloud_delete_monitor_groupB
  3.1/5.0
  Behavior3/5

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

  The annotations already provide destructiveHint=true, and the description reinforces this with 'Destructive' and 'permanently remove', adding the irreversible consequence. However, it omits the confirm parameter's mandatory role and doesn't mention idempotency or any other side effects, so it adds modest context 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single declarative sentence with a warning prefix, making it efficient and front-loaded. However, the 'Destructive' warning partially duplicates the annotation, but it is still concise and clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is very brief and omits the safety confirmation requirement (confirm=true), which is critical for a destructive operation. It also doesn't mention that the operation is irreversible beyond 'permanently remove', nor does it reference the force variant, leaving the agent without key execution context despite the simple tool shape.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes both parameters (confirm must be true, monitorGroupId is the ID to delete) with 100% coverage, so the description adds no additional parameter detail. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Delete') and the resource ('Cloud Insight monitoring target group'), adding that removal is permanent. It differentiates from read/create/update tools but not from the sibling ncloud_delete_monitor_group_force, so it falls slightly short of full differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given for when to use this tool versus alternatives such as ncloud_delete_monitor_group_force or when not to use it. The description only warns of destructiveness without explaining the confirm parameter or any preconditions, leaving the agent without selection criteria.

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

• ncloud_dns_get_query_countB
  3.1/5.0
  Behavior2/5

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

  The readOnlyHint annotation already signals a safe read operation, and the description's 'Get ... monitoring data' aligns with that. However, the description adds no additional behavioral context beyond the annotation—no mention of aggregation behavior, time range limits, domain filtering semantics, or what the returned data contains. With annotations present, the bar is lower, but the description still contributes minimal value beyond what the annotation and schema already convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no unnecessary words. It front-loads the verb and directly states the resource and scope. Perfectly appropriate size for the information conveyed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple with only two parameters and a readOnly annotation, but no output schema exists. The description does not indicate the return format, time range behavior, or how domainId affects the data (e.g., aggregate vs. specific domain). This leaves some ambiguity for an agent deciding whether this tool meets its needs, warranting a slightly below-average completeness score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both 'domainId' ('Filter by specific domain ID') and 'baseTimeUnit' ('Time unit for aggregation') have clear descriptions in the schema. The tool description adds no parameter-specific meaning beyond that, so it neither helps nor harms. Baseline of 3 applies because the schema fully handles parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear action ('Get') and resource ('DNS query count monitoring data') with a scope ('for Global DNS domains'). However, it does not explicitly distinguish this tool from the similar sibling ncloud_gtm_get_query_count, which also provides query count but for Global Traffic Manager. The name and phrase 'Global DNS domains' provide some differentiation, but the description alone would not clearly tell an agent when to choose one over the other.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any exclusions or prerequisites. Given the existence of ncloud_gtm_get_query_count and other DNS monitoring tools in the sibling list, explicit guidance on context or alternatives would be valuable but is entirely absent.

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

• ncloud_drm_get_policy_logsB
  3.1/5.0
  Behavior2/5

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

  The readOnlyHint=true annotation aligns with the 'Get' operation, but the description adds no additional behavioral context such as pagination behavior, time range handling, or event log format. It merely restates the operation, providing no value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no redundant words. It is appropriately sized for a straightforward query operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and a minimal description, the tool lacks context about return format, pagination limits, or event types. The schema covers query parameters, but for a log retrieval tool this is a meaningful gap that could confuse agents needing to interpret results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for all five parameters, so the schema handles semantic meaning. The tool description itself adds no parameter-specific information, but this is acceptable given the schema's completeness.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the resource ('event logs for a DRM policy'), making it specific and distinct from sibling tools like ncloud_drm_get_site_logs. However, it does not explicitly name alternatives or contrast itself, so it falls short of full sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus other log-related tools such as ncloud_drm_get_site_logs or ncloud_search_logs. The description is a bare statement of functionality with no context about use cases or exclusions.

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

• ncloud_functions_get_packageB
  3.1/5.0
  Behavior2/5

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

  The readOnlyHint annotation indicates a safe read operation, and the description's 'Get' aligns with that. However, the description adds no behavioral context beyond the annotation—no mention of response structure, error cases (e.g., package not found), or rate limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It conveys the action and target clearly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read operation with two documented params and readOnlyHint annotation, the description is mostly adequate. However, with no output schema, it doesn't clarify what 'detailed information' includes or what happens if the package doesn't exist.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters (platform and packageName) are fully described in the schema (100% coverage), so the description doesn't need to restate them. The description itself adds no additional parameter semantics beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') with a clear resource ('detailed information about a specific package'). It clearly indicates this tool retrieves a single package's details, though it doesn't explicitly contrast with sibling ncloud_functions_list_packages which lists packages.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like ncloud_functions_list_packages or when a package name is needed. There are no usage scenarios, prerequisites, or exclusions mentioned.

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

• ncloud_functions_invoke_triggerB
  3.1/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries the full burden of behavioral disclosure. It does not mention side effects, permissions, whether the invocation is synchronous/asynchronous, or what results are returned. 'Invoke' implies execution, but no additional behavioral context is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no unnecessary words. It is appropriately scoped for a simple tool, though it could include more substance without becoming verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although the schema covers parameters, the overall context is incomplete. There is no usage guidance, no behavioral information about side effects, and no explanation of what happens when a trigger is invoked. For an execution-type tool with no annotations, this is insufficient for an agent to confidently select and use it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 (triggerName, platform, params). The description adds no extra parameter-level semantics, leaving the baseline at 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('invoke') and resource ('Cloud Functions trigger'), clearly stating what the tool does. It distinguishes from sibling tools such as ncloud_functions_invoke_action (which invokes an action directly) and read-only trigger tools like ncloud_functions_list_triggers or ncloud_functions_get_trigger.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to use this tool versus alternatives. It does not mention that this is for manually triggering an action, nor does it compare to ncloud_functions_invoke_action or explain scenarios where a manual trigger is appropriate. The description only states the action, leaving the agent without context for selection.

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

• ncloud_get_log_count_totalB
  3.1/5.0
  Behavior2/5

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

  The readOnlyHint annotation already declares this is a safe read operation. The description adds no additional behavioral information such as whether the count is for a specific time range, whether it resets, or what constitutes 'collected'. Since it adds no context beyond the annotation, it falls below the baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler or repetition. It perfectly balances brevity with the necessary information for a simple tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple count tool with no output schema, the description is minimally adequate. However, given the closely related sibling tools (ncloud_get_log_count_recent, ncloud_get_log_count_by_period, ncloud_get_log_count_by_type), it lacks the contextual differentiation needed to avoid confusion about which count is being retrieved.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for the single optional parameter (regionCode), so the schema already explains its meaning. The description adds no parameter information, but the baseline of 3 applies because the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' and identifies the resource as 'total collected log count in Cloud Log Analytics', which is clear and distinguishes it from siblings like ncloud_get_log_count_recent or ncloud_get_log_count_by_period. However, it doesn't explicitly state how this 'total' differs from those other counts, so it's not a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives. For example, it doesn't mention that this is a global aggregate while the sibling tools filter by time or type. The agent is left to infer from the name alone.

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

• ncloud_get_server_detailB
  3.1/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the readOnlyHint annotation. It does not mention what 'detailed information' includes, potential errors, or any other operational traits. With annotations present, the bar is lower, but the description still lacks value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no unnecessary words or repetition. It earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read tool, the description is minimally adequate, but it lacks information about what the returned detail includes. With no output schema, the agent is left guessing at the response structure, so a bit more detail would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description for serverInstanceNo ('Server instance number to query') fully covers the parameter meaning, and the description adds no extra details. With 100% schema coverage, the baseline is 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get detailed information about a specific server instance' clearly states the action (get) and resource (specific server instance). It distinguishes from list_servers by implying a single instance, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like ncloud_list_servers, nor any prerequisites (e.g., needing a server instance number). The description simply states what it does without context.

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

• ncloud_gtm_get_geo_cidr_map_detailB
  3.1/5.0
  Behavior2/5

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

  The readOnlyHint annotation already conveys the safe read-only nature. The description adds only that it retrieves 'detailed information' but does not disclose what that detail includes, whether any authorization is needed, or how errors are surfaced. With annotations present, the bar is lower, but the description still adds minimal behavioral context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It conveys the essential purpose efficiently, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given one parameter, full schema coverage, and a read-only annotation, the description is minimally adequate for a simple getter. However, it does not mention the return format or how to interpret 'detailed information', and it lacks guidance on the relationship to the list tool. It is complete enough for basic selection but leaves gaps for an agent expecting a fully self-contained description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% because mapId is described as 'Map ID to query'. The tool description adds context that this map is a 'Geo or CIDR map', which clarifies the entity type, but it does not offer syntax, format, or how to obtain valid IDs. Baseline 3 applies since the schema carries the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get detailed information') and the resource ('a specific Geo or CIDR map'), which is specific and not a tautology. It distinguishes itself from the list sibling ('list_geo_cidr_maps') by emphasizing 'specific' and 'detailed', though it does not explicitly name the alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 that list_geo_cidr_maps should be used first to obtain map IDs, nor does it state any exclusions or prerequisites. The context signals show a related list tool, but the description does not leverage that.

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

• ncloud_gtm_get_policy_detailB
  3.1/5.0
  Behavior2/5

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

  The description only states it retrieves info, which aligns with the readOnlyHint=true annotation but adds no behavioral context (e.g., error behavior, return structure, or required permissions). It provides no value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence with no redundancy. It is appropriately front-loaded and contains exactly the necessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter read operation, the description is functional but omits what 'detailed information' includes. With no output schema, a bit more specificity about the returned policy details would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with policyId described as 'Policy ID to query'. The description does not add any parameter semantics, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves detailed information about a specific Global Traffic Manager policy, using a specific verb and resource. It distinguishes from list tools but doesn't explicitly contrast with the sibling get_policy_resources tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like ncloud_gtm_list_policies or ncloud_gtm_get_policy_resources. The word 'specific' implies an existing policy ID, but prerequisites or alternative scenarios are not mentioned.

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

• ncloud_gtm_update_geo_cidr_mapB
  3.1/5.0
  Behavior2/5

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

  Annotations provide idempotentHint=true and destructiveHint=false, covering the safety profile. However, the description adds no extra behavioral context, such as whether the update replaces or merges detailedMapList, whether mapType can be changed after creation, or what happens to unspecified fields. For a mutation tool, this omission is a significant gap beyond what annotations disclose.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded and free of unnecessary words. It is easy to parse and directly states the action and resource. While it could be more informative, it is appropriately sized for a simple tool description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a nested detailedMapList and a mapType enum, but the description does not explain update semantics, whether fields are required or optional, or what the outcome of a successful update is. With no output schema, the description should carry more load for behavioral expectations, but it does not. Given the moderate complexity and minimal description, it is incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters (mapId, name, mapType, detailedMapList) are already documented in the schema. The description adds no parameter-specific meaning beyond this, which is acceptable given the high schema coverage. However, it does not clarify partial-update behavior or parameter dependencies, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Update' and clearly identifies the resource as 'an existing Geo or CIDR map', which distinguishes it from sibling tools like create, delete, list, and get. However, it does not enumerate which fields can be updated, but for a single-line description it is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when modifying an existing Geo or CIDR map, but it does not explicitly state when to use this tool versus create/delete/list/get, nor does it mention any prerequisites or alternatives. Guidance is only implied by the word 'Update' and the sibling context.

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

• ncloud_gtm_update_policyB
  3.1/5.0
  Behavior2/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false, and the description adds no additional behavioral context. It does not disclose whether the update is partial (only provided fields are changed) or whether it replaces the entire policy configuration, which would be useful 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no redundant words. It is perfectly concise and front-loaded, efficiently stating the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema is rich and comprehensively describes all parameters, and annotations cover the safety profile. The description is sufficient for a basic understanding but lacks context on scope boundaries (e.g., it does not clarify that this tool handles overall policy settings, not just resources or health checks), which is important given the numerous closely related sibling tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all properties, so the schema already provides full parameter semantics. The tool description adds no extra parameter information, but given the high schema coverage, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action (update) and the resource (existing Global Traffic Manager policy). It is specific and unambiguous, but it does not differentiate from related sibling tools like ncloud_gtm_update_policy_resources or ncloud_gtm_update_policy_health_check, which also update aspects of a GTM policy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as ncloud_gtm_update_policy_resources or ncloud_gtm_update_policy_health_check. It does not mention any prerequisites, such as needing an existing policy ID, or clarify whether this is for general policy settings only.

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

• ncloud_hadoop_list_notebook_imagesB
  3.1/5.0
  Behavior2/5

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

  The readOnlyHint annotation already indicates this is a safe read operation, so the description does not need to repeat that. However, it adds no additional behavioral context such as pagination, region-scoping behavior, or relationship between 'image products' and other listing tools. The description barely goes beyond the name and annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise phrase that conveys the essential purpose without filler. Every word adds value, and it is appropriately sized for a simple list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one optional parameter, no output schema), the description is minimally adequate but leaves gaps. It does not clarify what an 'image product' is, whether regionCode is needed to scope results, or what the response format looks like. The absence of an output schema makes some return-value context desirable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% since the only parameter, regionCode, is described as 'Region code'. The description itself provides no parameter-specific details beyond what the schema already states, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List available notebook image products' clearly states the action (list) and the resource (notebook image products). It is specific enough to distinguish from generic list tools, though it does not explicitly differentiate from the closely related sibling tool ncloud_hadoop_list_notebook_products.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_hadoop_list_notebook_products or ncloud_hadoop_list_image_products. The description does not mention any exclusions, preconditions, or use cases, leaving the agent without comparative context.

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

• ncloud_hadoop_list_notebooksB
  3.1/5.0
  Behavior2/5

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

  The annotation readOnlyHint=true already signals this is a safe read operation. The description adds no further behavioral context—it does not mention filtering options, pagination behavior, return volume, or any limitations. This is a bare 'List' statement that adds no value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence ('List Cloud Hadoop notebook instances') with zero superfluous words. It efficiently captures the core action and resource, making it perfectly sized for a simple list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a straightforward list operation with no output schema. While the schema covers parameters and the readOnlyHint annotation is present, the description lacks any mention of what the response contains, whether all notebooks across clusters are returned by default, or any other operational detail. This is adequate but not complete for a tool with multiple optional filters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all five parameters (pageNo, pageSize, regionCode, cloudHadoopInstanceNo, cloudHadoopNotebookInstanceNoList) documented in the input schema. The description itself does not elaborate on parameter usage, but since the schema already does, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and identifies the resource ('Cloud Hadoop notebook instances'), clearly conveying the tool's function. However, it does not explicitly distinguish itself from sibling tools like ncloud_hadoop_get_notebook_detail or other list tools, though the resource type is precise enough to avoid major confusion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 (e.g., ncloud_hadoop_get_notebook_detail for details, or ncloud_hadoop_list_notebook_buckets for buckets). There is no mention of scenarios that favor this listing operation, leaving the agent to infer usage from the name alone.

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

• ncloud_hadoop_list_productsB
  3.1/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the readOnlyHint annotation. It doesn't describe the response format, potential filtering side effects, or how availability might vary by region or image product. The term 'available' hints at dynamic content but is not explicit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that front-loads the verb and immediately conveys the purpose. No wasted words or redundant structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with a readOnly annotation and fully described schema parameters, the description gives the essential purpose. However, without an output schema, the agent must infer what 'server types (specs)' means in terms of the returned data (e.g., codes, names, CPU/memory details). A bit more detail about the return structure would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for both parameters ('Region code' and 'Image product code filter'), so the description adds no additional parameter meaning. The description doesn't explain how these filters affect the list, but the schema already carries that burden, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and the resource ('server types (specs) for Cloud Hadoop nodes'), distinguishing it from sibling tools like ncloud_hadoop_list_image_products. However, it does not elaborate on what 'specs' includes, so it stops short of being maximally precise.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. It doesn't mention that it's useful for cluster creation or how it relates to list_image_products. The word 'available' implies a use case, but no direct when-to-use instructions are provided.

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

• ncloud_kms_get_latest_use_infoB
  3.1/5.0
  Behavior2/5

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

  The readOnlyHint annotation already indicates a safe read operation. The description adds no further behavioral context, such as what 'usage information' includes, whether it returns a single record, or if any special permissions are needed. It does not contradict the annotation, but provides no extra transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no redundant wording. It front-loads the action and resource effectively and is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, no output schema) and the readOnlyHint annotation, the description is minimally sufficient. However, it lacks details about what 'usage information' consists of, which could be critical for an agent deciding if this tool meets the user's need.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (keyTag is well described as 'unique identifier derived from key name'). The description does not add any additional meaning to the parameter beyond echoing it ('specific KMS key'), so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the resource ('most recent usage information for a specific KMS key'), which is specific and distinct from other KMS tools like get_key_info or get_key_activity_logs. It does not explicitly compare with siblings, but the resource is unique enough to avoid confusion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, such as ncloud_kms_get_key_activity_logs or ncloud_kms_get_key_info. The description only states what it does, leaving the agent to infer usage from the tool name.

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

• ncloud_list_mongodb_backup_detailsB
  3.1/5.0
  Behavior2/5

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

  The description adds little beyond the readOnlyHint annotation. It doesn't disclose response format, pagination, or any operation-specific behavior. The only extra context is 'detailed,' which is more about purpose than a behavioral trait.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence with no filler. It front-loads the verb and resource clearly, making every word earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with a single parameter and full schema coverage, the description is largely sufficient. However, it doesn't explain what 'detailed' includes or return conventions, and there's no output schema to compensate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter is fully described in the schema (cloudMongoDbInstanceNo with description). The description adds no extra parameter-level meaning, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists detailed backup information for a Cloud DB for MongoDB instance, with a specific verb and resource. The word 'detailed' hints at a distinction from the simpler backup listing sibling, but it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided. The description does not indicate when to use this tool over ncloud_list_mongodb_backups or other MongoDB tools, nor any prerequisites or intended scenarios.

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

• ncloud_list_mssql_log_backup_filesB
  3.1/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the readOnlyHint annotation. It does not mention pagination, response format, or any special restrictions. With the annotation already declaring the read-only safety profile, the description provides no additional value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that clearly names the action and resource. It is appropriately sized with no fluff or redundancy, earning a perfect score for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is minimal but sufficient for a simple listing operation given the rich schema and readOnlyHint annotation. However, it does not explain how this tool differs from related sibling tools, and with no output schema, the agent has limited expectations about the returned data.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 itself does not elaborate on parameter meaning, but the schema already documents both parameters clearly as instance numbers. No additional semantics are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List) and the resource (log backup files for a Cloud DB for MSSQL instance). It is specific but does not explicitly differentiate from sibling tools like ncloud_list_mssql_log_files or ncloud_list_mssql_backups, which are similar in purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. The description simply states what it does without indicating context, prerequisites, or exclusions, leaving the agent to infer usage from the name and schema alone.

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

• ncloud_list_pipeline_historyB
  3.1/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, and the description is consistent with that. However, the description adds no additional behavioral context such as pagination limits, default page size, or what constitutes an execution history entry. It essentially restates the name.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no unnecessary words. It efficiently communicates the core purpose without bloat.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with pagination parameters, the description is minimally adequate but lacks return value details (no output schema) and any nuances such as default page size or result ordering. It doesn't describe what the history list contains beyond the name.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for each parameter. The description adds no extra meaning beyond the schema, which already explains projectId as 'Pipeline ID' and the pagination fields. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (get execution history list) and the resource (SourcePipeline pipeline). It distinguishes itself from the sibling get_pipeline_history_detail by implying a list vs. a detail, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like get_pipeline_history_detail or list_pipelines. The description only states what the tool does, not the context in which it should be chosen.

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

• ncloud_list_postgresql_backupsB
  3.1/5.0
  Behavior2/5

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

  The annotation readOnlyHint=true already declares the read-only nature. The description adds only 'List backups for a Cloud DB for PostgreSQL instance,' which restates the function without disclosing additional behavior such as pagination, default limits, or what backup information is returned. No behavioral context is added 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the verb and resource. It is concise, contains no unnecessary information, and is appropriately sized for a simple read operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description is minimal. It fails to specify what the returned backup list contains or how it differs from the sibling `ncloud_list_postgresql_backup_details`. The agent may not know whether this returns summaries or full details, but the parameter is self-explanatory and the operation is straightforward, making it minimally adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has one required parameter `cloudPostgresqlInstanceNo` with description 'Cloud PostgreSQL instance number,' giving 100% schema coverage. The tool description does not add any further meaning about the parameter, such as format or how to obtain the instance number. Since schema coverage is high, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and identifies the resource as 'backups for a Cloud DB for PostgreSQL instance.' It clearly states the tool's function. However, it does not distinguish this tool from the sibling `ncloud_list_postgresql_backup_details`, which also relates to backups, so it lacks sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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. There is no mention of prerequisites, exclusions, or references to sibling tools like `ncloud_list_postgresql_backup_details`. The agent is left to infer usage from the name alone.

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

• ncloud_nks_upgrade_node_poolB
  3.1/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries the full burden of behavioral disclosure. It only reveals the HTTP method (PATCH), implying mutation, but does not mention that upgrades may cause rolling node replacement, downtime, incompatibility, or irreversibility, nor whether it is a long-running operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The purpose is front-loaded in a single, tight sentence with no wasted words. The second sentence about PATCH is brief but of marginal value to an MCP agent since the server typically handles the HTTP method.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and empty annotations, the description is the only source of context, and at 13 words it is insufficient for a mutating infrastructure operation. It omits expected return/status checks, version ordering constraints, upgrade disruption profile, and prerequisites such as cluster/node pool availability.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all five parameters. The description adds no semantic detail about parameters beyond noting they are sent as query parameters, which is marginal; baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Upgrade'), the resource ('node pool'), and the specific aspect (Kubernetes version). This distinguishes it from sibling tools like ncloud_nks_upgrade_cluster (which targets the whole cluster) and ncloud_nks_update_node_pool (a more general update).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus the closely related ncloud_nks_upgrade_cluster or ncloud_nks_update_node_pool, and there are no prerequisites, exclusions, or alternative recommendations. The PATCH note is an implementation detail, not usage guidance.

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

• ncloud_pca_create_caB
  3.1/5.0
  Behavior2/5

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

  The only annotation is destructiveHint: false, which the description does not leverage or contradict. The description adds no behavioral context such as side effects, prerequisites, quotas, or state changes after creation. Since annotations are minimal, the description carries the burden and fails to disclose meaningful behavioral traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded, but the second sentence ('Requires alias, keyType, period, and x509Parameters') is redundant with the schema's required fields and introduces an erroneous terminology. It does not earn its place and detracts from conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 14 parameters and no output schema, the description is too sparse. It does not mention required vs. optional fields, dependencies (e.g., issuerTag for PRIVATE_SUB), return values, or likely failure modes. An agent would need to rely entirely on the schema, which is insufficient for correct invocation in nuanced scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage, the schema already documents all parameter details. The description's parameter mention is inaccurate and adds negative value: 'x509Parameters' is not a real parameter, and it omits 'caType' and 'commonName' which are required. It does not clarify formats, dependencies, or relationships beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create') and clearly identifies the resource ('new Private CA') while distinguishing root and sub CA variants. This aligns with the tool name and differentiates it from sibling PCA tools like delete, get, or issue operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The purpose statement 'Create a new Private CA' implicitly conveys when to use the tool, but it does not explicitly mention when not to use it or suggest alternatives. No comparison to other PCA tools (e.g., delete, get, issue end cert) is provided, so usage context is only implied, not explicit.

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

• ncloud_pipeline_list_sourcedeploy_stagesB
  3.1/5.0
  Behavior2/5

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

  The readOnlyHint annotation already establishes this as a safe read operation. The description adds no further behavioral context, such as pagination behavior, filtering semantics, or what 'available' means, leaving the agent to infer from the schema alone.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no padding or redundant information. It earns a top score for conciseness despite lacking depth elsewhere.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple list operation with full schema coverage and a readOnly annotation. The description states the essential purpose, and the schema covers parameters, but there is no mention of return value shape or how it fits into pipeline workflows, leaving minor gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all four parameters (projectId, pageNo, pageSize, searchWord) documented in the schema. The description adds no extra parameter insights, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource ('List available SourceDeploy stages for a project') making the core action clear. However, it does not distinguish this tool from the similar sibling ncloud_sourcedeploy_list_stages, so it falls short of the highest score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives like ncloud_sourcedeploy_list_stages or ncloud_pipeline_list_sourcedeploy_scenarios. No context, prerequisites, or exclusions are provided beyond what the name implies.

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

• ncloud_reboot_mongodb_serverB
  3.1/5.0
  Behavior2/5

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

  The annotations already declare idempotentHint=true and destructiveHint=false, leaving a low burden on the description. However, the description provides no additional behavioral traits beyond the annotations—nothing about temporary downtime, asynchronous execution, or instance-state requirements. It does not contradict the annotations, but it is essentially silent on behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the action verb, and contains zero filler words. Every word earns its place by precisely stating the tool's purpose. It is appropriately sized for a simple one-parameter reboot operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is low-complexity (one required parameter, no output schema) and the annotations cover the safety profile, so the description is minimally sufficient. However, it lacks operational context that would help an agent set expectations, such as the instance becoming temporarily unavailable or the reboot being asynchronous.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with cloudMongoDbServerInstanceNo already described as 'Cloud MongoDB server instance number to reboot'. Therefore the baseline is 3. The description adds no additional parameter meaning beyond the schema; the single parameter's semantics are fully captured by the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Reboot a Cloud DB for MongoDB server instance' uses the specific verb 'Reboot' and clearly identifies the target resource (Cloud DB for MongoDB server instance). It distinguishes from sibling reboot tools like ncloud_reboot_mysql_server by naming MongoDB, though it is essentially a short paraphrase of the tool name without explicit differentiation from alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool, what prerequisites exist, or which alternatives apply. It does not mention that the instance must be running, that the instance number can be obtained from ncloud_list_mongodb_instances, or that other reboot tools (e.g., ncloud_reboot_mysql_server) should be used for other database types. Usage is only implied by the name.

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

• ncloud_reboot_mssql_serverB
  3.1/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, which covers the safety profile. However, the description adds no additional behavioral context such as whether the reboot causes downtime, is asynchronous, or if there are any side effects. It does not contradict the annotations, but it also provides no extra transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence of 8 words that immediately conveys the core operation. There is no wasted text, and it is appropriately sized for a simple reboot action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter reboot tool, the description is minimally adequate. The schema covers the parameter, and annotations cover safety. However, the description lacks any context about operational impact (e.g., downtime, async behavior) or when to use the tool, which would help an agent invoke it correctly. It is not incomplete enough to be unusable, but it barely meets the minimum viable threshold.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for the single parameter (cloudMssqlServerInstanceNo) with a clear description. The description's mention of 'server instance' only loosely ties to the parameter without adding any new format, constraints, or deeper meaning. Baseline 3 applies since the schema does all necessary work.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Reboot') and the resource ('Cloud DB for MSSQL server instance'), which distinguishes it from other reboot tools for MySQL, PostgreSQL, etc. The wording is slightly awkward ('a Cloud DB for MSSQL server instance') but the meaning is unambiguous. It loses a point because it doesn't explicitly mention the instance number parameter, though that is covered by the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives (e.g., ncloud_reboot_mysql_server, ncloud_reboot_postgresql_server) or any prerequisites like instance state. The description simply restates the action without any usage context or exclusions.

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

• ncloud_search_event_countB
  3.1/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the readOnlyHint annotation. It does not disclose return format, pagination, potential performance costs, or any rate-limiting constraints. It is consistent with the annotation but contributes no extra transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single succinct sentence, front-loaded with the action and object, with no filler or redundant phrases.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only count tool with full schema coverage and a readOnly annotation, the description is minimally adequate. However, it does not specify the return value (e.g., just the integer count) nor differentiate from the related event search tools, leaving some contextual gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are already well-documented. The description only reinforces the time-range aspect and does not add new semantic meaning beyond the schema, meriting the baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Get the count') and resource ('monitoring events from Cloud Insight') with an explicit time-range scope. It does not explicitly contrast with sibling tools like ncloud_search_events, but the count-vs-list distinction is inferable from the name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives. It does not mention that ncloud_search_events returns actual events while this returns only a count, nor any prerequisites or context for choosing this count endpoint.

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

• ncloud_ses_get_dashboardB
  3.1/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond what the readOnlyHint annotation already conveys. It does not describe the return format, pagination, rate limits, or any side effects. Since the annotation already indicates safety, the description is expected to add extra context but fails to do so.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that directly states the tool's purpose. Every word adds value, with no redundancy or filler, making it optimally concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one parameter, read-only) and the schema covers the parameter, so the description is minimally adequate. However, without an output schema or any hint of what 'dashboard information' includes, the description lacks enough context to fully prepare an agent for the response. A bit more specificity would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the single parameter (serviceGroupInstanceNo) with the description 'Cluster instance number'. The tool description adds no additional semantic meaning, but with 100% schema coverage the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource 'dashboard information for a Search Engine Service cluster', identifying the tool's purpose without being tautological. However, it does not explicitly differentiate this from sibling tools like ncloud_ses_get_monitoring or ncloud_ses_get_cluster_detail, so it earns a 4 rather than a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as ncloud_ses_get_cluster_detail or ncloud_ses_get_monitoring. There is no mention of prerequisites, exclusions, or typical use cases, leaving the agent to infer usage solely from the tool name.

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

• ncloud_ses_precheck_upgradeB
  3.1/5.0
  Behavior2/5

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

  No annotations are present, so the description carries full behavioral disclosure. It merely states 'Pre-check' without indicating whether it is read-only, what it validates, or what the response looks like. This leaves the agent unable to infer side effects or safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is one short sentence ('Pre-check before upgrading Search Engine version') with no waste. However, it is quite terse and lacks any additional context that could be added without hurting conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description should explain what the precheck reports (e.g., compatibility issues), but it only gives a generic phrase. It also omits any details about prerequisites or the upgrade workflow, leaving the context incomplete for a mutation-adjacent operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema (100% coverage) with 'Cluster instance number' and 'Target version code'. The description adds no additional parameter semantics, but the schema already covers the meaning, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a pre-check before Search Engine version upgrade, using 'Pre-check' as the verb and 'upgrading Search Engine version' as the resource. It distinguishes from actual upgrade and progress tracking tools in the sibling list, though it does not elaborate on the specific checks performed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'before upgrading' implies the tool is a prerequisite to ncloud_ses_upgrade_version, but no explicit guidance or alternatives are listed. It conveys the timing but not when to invoke it versus other tools.

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

• ncloud_update_rule_groupB
  3.1/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the annotations. It does not explain whether unspecified fields are preserved or reset, whether re-applying the same update is truly idempotent, or any permission requirements. Annotations already declare idempotent and non-destructive, but the description adds no additional insight.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no redundant words or repetition. It is concise and directly conveys the action and target, earning a perfect score for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich schema and annotations, the minimal description is adequate but leaves gaps. It does not explain the update semantics (e.g., partial vs. full replacement), return values, or error scenarios. For a 6-parameter mutation tool, this level of completeness is mediocre but not insufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all six parameters are fully documented in the input schema. The tool description itself adds no parameter information, but with full schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Update an existing Cloud Insight event rule group' uses a specific verb ('Update') and resource ('rule group'), clearly distinguishing it from create/delete/list siblings. However, it does not elaborate on specific aspects being updatable, so it is clear but slightly generic.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided for when to use this tool versus alternatives. It does not mention that this is the appropriate tool for modifying an existing rule group in contrast to ncloud_create_rule_group or ncloud_delete_rule_group, nor does it note any prerequisites.

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

• ncloud_add_file_pluginB
  3.2/5.0
  Behavior2/5

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

  Annotations only include destructiveHint=false, and the description adds no behavioral context beyond the basic action. It does not disclose whether the operation is idempotent, whether the server must be running, or what the response contains.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no redundant words, front-loading the verb and object. It is concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  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 the description omits return value details and preconditions. It is minimal for a mutation tool, lacking context about plugin replacement behavior or server requirements.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes all three parameters (instanceNo, configList, type) with descriptions, and the description adds no additional parameter semantics. Since schema coverage is 100%, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('add') and identifies the resource ('file monitoring plugin(s)') and target ('server instance'), distinguishing it from sibling tools like add_process_plugin and add_port_plugin.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, such as whether it appends to existing plugins or replaces them, nor any alternatives. No context about prerequisites or comparison to sibling tools like set_file_plugins is given.

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

• ncloud_add_route_table_subnetB
  3.2/5.0
  Behavior2/5

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

  With annotations only providing destructiveHint=false, the description adds no further behavioral context—no mention of idempotency, effects on existing associations, failure conditions, or response behavior. It does not contradict annotations, but it also does not enrich them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence conveys the purpose with zero wasted words. It is efficient and easy to parse, striking the right length for the simplicity of the operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  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 minimal annotations, yet the description provides no additional context about expected responses, preconditions, or side effects. For a mutation-like operation, this is insufficient for an agent to fully anticipate the outcome.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with each parameter briefly described. The description adds no additional parameter semantics beyond what the schema already 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Associate a subnet with a route table' uses a specific verb and resource, clearly stating the action. It effectively distinguishes this tool from its sibling ncloud_remove_route_table_subnet by naming the opposite operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. The description simply states the action without contextualizing it in a decision process.

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

• ncloud_add_server_image_sharingB
  3.2/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the destructiveHint annotation. It does not disclose whether existing sharing permissions are preserved, whether the operation is idempotent, or what authorization is required. Since the annotation already indicates non-destructiveness, the description contributes minimal extra transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the primary verb 'Add' and fully communicates the operation without unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple two-parameter nature and rich schema coverage, the description is largely complete. However, it lacks differentiation from closely related sibling tools and does not provide usage context, which slightly reduces completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides clear descriptions for both parameters (serverImageNo and targetLoginIdList), covering 100% of the parameter semantics. The description does not add meaningful detail beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the action (Add), resource (server image), and recipients (specified accounts). However, it does not distinguish between server image sharing and the sibling ncloud_add_member_server_image_sharing, which may cause ambiguity in tool selection.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like ncloud_add_member_server_image_sharing or ncloud_remove_server_image_sharing. Missing prerequisites, exclusions, or context for sharing permissions.

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

• ncloud_cdss_change_kafka_configB
  3.2/5.0
  Behavior2/5

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

  Annotations already declare the tool as idempotent and non-destructive, but the description adds no additional behavioral context. It does not mention whether changes take effect immediately, require a restart, or need to be applied via a separate step, which is critical for a config mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, straightforward sentence with no filler or redundancy. It is efficient and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is minimal and lacks essential context: it does not clarify the effect of the change, whether it is applied immediately or requires a separate apply action, or what kind of return value to expect. Given the absence of an output schema and the existence of a sibling apply_config_group tool, this leaves critical gaps for an agent deciding whether to invoke this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no supplementary information about the parameters beyond what the schema already states, such as the format of kafkaConfig key-value pairs or the meaning of configGroupNo.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Change' and identifies the resource as 'Kafka configuration settings in a Config Group'. This clearly indicates the operation and distinguishes it from sibling tools like get_kafka_config (read) and apply_config_group (apply).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like apply_config_group or rolling_restart. The description implies it is for modifying config, but lacks context about prerequisites, sequencing, or exclusion criteria.

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

• ncloud_cdss_create_config_groupB
  3.2/5.0
  Behavior2/5

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

  Annotations only include destructiveHint: false, and the description adds no additional behavioral context. It does not disclose side effects, idempotency, naming constraints, or expected response behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the key verb and resource. It is efficient, though slightly generic and lacking additional details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple create operation, the description plus schema is mostly sufficient, but it lacks context about return values, prerequisites, and potential errors. With no output schema, more detail on response would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all three parameters, so the schema already defines each parameter adequately. The description adds no extra parameter semantics, but baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Create' and the resource 'Config Group' in the context of CDSS cluster configuration. It distinguishes this from sibling tools like list/get/delete/apply config groups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing an existing CDSS cluster, or when to use other config group tools (e.g., apply, change kafka config).

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

• ncloud_cdss_restart_kafka_per_nodeB
  3.2/5.0
  Behavior2/5

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

  The description adds no behavioral detail beyond the annotations. Annotations indicate idempotent and non-destructive, but the description does not disclose side effects like potential service interruption on the specific node, whether the operation is synchronous, or any required prechecks. With annotations present, the bar is lower, but the description still fails to add meaningful context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that efficiently states the tool's purpose. There is no fluff or redundant information, making it optimally concise for its scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of an output schema and the minimal description, the tool's behavior is under-documented. There is no mention of what happens during the restart, how to verify success, or how this relates to other CDSS restart operations like prechecks or rolling restarts. The context is insufficient for an agent to fully anticipate the tool's effects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters having clear descriptions ('Node compute instance number' and 'Cluster instance number'). The description itself does not add any parameter semantics beyond the schema, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Restart Kafka') and the specific scope ('on a specific node in a CDSS cluster'), which distinguishes it from sibling tools like ncloud_cdss_restart_kafka that presumably restart Kafka cluster-wide. The verb and resource are 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.

  Usage Guidelines2/5

  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 that this is for per-node restart, nor does it name alternatives such as ncloud_cdss_restart_kafka for cluster-wide restarts. There is no context about prerequisites or typical use cases.

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

• ncloud_cdss_upgrade_versionB
  3.2/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries the full burden of behavioral disclosure. It only states the action and does not mention potential downtime, whether the upgrade triggers a rolling restart, if it is a long-running operation, or any required permissions. This is insufficient for a mutating operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, succinct sentence that directly states the tool's purpose with no unnecessary words. It is appropriately sized and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex mutation operation with no annotations and no output schema, the description is too minimal. It omits critical context such as preconditions (precheck), monitoring via upgrade_status, and what the response or result might be. The presence of sibling tools for precheck and status makes this gap more significant.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for all three parameters, so the description adds little beyond the schema. The phrase 'Kafka version' is already captured by the 'kafkaVersionCode' parameter description. Therefore, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Upgrade Kafka version for a CDSS cluster' uses a specific verb (upgrade) and resource (Kafka version for a CDSS cluster), clearly differentiating it from sibling tools like ncloud_cdss_upgrade_precheck and ncloud_cdss_upgrade_status. It unambiguously states the tool's core function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites such as running ncloud_cdss_upgrade_precheck first, nor does it point to ncloud_cdss_upgrade_status for monitoring progress. The description implies the action but lacks explicit usage context.

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

• ncloud_copy_objectB
  3.2/5.0
  Behavior2/5

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

  Annotations are empty, so the description must disclose side effects. It states the copy action but omits overwrite semantics, server-side vs client-side behavior, metadata preservation, and permissions required. The description carries the full behavioral disclosure burden and fails to cover these critical traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no fluff. All words are informative, and it efficiently states the operation and its scope without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema or annotations, the description alone must support safe invocation. It omits important context such as overwrite behavior, success response, and source/destination requirements. Though parameters are fully documented, the tool's behavioral context is underspecified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of parameters (bucketName, objectName, copySource), so the description adds no additional meaning. The description does not clarify parameter interdependencies beyond what the schema already provides. Baseline 3 applies due to full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb ('Copy') and resource ('an object in Object Storage'), and explicitly distinguishes two valid scenarios (same bucket or cross-bucket). It clearly differentiates this operation from sibling object tools like get, put, or delete.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to choose copy_object over alternative operations (e.g., get_object + put_object). No prerequisites, exclusions, or alternative tools are mentioned; the description only restates the operation without context for decision-making.

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

• ncloud_create_maintenanceB
  3.2/5.0
  Behavior2/5

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

  With only destructiveHint=false annotation, the description adds no additional behavioral information. It does not disclose side effects, return values, validation rules, or implications of creating a maintenance schedule, leaving the agent with limited understanding of the operation's behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that efficiently conveys the core action and object. It is front-loaded with the verb and resource, contains no redundant phrasing, and every word contributes to the meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite full schema coverage, the description lacks crucial context such as what a 'planned maintenance schedule' entails, the meaning of the 'dimensions' object, expected return values, and any constraints or prerequisites. For a create operation with nested parameters and no output schema, this sparse description leaves significant gaps for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 5 parameters have complete schema descriptions (100% coverage), so the baseline is 3. The description adds no extra parameter semantics beyond what the schema already specifies, which is acceptable given the schema's thoroughness.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Create' with a distinct resource 'planned maintenance schedule in Cloud Insight', clearly indicating the tool's action and focus. It differentiates from sibling tools like update_maintenance, delete_maintenance, and list_maintenances by specifying creation of a new schedule.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no guidance on when to use this tool versus alternatives, lacks any prerequisites or context, and does not mention that this tool is for creating new schedules while others handle updates or deletions. No usage scenarios or exclusions are provided.

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

• ncloud_create_monitor_groupB
  3.2/5.0
  Behavior2/5

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

  Aside from the single annotation indicating destructiveHint=false, the description adds no behavioral details such as idempotency, permissions, return values, or side effects. 'Create a new' minimally implies a mutation but doesn't disclose anything beyond what the annotation already partially covers.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, immediately front-loaded with the action verb and resource. No filler words; the Korean translation in parentheses is a harmless addition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool is a create operation within the Cloud Insight monitoring domain, the description doesn't explain what a target group is, how it relates to metrics groups or rules, or what the API returns. With no output schema and only minimal annotation, the agent lacks context to use this tool confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover all three parameters (100% coverage), so the baseline is 3. The tool description itself doesn't add parameter context, but the schema already explains prodKey, groupName, and resourceList sufficiently.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Create' with the resource 'Cloud Insight monitoring target group,' clearly distinguishing it from sibling operations like list, get, update, and delete monitor group. The Korean parenthetical provides a localized alias but doesn't introduce ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description doesn't mention related operations or prerequisites, so an agent must infer usage solely from the name and verb.

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

• ncloud_create_postgresql_read_replicaB
  3.2/5.0
  Behavior2/5

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

  With only a destructiveHint: false annotation (which is consistent with 'Create'), the description adds no additional behavioral context. It does not disclose whether the operation is asynchronous, how to track progress, or any side effects beyond creating a replica. The description does not contradict annotations, but it adds minimal value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no wasted words. It effectively communicates the tool's purpose without verbosity or redundant phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create operation with no output schema, the description is incomplete. It does not mention what is returned on success, whether the operation is synchronous or asynchronous, or how to check the status. Given the lack of annotation coverage and output schema, the description fails to provide sufficient context for an agent to fully understand the tool's behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with clear descriptions (e.g., 'Cloud PostgreSQL instance number to create read replica for'), so the baseline is 3. The tool description itself adds no parameter-level meaning beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb and resource: 'Create a read replica for a Cloud DB for PostgreSQL instance'. It specifies the exact action and the target resource, and the name aligns with sibling tools like ncloud_delete_postgresql_read_replica, distinguishing this creation action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 prerequisites, such as needing an existing primary instance, nor does it contrast with creating a separate instance or using the delete replica tool. Usage is only implied by the name.

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

• ncloud_create_public_ipB
  3.2/5.0
  Behavior2/5

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

  The description adds little beyond the tool name and the destructiveHint annotation. It confirms this is a creation operation, but does not disclose potential implications such as billing, immediate availability, or that the resource persists and must be deleted later. There is no mention of required permissions or region constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that states the primary purpose without extraneous information. Every word is necessary, and it is immediately clear what the tool does. This is efficient and appropriately structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the simple schema and annotations, the description is too minimal for a cloud resource creation tool. It does not mention optional association behavior, lifecycle implications, or the response structure (no output schema exists). An agent would need additional context to understand the full scope of the operation and its consequences.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents both parameters (serverInstanceNo and publicIpDescription) with clear descriptions, so the description does not need to repeat them. The description adds no additional meaning about parameter usage or relationships, which maintains the baseline score of 3 given 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Create a new public IP instance' clearly identifies the action (create) and the resource (public IP instance). This distinguishes it from sibling tools like ncloud_list_public_ips, ncloud_associate_public_ip, and ncloud_delete_public_ip, which perform different operations on the same resource. The verb and resource are 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.

  Usage Guidelines2/5

  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 that this should be used when a new public IP is needed, or that existing IPs should be associated via ncloud_associate_public_ip. No prerequisites or exclusions are stated, leaving the agent without context for selection.

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

• ncloud_create_rule_groupB
  3.2/5.0
  Behavior2/5

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

  Annotations only state destructiveHint=false, which is expected for a create operation. The description adds no behavioral context beyond 'Create a new', such as whether the rule group becomes active immediately, permission requirements, or side effects. It does not disclose that dryRun can preview without creating, which is a valuable behavioral trait not obvious from the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no redundant phrasing. The first sentence states the core action and resource, the second summarizes key components. Every phrase earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a complex creation tool with 7 parameters, nested arrays, and no output schema. The description does not reference prerequisites (e.g., needing existing metrics groups or monitor groups) or related list tools, nor does it mention validation behavior or the existence of dryRun for preview. For its complexity, the 2-sentence description is incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameter descriptions exist in structured form. The tool description adds a high-level summary ('Defines monitoring targets, metrics, thresholds, and notification recipients') that groups parameters conceptually, but it does not explain relationships between parameters or provide value beyond what the schema already conveys. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Create' and the resource 'Cloud Insight event rule group', distinguishing it from update/list/delete siblings. It further defines the scope by mentioning monitoring targets, metrics, thresholds, and notifications, which 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.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives like ncloud_create_rule_directly, nor does it mention prerequisites such as needing existing metricsGroupId and monitorGroupId. There is no exclusionary language or reference to related list/read tools for setup.

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

• ncloud_create_target_groupB
  3.2/5.0
  Behavior2/5

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

  With only destructiveHint=false in annotations, the description carries the burden of behavioral disclosure. It does not mention that the target group may need to be attached to a load balancer later, what the response contains (e.g., targetGroupNo), or any side effects. The description is minimal and does not add meaningful behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the verb, and contains no fluff. It earns its place by adding the load balancer context, making it appropriately sized and structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 15 parameters and no output schema, the description is incomplete. It does not explain the target group's role in load balancing, when it should be created relative to load balancers, or what the expected response is. The agent would need to rely on schema and sibling names, which is insufficient for confident invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 itself adds no parameter-level information, but all parameters already have descriptions in the schema. This is acceptable but not enhanced.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Create') and resource ('a new target group for a load balancer'), which distinguishes it from sibling tools like list/get/change/delete target groups. It adds the load balancer context, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives, such as creating a load balancer first or modifying an existing target group. It lacks prerequisites (e.g., existing VPC) and does not mention related tools like change_target_group_config or list_target_groups.

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

• ncloud_functions_create_actionB
  3.2/5.0
  Behavior2/5

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

  The annotation only states destructiveHint=false. The description adds 'Create or update' which signals mutation but does not disclose important behavioral traits such as overwriting existing actions on update, required fields for Basic vs Sequence, or any side effects. The annotation bar is low, but the description contributes almost nothing beyond the operation name.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single front-loaded sentence with no redundant words. It conveys the essential purpose and type restriction in 13 words, making it highly efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (17 parameters, 2 required, no output schema, nested objects), the description is vastly underspecified. It fails to explain the relationship between exec_kind and other parameters (e.g., sequence requires exec_components, basic requires exec_code/exec_main) or the behavior of updates. The schema carries all the weight, but the description should provide higher-level context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all 17 parameters have descriptions. The tool description adds no extra parameter meaning, merely referencing 'Basic or Sequence type' which is redundant with the exec_kind schema description. This matches the baseline of 3 for fully-documented schemas.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Create or update') and the resource ('Cloud Functions action') with the type qualifier 'Basic or Sequence'. This distinguishes it from sibling tools for packages, triggers, and other resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided about when to use this tool versus alternatives. It does not mention that actions are distinct from packages or triggers, nor does it explain when to create vs update. The description is too minimal to guide tool selection among the many sibling tools.

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

• ncloud_functions_get_triggerB
  3.2/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes that this is a safe, non-destructive operation, so the description doesn't need to restate that. The description adds minimal behavioral context (it returns 'detailed information' but doesn't specify what fields or any edge cases). No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, straightforward sentence of eight words. It's front-loaded and concise with no unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and a vague description saying only 'detailed information,' the agent does not know what fields the response includes. The description also doesn't clarify the role of the platform parameter in resolving the trigger or any error behavior. For a tool with minimal schema and no output structure, this is insufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters (platform and triggerName) are fully documented in the schema. The tool description doesn't add any additional parameter semantics beyond what the schema already provides, which meets the baseline expectation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' with the resource 'detailed information about a specific trigger', clearly indicating a read operation targeting an individual trigger. It doesn't explicitly differentiate from siblings like list_triggers or get_trigger_activation_detail, but the focus on 'specific trigger' is clear enough for a get-by-name operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 doesn't mention that list_triggers should be used to enumerate triggers, nor that get_trigger_activation_detail is for activation history. The context is purely implied by the name.

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

• ncloud_functions_invoke_actionB
  3.2/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries full behavioral burden. It only discloses that the execution result is returned, but does not mention whether the invocation is synchronous, how timeout affects behavior, side effects of running user code, or error/return format. This is insufficient for a tool that executes arbitrary functions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, front-loaded with the core action, and no redundant words. Every word adds value by specifying the resource and the return behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given empty annotations, no output schema, and a complex operation that runs user code, the description is too minimal. It lacks return value structure, timeout semantics, platform-specific behavior, and error handling context. The schema covers parameters but nothing about execution context or result format.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 100% description coverage for all five parameters, including defaults, constraints, and descriptions. The tool description adds no extra parameter semantics beyond what the schema already provides, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states a specific verb 'Invoke' with a specific resource 'Cloud Functions action', and adds 'return the execution result' which clarifies the synchronous behavior. This clearly distinguishes it from siblings like ncloud_functions_invoke_trigger, ncloud_functions_create_action, and ncloud_functions_get_action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool compared to alternatives like ncloud_functions_invoke_trigger or ncloud_functions_get_action. There is no mention of prerequisites, blocking vs async invocation, or scenarios where a different Functions tool would be appropriate.

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

• ncloud_get_activity_logsB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description appropriately reflects a read operation. It adds useful context about the POST method and internal epoch conversion, which goes beyond the schema, but it omits behavioral details like pagination behavior or response format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with purpose and followed by transport/time details. No filler or repetition, but the mention of 'service and user' could be more explicit about parameter correspondence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers core functionality, HTTP method, and time handling, but for a 5-parameter tool with no output schema, it lacks details on return value structure, pagination expectations, and how to achieve service/user filtering. Given the large sibling set, more guidance would be beneficial.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of parameters, including time format and conversion details, so the baseline is 3. The description adds a high-level mapping to 'period, service, and user' but does not clarify how 'user' maps to the parameters, and 'service' aligns loosely with nrn.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches 'cloud activity tracer logs' with filtering capabilities, which distinguishes it from other log-related tools in the sibling list. However, it does not explicitly differentiate from ncloud_get_activity_detail or ncloud_search_events, making the distinctiveness slightly incomplete.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided on when to use this tool versus the many sibling log/event tools. The description implies usage by describing filters, but it does not state prerequisites, exclusions, or alternatives.

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

• ncloud_get_block_storage_detailB
  3.2/5.0
  Behavior2/5

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

  The annotation readOnlyHint=true already discloses the read-only safety profile, so the description does not need to state that. However, the description adds no additional behavioral context beyond the annotation—it does not mention what 'detailed information' includes (e.g., size, status, attached server), nor does it describe response format or potential error conditions. Since there is no output schema, the description could have carried more weight here but does not.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the action ('Get detailed information') and resource ('specific block storage instance'), with no wasted words. However, it is terse and under-specifies the value, which prevents a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one required parameter and an existing readOnly annotation, this description is minimally viable. However, with no output schema, the description could have been more complete by indicating what 'detailed information' includes or whether there are any constraints (e.g., the instance must exist). It is adequate but has clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the parameter blockStorageInstanceNo is described as 'Block storage instance number to query,' which is unambiguous. The tool description does not add extra semantic detail beyond the schema, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get detailed information about a specific block storage instance' uses a specific verb ('Get detailed information'), identifies the resource ('block storage instance'), and explicitly scopes to 'a specific' instance, distinguishing it from the sibling tool ncloud_list_block_storage (which lists instances) and ncloud_get_block_storage_volume_types (which concerns volume types).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives, such as 'use this when you have a blockStorageInstanceNo and need details' or 'use list_block_storage to enumerate all instances first.' The implied use case is present but not stated, and no exclusions or prerequisites are mentioned.

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

• ncloud_get_discount_listB
  3.2/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates this is a safe read operation. The description adds some behavioral context by stating it returns discounts 'assigned to the account' and includes 'validity periods and amounts,' which clarifies the response scope. However, it does not disclose pagination behavior, default filtering, or the effect of parameters like isPartner or isValidDiscount.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states the purpose and then elaborates with the key return elements. There is no wasted text, and it is easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 9 optional parameters and no output schema, the description is too brief to provide adequate context. It does not explain how to use the date range, filtering, or account-type parameters, nor does it describe the response structure beyond 'validity periods and amounts.' The tool would be hard to invoke correctly without consulting each parameter schema individually.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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's mention of 'product discounts, credits, coins' maps to the discountTypeCode enum, adding minimal semantic value. Otherwise, it does not explain parameter interactions or provide syntax details beyond what the schema already documents.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get discount list' with a specific resource and scope, enumerating the types of discounts (product discounts, credits, coins) and what is returned (validity periods and amounts). It differentiates from sibling tools like ncloud_get_coin_history_list and ncloud_get_credit_history_list by explicitly covering all discount types, but it does not name alternatives directly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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. The description merely states what it does without mentioning any exclusions, prerequisites, or comparison to other discount-related tools. The presence of 9 optional parameters and many sibling tools makes this a significant gap.

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

• ncloud_get_log_count_recentB
  3.2/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already declares the read-only nature, and the description is consistent with it (no contradiction). However, the description adds no extra behavioral context beyond 'recent'—it doesn't clarify time windows, aggregation behavior, or return format. Given the annotation covers safety, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, directly front-loaded sentence with no filler. It earns its place by stating the core purpose without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is low-complexity with one optional parameter and a read-only annotation, yet the description leaves key context missing: what time period 'recent' covers, what the count represents (e.g., total logs or distinct types), and what the return value looks like. This is a minimal viable description but with notable gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with a clear description for the only parameter 'regionCode' (Region code, default kr). The tool description adds no additional parameter context, but since the schema is complete, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Get') and resource ('recent log count in Cloud Log Analytics'), making the tool's purpose understandable. However, it does not explicitly contrast with sibling tools like get_log_count_total or get_log_count_by_period, relying solely on the word 'recent' to differentiate.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus the other log count tools in the sibling list. No context is provided for what 'recent' means (e.g., last 24 hours) or scenarios where this should be preferred over get_log_count_total or get_log_count_by_period.

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

• ncloud_get_root_passwordB
  3.2/5.0
  Behavior2/5

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

  Annotations declare readOnlyHint=true, and the description does not contradict this. However, the description fails to disclose that the returned password is typically encrypted and requires the privateKey parameter to decrypt—a key behavioral aspect not covered by 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that immediately conveys the core function. There is no wasted text or repetition of schema information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the sensitive nature of retrieving a root password, the description omits important context such as the encryption/decryption flow and the optional nature of the private key (serverInstanceNo is required, privateKey is not). The schema partly covers this, but the tool's overall context remains incomplete for an agent to use it confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the input schema already documents both parameters meaningfully (e.g., privateKey is 'Private key to decrypt the password'). The description adds no extra parameter detail, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves the root password for a specific server instance. The singular 'a server instance' distinguishes it from the sibling tool ncloud_get_root_password_list, which handles multiple instances.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus the list variant or any other alternative. It also doesn't mention prerequisites such as needing the private key to decrypt the password, which is critical for successful use.

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

• ncloud_globalcdn_get_purge_historyB
  3.2/5.0
  Behavior2/5

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

  The readOnlyHint=true annotation is consistent with the 'Get' verb, but the description adds no behavioral context beyond that, such as rate limits, result ordering, pagination, or side effects. It provides no additional transparency value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 14 words, front-loaded with the action and resource. Every word is informative, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only lookup with 2 parameters and no output schema, the description states the core purpose and scope. It does not describe return values or pagination, but these are not critical for a basic history retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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. The description's 'for an instance' and 'optionally filtered by purge IDs' echoes the schema's cdnInstanceNo and purgeIdList, adding only minimal clarification that the filter is optional.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' with a specific resource 'Global CDN purge request history' and scope 'for an instance (optionally filtered by purge IDs)'. It clearly identifies the tool's function but does not explicitly contrast with the similar sibling tool ncloud_cdnplus_get_purge_history.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, prerequisites, or exclusions. Usage is only implied by the get-history function, and no mention is made of the sibling CDN+ history tool.

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

• ncloud_gtm_update_policy_resourceB
  3.2/5.0
  Behavior3/5

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

  The annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds minimal context by specifying 'within a policy' and 'specific resource group', but it does not disclose whether the update replaces the entire resource group or only merges changes, nor any other behavioral details 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that states the action and target without any redundant words or filler. Every word contributes to the purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool involves complex nested parameters (active/standby arrays) and no output schema, yet the description is extremely brief. It does not explain what a resource group is, how the update behaves (replace vs. modify), or any relationship to sibling tools like ncloud_gtm_get_policy_resources. The description is insufficient for an agent to safely and correctly invoke this tool in a real GTM policy context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 input schema provides terse descriptions for each parameter (e.g., 'Policy ID', 'Active resources'), and the tool description adds no further semantic meaning. The nested object fields (content, healthCheckRegionId, type) lack explanatory context, but the schema coverage requirement is met.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Update') and resource ('specific resource group within a Global Traffic Manager policy'), clearly identifying the operation's target. It distinguishes from the sibling tool ncloud_gtm_update_policy_resources by indicating a singular resource group, though it does not explicitly contrast them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as first retrieving the policy or resource group details, nor any exclusion criteria (e.g., use ncloud_gtm_update_policy_resources for bulk updates).

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

• ncloud_gtm_update_profileB
  3.2/5.0
  Behavior3/5

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

  Annotations already provide idempotentHint=true and destructiveHint=false, covering safety. The description adds only that it updates an 'existing' profile, but does not disclose partial vs. full update semantics, potential side effects, or any required permissions beyond what annotations imply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no filler words. It front-loads the action and resource, making it highly scannable and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is too terse to be fully complete. It omits whether updates are partial (only provided fields) or a full replacement, lacks any return value indication (no output schema), and does not clarify how to locate the domainId. While annotations and schema cover safety and parameters, the core update behavior remains ambiguous.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with clear descriptions for all four parameters (e.g., ttl is 'TTL value in seconds'). The description text adds no additional parameter context, so the schema carries the full burden, meriting the baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Update') and the resource ('existing Global Traffic Manager profile (domain)'), distinguishing it from create/delete/list siblings like ncloud_gtm_create_profile and ncloud_gtm_delete_profile. However, it does not enumerate the updatable fields (TTL, policyId, claRegion), which appear only in the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit when-to-use guidance or alternatives. It does not mention related tools such as ncloud_gtm_create_profile or ncloud_gtm_update_policy, leaving the agent to infer usage solely from the tool name and context.

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

• ncloud_import_login_keyB
  3.2/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries the full burden of behavioral disclosure. It does not mention side effects (e.g., behavior if key name already exists), success/failure semantics, or return values. It only restates the basic action without adding operational insight.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that directly states the action with no unnecessary words. It is appropriately sized for the tool's simplicity and front-loads the key information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutating tool with no annotations, no output schema, and only a one-line description, the context is incomplete. It lacks guidance on side effects, prerequisites, or what happens on success/failure. While the schema covers parameters, the description fails to provide operational completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters, and the description adds no additional meaning beyond what the schema already provides. The baseline of 3 is appropriate because the schema handles parameter semantics adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Import') and resource ('SSH public key') with a clear target ('login key'), making the action unambiguous. It distinguishes itself from sibling tools like create_login_key and delete_login_keys by focusing on importing an existing key.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, no prerequisites, and no context such as 'use when you have an existing public key'. It simply states the action without any situational context or exclusions.

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

• ncloud_list_rule_groupsB
  3.2/5.0
  Behavior3/5

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

  The description aligns with the readOnlyHint annotation (says 'Get'), but adds no behavioral details beyond that. It provides domain context by mentioning 'Cloud Insight' and 'monitoring alerts,' but does not disclose pagination behavior or filtering constraints already present in the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no filler. It is front-loaded with the main verb and resource, making it easy to scan. While concise, it omits any supplementary usage or context details, but remains economical.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with pagination parameters and a read-only annotation, the description is adequate but minimal. It doesn't explain what a 'rule group' is or that results are paginated, relying on the schema for parameter details. Given the lack of an output schema, the description could clarify return format, but the core purpose is clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all four parameters, so the description does not need to repeat parameter semantics. The schema already describes prodKey as 'cw_key' filter, pageSize/Num, and search keyword. The description adds no additional meaning beyond the schema, so it meets the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('list of Cloud Insight event rule groups'), clearly indicating a listing operation. It distinguishes from sibling tools like get_rule_group (single) and create/delete/update variants by focusing on list retrieval. However, it could more explicitly mention that this returns all rule groups (with pagination) to fully disambiguate.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as get_rule_group for a single rule group or list_metrics_groups for other monitoring resources. The description only states what the tool does, leaving the agent to infer usage from the tool name.

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

• ncloud_nks_add_subnetB
  3.2/5.0
  Behavior2/5

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

  Annotations provide only destructiveHint=false, which is minimal. The description adds no behavioral context beyond the action itself, such as whether subnets are added incrementally, if there are any side effects, or if the operation is reversible. For a mutating operation, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no redundancy. Every word contributes to the meaning, and the structure is clean and front-loaded with the action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation with no output schema and minimal annotations, the description does not provide adequate context. It omits any information about return values, idempotency, associated costs, or the relationship to cluster networking, leaving the agent with limited understanding of the operation's full implications.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes both parameters (clusterUuid and subnetNoList) with clear descriptions, covering 100% of the schema. The description adds no additional parameter-level detail, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Add subnets to an NKS cluster' uses a specific verb and resource, clearly indicating what the tool does. It differentiates from sibling tools like ncloud_nks_update_node_pool_subnet or ncloud_nks_create_cluster because it specifically targets adding subnets at the cluster level.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it state any prerequisites or conditions. The one-sentence description is purely functional and lacks context for selection.

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

• ncloud_nks_create_access_entryB
  3.2/5.0
  Behavior2/5

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

  The only annotation is destructiveHint: false, which is trivial for a create operation. The description does not add behavioral context such as auth requirements, idempotency, side effects, or required permissions. No contradiction is present, but the description adds nothing beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It is highly concise and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create operation with 4 parameters, no output schema, and no enums, the description is too sparse. It fails to mention prerequisites (e.g., existing cluster), what constitutes a valid 'type' or 'principalArn', or what the expected result is (e.g., returns an access entry object). The rich NKS access-control context is not conveyed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 in the input schema. The description does not add extra parameter meaning, but also does not need to compensate, placing it at baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create') and clearly identifies the resource ('IAM access entry') and target ('NKS cluster'). It distinguishes from sibling tools like update/delete/list access entries, making the intent immediately clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives, nor are prerequisites mentioned (e.g., that the cluster must already exist). The description simply states the action without contextualizing it against related operations.

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

• ncloud_nks_set_oidcB
  3.2/5.0
  Behavior2/5

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

  The annotations already declare idempotentHint=true and destructiveHint=false, so the agent knows it is a safe, repeatable operation. However, the description adds no extra behavioral context, such as the effect of setting status=false (disabling OIDC), potential impact on cluster access, or that it replaces existing OIDC configuration.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler or redundant details. It efficiently states the tool's purpose without unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 9 parameters and no output schema, the description only provides a terse purpose statement. It does not mention the role of the required 'status' parameter (enable/disable), potential side effects, or how this tool relates to ncloud_nks_get_oidc. For a complex configuration operation, this level of context is insufficient for an agent to fully understand the tool's impact.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all 9 parameters, giving 100% coverage. The description itself adds no parameter-specific information, so it does not improve upon the schema. Baseline of 3 is appropriate given the strong schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Configure' with a clear resource ('OIDC authentication') and target ('NKS cluster'). It clearly distinguishes this from the sibling tool ncloud_nks_get_oidc, which retrieves OIDC settings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 the complementary ncloud_nks_get_oidc tool, nor does it state any prerequisites or conditions for use.

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

• ncloud_pca_sign_sub_csrB
  3.2/5.0
  Behavior1/5

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

  The description says 'Sign a Sub CA CSR' which is a mutating operation (creating an intermediate CA certificate), but the annotations declare readOnlyHint: true. This is a direct contradiction. The description does not disclose any side effects, permissions, or lifecycle implications beyond what the annotation incorrectly claims.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no filler. It front-loads the action and purpose, making it easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the annotation contradiction and lack of output schema, the description fails to provide necessary behavioral context. It does not mention that this operation is irreversible, requires CA private key access, or that it creates a new certificate. The one-line description is insufficient for a PKI mutation tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 all three parameters (caTag, csrPem, period) adequately. The description adds minimal extra meaning—it implies the CSR is for a Sub CA and the CA signs it, but does not clarify parameter format or interactions beyond schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Sign') and a specific resource ('Sub CA CSR'), and clearly states the outcome ('to issue an intermediate CA certificate'). It distinguishes itself from sibling tools like ncloud_pca_sign_end_csr by explicitly targeting Sub CA CSRs rather than end-entity CSRs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case (when you need to issue an intermediate CA certificate from a Sub CA CSR) but does not explicitly state when to use this tool versus alternatives, such as ncloud_pca_sign_end_csr or ncloud_pca_issue_end_cert. No exclusions or prerequisites are mentioned.

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

• ncloud_pipeline_list_sourcecommit_branchesB
  3.2/5.0
  Behavior2/5

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

  The readOnlyHint annotation already signals a safe read operation. The description adds no behavioral details beyond that—no mention of return format, pagination, scoping, or any constraints. The phrase 'for pipeline configuration' only indicates intent, not behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no filler. It front-loads the action and resource, and every word earns its place. It could optionally include alternative tool references, but its brevity is appropriate for a simple operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only one parameter, full schema coverage, and a readOnly annotation, the description is minimally sufficient. However, since there is no output schema, it doesn't explain what the response contains (e.g., branch names, metadata), and it offers no guidance on edge cases or prerequisites. It's adequate but not rich.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the sole parameter (repositoryName with a clear description). The description does not add anything beyond the schema, so it meets the baseline but provides no extra semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List) and resource (branches of a SourceCommit repository), with an added purpose clause ('for pipeline configuration'). It is unambiguous about what the tool does, though it doesn't explicitly differentiate from similar siblings like ncloud_sourcecommit_list_branches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'for pipeline configuration' phrase implies the tool is intended for pipeline setup scenarios, but there is no explicit guidance on when to use this versus related list-branch tools, nor any exclusions. Usage context is implied rather than stated.

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

• ncloud_put_scaling_policyB
  3.2/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries the full burden of disclosing behavioral traits. It only says 'Create or update' without explaining side effects, idempotency, permission requirements, error conditions, or impact on existing policies. This is insufficient for a mutating operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no wasted words. It efficiently conveys the core action and resource. Every word earns its place, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and empty annotations, the description must provide more context. It lacks information about when to use the tool, behavior on existing policies, prerequisites, or how adjustment types affect outcomes. The minimal description leaves significant gaps for an agent trying to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each of the 6 parameters having a description. The tool description adds no additional parameter semantics, but it does not need to since the schema is comprehensive. This aligns with the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create or update') and the resource ('a scaling policy for an Auto Scaling Group'), which is specific and distinguishes it from related sibling tools that list, delete, or execute scaling policies. The verb+resource combination is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or references to sibling tools such as ncloud_list_scaling_policies or ncloud_delete_scaling_policy. The description simply states what it does without contextualizing usage.

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

• ncloud_query_widget_previewB
  3.2/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, and the description's 'Query' aligns with a read-only operation. The phrase 'by specifying metrics directly' adds a bit of context about how it works, but the description doesn't disclose response format, pagination, or other behavioral traits. It adds some value but not rich context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 10 words, front-loaded with the verb 'Query'. It is concise, free of fluff, and gets straight to the point. While more context could be added elsewhere, the structure itself is exemplary.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 7 parameters, no output schema, and only a terse description, the tool lacks essential surrounding context. The description doesn't explain what 'widget preview data' means, how the output is returned, or when to use this over other query tools. The readOnlyHint and schema cover some gaps, but the description alone is insufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 7 parameters have schema descriptions, so the schema does the heavy lifting. The description's 'by specifying metrics directly' maps to the 'metric' parameter but adds no new meaning beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool does 'Query widget preview data from Cloud Insight' with the qualifier 'by specifying metrics directly'. It names a specific verb and resource, which is clear, but it doesn't explicitly contrast with sibling tools like ncloud_query_monitoring_data or ncloud_get_dashboard_widgets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 exclusions, prerequisites, or related tools, despite the large sibling list containing similar query and dashboard tools. Usage context is entirely absent.

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

• ncloud_ses_add_nodeB
  3.2/5.0
  Behavior2/5

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

  The description only states the action; it doesn't disclose that this is a scaling operation that may take time, incur costs, or require the cluster to be in a specific state. The annotation provides destructiveHint: false, but the description adds no behavioral context beyond that.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It directly states the action and target, making it easy to parse and understand.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and minimal annotations, the description carries the burden for behavioral disclosure. It lacks prerequisites, operation duration, billing implications, and any constraints or limitations. An agent would need to guess the operational context, making this incomplete for a tool that modifies a cluster.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema (addDataNodeCount as 'Number of data nodes to add' and serviceGroupInstanceNo as 'Cluster instance number'), which covers 100% of parameter semantics. The description doesn't add any additional parameter details, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource ('Add data nodes to a Search Engine Service cluster'), clearly identifying the action and target. It distinguishes itself from sibling tools like ncloud_ses_change_node_spec or ncloud_ses_delete_cluster by focusing on adding data nodes specifically.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention that this is for scaling out a cluster, nor does it contrast with changing node specifications or creating a new cluster. An agent has no criteria for selecting this tool over related operations.

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

• ncloud_ses_create_snapshotB
  3.2/5.0
  Behavior2/5

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

  With only destructiveHint: false in annotations, the description carries the burden of disclosing behavioral traits. It merely states 'create a snapshot' without explaining whether the operation is asynchronous, what side effects occur, whether the bucket must already exist, or what the response/result will be. This is a significant gap for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence that conveys the essential purpose with no unnecessary words. It is concise and well-structured, stating the action and the target resource directly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description lacks important contextual details for an agent to use the tool correctly: it doesn't specify prerequisites, expected outcomes, or how this manual snapshot creation fits with related snapshot features (e.g., scheduled snapshots). The absence of an output schema makes the lack of return-value information more impactful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: bucketName is described as 'Object Storage bucket name for snapshot storage' and serviceGroupInstanceNo as 'Cluster instance number'. The tool description adds no additional parameter meaning beyond the schema, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Create) and the resource (a snapshot of a Search Engine Service cluster), using a specific verb and resource that distinguishes it from sibling tools like ncloud_ses_get_snapshot_history or ncloud_ses_set_snapshot_schedule. The scope is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, such as whether it is for manual snapshots as opposed to scheduled snapshots, or if any prerequisites (e.g., existing bucket or cluster state) are required. No alternative tools are mentioned.

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

• ncloud_set_block_storage_protectionB
  3.2/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the annotations. It does not explain that return protection prevents deletion, that the tool can enable or disable protection, or any side effects. While annotations provide idempotentHint and destructiveHint, the description itself is a one-liner that offers no additional insight into the tool's behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, concise and directly to the point. It contains no wasted words, though it could include more contextual detail without becoming verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, has full parameter documentation, and annotations cover idempotency and non-destructiveness. However, the description does not explain what 'return protection' means or its implications, leaving a gap in understanding for an agent unfamiliar with the domain. It is minimally adequate but not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters clearly described (e.g., 'true to protect, false to unprotect' for isReturnProtection). The tool description does not add any extra meaning beyond the schema, so the baseline of 3 stands.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Set return protection for a block storage instance' clearly specifies the verb (set), the resource (block storage instance), and the attribute (return protection). It effectively distinguishes from sibling tools like ncloud_nks_set_return_protection and ncloud_set_nas_volume_return_protection by naming the exact resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. The description does not mention related tools or provide any contextual hints about when setting return protection is appropriate, making it purely declarative without usage direction.

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

• ncloud_sourcebuild_start_buildB
  3.2/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, covering safety traits. However, the description adds no additional behavioral context such as whether the build runs asynchronously, whether it can fail due to concurrent builds, or what side effects occur beyond starting. No contradiction exists, but the description contributes nothing beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although the tool is simple and the schema covers the parameter, the description lacks essential context such as when to use it, how it relates to cancel_build or get_build_history, and what the agent should expect (e.g., asynchronous execution). The description is too minimal for a complete operational understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers the only parameter (projectId) with a clear description 'Project ID to build' (100% schema coverage). The tool description adds no additional meaning to the parameter, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Start a build for a SourceBuild project' uses a specific verb ('Start') and clearly identifies the resource (build) and scope (SourceBuild project). It distinguishes itself from sibling tools like ncloud_sourcebuild_cancel_build (which cancels) and ncloud_sourcebuild_get_build_history (which reads).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, whether a project must exist, or contrast with cancel_build or get_build_history. The agent receives no context for selection.

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

• ncloud_sourcedeploy_create_scenarioB
  3.2/5.0
  Behavior2/5

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

  The only annotation is destructiveHint=false, which aligns with the create action but adds little. The description does not disclose behavior like idempotency, potential overwrites, required permissions, or what is returned on success. It adds no context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that directly states the tool's purpose with no filler or redundancy. Every word contributes meaningful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of the config object and the lack of an output schema or deeper annotations, the description is insufficient. It does not explain what a deployment scenario is, how the config should be structured, or what happens after creation. The tool appears to be part of a larger workflow, but no surrounding context is provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline applies. The description itself does not enrich parameter understanding; it merely repeats 'stage' from the schema. The 'config' parameter is a complex nested object, but the schema's description ('source, deployment strategy, commands, etc.') is the only semantic content.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create') and the resource ('a new deployment scenario'), with a location qualifier ('in a stage'). This is specific enough to distinguish it from sibling tools like edit_scenario, delete_scenario, and list_scenarios.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites such as needing an existing project and stage. The description only states what it does, not in which context it should be invoked.

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

• ncloud_sourcedeploy_reject_deployB
  3.2/5.0
  Behavior2/5

  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 only states the action without noting whether the rejection is reversible, what side effects it has, or whether the deployment request must be in a specific state. This is insufficient for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the core action without any extraneous words. Every word earns its place, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the existence of sibling tools in an approval/deployment workflow, the description lacks context about when rejection applies and what the outcome is. With no output schema and no annotations, the tool is under-specified for correct selection and invocation, especially for an agent unfamiliar with the workflow.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents all three parameters (projectId, stageId, scenarioId) with clear descriptions, achieving 100% coverage. The description adds no additional parameter semantics beyond what the schema provides, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Reject') and the resource ('a scenario deployment request'), which distinctly sets it apart from sibling tools like approve_deploy or cancel_deploy. 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.

  Usage Guidelines2/5

  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 such as cancel_deploy or approve_deploy. It does not mention the approval workflow context or any prerequisites or conditions that should be met before rejection.

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

• ncloud_upgrade_mysql_versionB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden for behavioral disclosure, but it only says 'Upgrade'. It does not mention possible downtime, irreversibility, version compatibility steps, or any operational side effects. This is a significant gap for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It efficiently states the tool's core purpose in a clear structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no annotations and no output schema, this description is under-specified. It lacks operational context such as downtime, prerequisites, version constraints, or response format, leaving the agent without critical information to safely invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of the parameters with descriptive text, so the baseline is 3. The description itself adds no parameter-level details beyond what the schema already provides, but the schema does a good job explaining fields like isMajorVersionUpgrade.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Upgrade') and the target resource ('DB engine version of a Cloud DB for MySQL instance'). It distinguishes this tool from siblings that upgrade other resources (e.g., ncloud_ses_upgrade_version, ncloud_nks_upgrade_cluster) by specifically naming MySQL instances.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, nor does it mention prerequisites like the need to specify an instance number or image product code. The only hint is the verb 'Upgrade', but there is no explicit context or exclusion.

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

• ncloud_wms_get_resultsB
  3.2/5.0
  Behavior2/5

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

  The description merely restates that this is a read operation ('Get'), which is consistent with readOnlyHint=true, but adds no behavioral context beyond that. It does not disclose return format, aggregation behavior, filtering semantics, pagination, or rate limits, providing little value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that directly states the tool's purpose with no filler, redundancy, or irrelevant detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 6 parameters, 2 enums, and no output schema, the one-sentence description is insufficient. It does not explain what the returned monitoring results contain, how aggregation types work, or how to distinguish this from ncloud_wms_get_result_detail. The rich schema descriptions partially compensate, but the description lacks essential context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all 6 parameters with 100% coverage, including enums for type and resultStatus. The description's mention of 'WMS scenario' and 'time range' only echoes schema fields and adds no new parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves monitoring results for a WMS scenario over a time range. The plural 'results' and domain scope differentiate it from sibling tools like ncloud_wms_get_result_detail, which focuses on a single result detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus alternatives such as ncloud_wms_get_result_detail or ncloud_wms_get_monitor. The phrase 'over a time range' weakly implies a time-bounded query, but there are no exclusions or alternative recommendations.

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

• ncloud_add_acg_inbound_ruleB
  3.3/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond what the destructiveHint=false annotation already conveys. It does not state whether the rule is immediately applied, whether duplicate rules are prevented, or what the API response contains. For a mutation tool, this is a minimal level of transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It immediately communicates the action and target, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich input schema, the description is minimally viable but lacks operational context. It does not mention return values (no output schema) or the distinction from outbound rule addition, which would help an agent fully understand the tool's role. The moderate complexity (7 params, conditional rules) is partially addressed by the schema, but the description alone would be insufficient for a new user.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all seven parameters, including conditional requirements (e.g., portRange required for TCP/UDP) and mutual exclusivity (ipBlock vs accessControlGroupSequence). The tool description itself does not add any parameter semantics, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Add' and the resource 'inbound rule to an Access Control Group'. The word 'inbound' differentiates it from the sibling tool ncloud_add_acg_outbound_rule, making the tool's specific role unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, such as ncloud_add_acg_outbound_rule. It also does not mention any prerequisites (e.g., needing an existing ACG or VPC). The only implied usage is from the tool name itself, which is insufficient for an agent to choose confidently.

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

• ncloud_add_nic_acgB
  3.3/5.0
  Behavior2/5

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

  The description only restates the action already evident from the tool name and annotations. With destructiveHint:false already declaring non-destructiveness, the description adds no additional behavioral context such as idempotency, effect on existing ACGs, or required permissions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence of eight words, front-loading the action and resource without unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with full schema coverage and an annotation, the description is minimally adequate but lacks details about the operation's effect on existing ACGs or failure conditions, which would be valuable for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes both parameters (networkInterfaceNo and accessControlGroupNoList). The description adds no extra meaning beyond the schema, so it meets the baseline for complete schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a clear verb 'Add' and specifies the resource 'access control groups (ACGs)' and target 'network interface'. This unambiguously distinguishes it from sibling tools like ncloud_remove_nic_acg.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_remove_nic_acg. The description simply states the action without prerequisites or exclusions, leaving the agent to infer usage from the name.

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

• ncloud_add_postgresql_usersB
  3.3/5.0
  Behavior2/5

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

  With only destructiveHint=false provided, the description adds no behavioral context beyond the annotation. It does not disclose what happens if a user already exists, whether the operation is idempotent, or any prerequisites. The description merely restates the action without revealing operational implications.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  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 resource. It is concise, free of unnecessary words, and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate for a simple add operation with full schema coverage, but it lacks usage guidelines and behavioral context. Given the presence of many sibling tools with similar names, the description alone may not fully prepare an agent to choose and invoke this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for both parameters with 100% coverage. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Add users') and the specific resource ('Cloud DB for PostgreSQL instance'), which distinguishes it from sibling tools for other database engines (e.g., MySQL, MongoDB) and from related PostgreSQL operations like change/delete/list users.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 that this creates new database users, nor does it point to change_postgresql_users for modifying existing users or delete_postgresql_users for removing them. There is no context about prerequisites or when this operation is appropriate.

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

• ncloud_attach_network_interfaceB
  3.3/5.0
  Behavior2/5

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

  The annotations already declare idempotentHint=true and destructiveHint=false, so the agent knows the operation is safe and repeatable. However, the description adds no extra behavioral context such as prerequisites, side effects, or state changes beyond the literal action, and does not mention anything about server/interface states.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One concise sentence with no redundancy or filler; clearly front-loaded with the action. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple two-parameter operation, the schema provides complete parameter descriptions, and annotations cover safety traits. However, the description omits usage context and behavioral nuances such as whether the network interface must be detached first or if the server must be in a specific state, leaving the overall context slightly incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully covers both parameters with clear descriptions, and the description aligns with them. No additional parameter details are needed beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific action verb 'Attach' with a clear resource 'network interface' and target 'server instance', making it distinct from sibling operations like detach_network_interface, create_network_interface, and add_nic_acg. It fully identifies what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_detach_network_interface or ncloud_create_network_interface. The description simply states the operation without context on prerequisites, state requirements, or alternative actions.

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

• ncloud_attach_policy_to_sub_accountB
  3.3/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, so the agent knows the operation is safe to retry and non-destructive. The description adds no extra behavioral context, such as whether existing policy assignments are replaced or appended, or what response is returned. 'Assign' is vague about the effect on existing policies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states the action and target without any wasted words. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with only two well-documented parameters and informative annotations, so the description is mostly adequate. However, it lacks guidance on usage alternatives and does not disclose the effect on existing policy assignments, making it slightly incomplete for an agent deciding between attach/detach operations or handling retries.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with clear descriptions for both subAccountId and policyIdList. The tool description adds nothing about parameter semantics beyond what the schema already provides, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('assign'), the resource ('IAM policies'), and the target ('sub account'), which distinguishes it from sibling tools like attach_policy_to_group. It is a specific, unambiguous statement, though it closely paraphrases the tool name without additional nuance.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case: you use this tool when you want to assign IAM policies to a sub account. However, it does not explicitly state when not to use it or mention alternatives such as the sibling tool ncloud_attach_policy_to_group for group attachments.

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

• ncloud_cdss_change_node_specB
  3.3/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the annotations. Annotations declare idempotentHint=true and destructiveHint=false, but the description does not disclose potential side effects like node restarts, downtime, or constraints on changing specs while the cluster is active. It simply restates the core function without enriching the safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It efficiently expresses the core purpose, though it is minimal; given the schema and annotations carry details, this level of conciseness is appropriate.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  As a mutation tool with no output schema, the description leaves significant gaps: it doesn't state whether both node types can be changed simultaneously, how to obtain valid product codes, or what response to expect. The optional parameters are not explained, and the impact on the cluster (e.g., rolling update) is omitted, making it incomplete for an agent to safely invoke.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already documented (e.g., 'New broker node product code', 'Cluster instance number'). The description adds no extra meaning beyond the schema, so the baseline score of 3 applies; it neither clarifies node type relationships nor explains optionality.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Change server spec') and the target resource ('nodes in a CDSS cluster'), using a specific verb and resource combination. It distinguishes from sibling tools like ncloud_cdss_get_node_spec (read vs. change) and ncloud_ses_change_node_spec (different service).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when you want to change server specs in a CDSS cluster) but provides no explicit guidance on prerequisites, exclusions, or alternatives. For example, it doesn't mention checking current specs via ncloud_cdss_get_node_spec or using product code lookup tools, so the usage context is only implied.

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

• ncloud_cdss_enable_public_endpointB
  3.3/5.0
  Behavior2/5

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

  The annotations already declare idempotentHint=true and destructiveHint=false, and the description does not add any additional behavioral context such as side effects, required permissions, or network implications. It only repeats the action from the name.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no filler, front-loading the key verb and resource. Every word contributes to meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter enabling operation with annotations, the description is adequate but lacks context on prerequisites, what 'public endpoint' means in this CDSS context, or any expected effects on broker nodes. It is not misleading but leaves room for interpretation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with a single required 'serviceGroupInstanceNo' described as 'Cluster instance number'. The description does not mention parameters, but with full schema coverage the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Enable public endpoint for broker nodes' uses a specific verb (Enable) and resource (public endpoint) with a clear scope (broker nodes). It distinguishes itself from siblings like ncloud_cdss_disable_public_endpoint and ncloud_cdss_enable_public_domain by clearly indicating the action and target.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description only states the action; it does not provide when-to-use or when-not-to-use guidance, nor does it mention alternatives such as enabling a public domain or disabling the endpoint. No exclusions or prerequisites are noted.

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

• ncloud_cdss_get_kafka_configB
  3.3/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint: true, and the description's 'Get' verb is consistent with that, so there is no contradiction. However, the description adds no additional behavioral context beyond the read-only nature, such as what the returned settings contain, error behavior, or rate limits. With annotations covering the safety profile, this is a minimal but acceptable level of transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that conveys the essential purpose without any filler or redundant information. It is front-loaded with the action and resource, making it easy to parse and use.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, no output schema), the short description is somewhat adequate, but it lacks details about the return value structure or typical usage context. The absence of any differentiation from similar sibling tools and the lack of mention of what 'Kafka configuration settings' includes leaves some gaps in completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage for the single parameter configGroupNo, whose description ('Config group number') is clear. The tool description does not add any extra semantic detail about the parameter, but the schema already provides sufficient information, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get Kafka configuration settings for a Config Group' clearly states the action (get) and the resource (Kafka configuration settings for a Config Group). It is specific enough to convey the core purpose, though it does not explicitly differentiate from sibling tools like ncloud_cdss_get_config_group_detail, which may also return configuration-related information.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as ncloud_cdss_get_config_group_detail or ncloud_cdss_change_kafka_config. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent without decision support.

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

• ncloud_cdss_get_monitoringB
  3.3/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already informs the agent this is a safe read operation, lowering the bar. The description adds the scope 'cluster and its nodes' but gives no further behavioral detail such as what metrics are included, time range handling, or response format. It does not contradict the annotation, so a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the action and resource. Every word contributes value and there is no fluff. It is optimally sized for a simple read operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a basic read tool with good annotations and full schema coverage, the description is adequate but leaves gaps. It does not specify what monitoring metrics are returned, nor does it differentiate from the similar 'ncloud_cdss_get_os_monitoring' tool. Given the simplicity and the presence of the sibling, a score of 3 reflects that it is minimally complete but lacks useful context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all three parameters have descriptions in the schema. The description 'Get monitoring metrics for a CDSS cluster and its nodes' adds nothing about parameter semantics beyond implying the cluster is specified by serviceGroupInstanceNo. Baseline 3 is correct since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get'), the resource ('monitoring metrics'), and the scope ('CDSS cluster and its nodes'). It is specific and understandable. However, it does not explicitly differentiate from the closely related sibling tool 'ncloud_cdss_get_os_monitoring', which also deals with monitoring for CDSS.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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. There is a sibling tool 'ncloud_cdss_get_os_monitoring' that seems to overlap, but the description does not clarify the distinction (e.g., cluster-level vs OS-level metrics). No exclusions or context are given, leaving the agent to guess when each is appropriate.

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

• ncloud_cdss_rolling_restart_precheckB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false, so the description carries a lower burden. The phrase 'Pre-check' aligns with these hints but adds no extra behavioral context, such as what the check entails, what it returns, or whether it is a required gate before restart.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description consists of a single, lean sentence that directly states the tool's purpose. There is no fluff, repetition, or unnecessary detail, making it highly efficient and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description should explain what the pre-check result looks like or how to interpret it, but it doesn't. It also lacks mention of preconditions or relationship to the rolling restart flow. For a simple one-parameter tool, it is minimally viable but has clear informational gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for the only parameter, serviceGroupInstanceNo, with a description 'Cluster instance number'. The tool description adds no additional meaning 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Pre-check before performing a rolling restart' clearly identifies the tool as a pre-check for a specific operation. It uses a specific verb-resource pairing and distinguishes it from siblings like ncloud_cdss_rolling_restart and ncloud_cdss_rolling_restart_status, though it doesn't detail what exactly is checked.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool vs alternatives. It implies it should be used before a rolling restart but gives no explicit guidance, exclusions, or comparison to related tools like ncloud_cdss_rolling_restart_status or ncloud_cdss_upgrade_precheck.

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

• ncloud_cdss_rolling_restart_statusB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no additional behavioral context beyond what the annotations provide, such as what progress status looks like or whether it can be polled. It is consistent with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that directly states the tool's function. Every word earns its place, with no extraneous information or repetition of the tool name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple status query with one parameter and clear annotations, the description is minimally adequate. However, there is no output schema, so the description could have explained what the returned progress status looks like or how to interpret it. The lack of return value information leaves a gap for an agent consuming this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the single parameter 'serviceGroupInstanceNo' with the description 'Cluster instance number', so schema coverage is 100%. The tool description does not add any further semantic detail about the parameter, but the baseline of 3 is appropriate since the schema carries the burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action as 'Get' and the resource as 'progress status of a rolling restart operation'. This distinguishes it from sibling tools like ncloud_cdss_rolling_restart (which initiates the restart) and ncloud_cdss_upgrade_status (which checks upgrade status). However, it could be more explicit about the target cluster or operation context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., after initiating a rolling restart) or exclusions (e.g., not for upgrade status). The description relies entirely on the tool name for context, which is insufficient for an agent deciding between related status tools.

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

• ncloud_change_mongodb_secondary_countB
  3.3/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, covering safety profile. The description adds no extra behavioral context such as whether the change causes downtime, how existing data is affected, or whether the operation is asynchronous. It simply restates the action without disclosing additional traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that directly conveys the tool's purpose. It contains no filler or redundant information, earning full marks for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple mutation tool with complete schema descriptions and good annotations, the description is adequate but not complete. It lacks information about return values or operational impact (e.g., whether the instance goes through a rolling change), though such details are not strictly necessary given the straightforward action and schema coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all four parameters documented (e.g., memberServerCount 'Number of member servers (2-7)', arbiterServerCount 'Number of arbiter servers (0-1)'). The description adds no additional meaning beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Change') and resource ('number of Secondary (Member/Arbiter) servers in a MongoDB instance'), clearly conveying what the tool does. It distinguishes itself from sibling tools like 'change_mongodb_mongos_count' and 'change_mongodb_shard_count' by focusing on secondary servers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, nor does it mention any preconditions or use cases (e.g., scaling MongoDB secondaries). It is not misleading, but lacks any explicit context for tool selection.

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

• ncloud_create_mssql_slaveB
  3.3/5.0
  Behavior2/5

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

  Annotations only include destructiveHint=false, which is minimal. The description adds no behavioral context beyond the literal 'Create' action—no mention of asynchronous processing, prerequisites, side effects, or error cases. This leaves the agent without insight into the operation's behavior beyond its existence.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the action and target. Every word 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple create operation with complete schema coverage, the description is minimally adequate, but it omits expected return values (no output schema) and any usage context. The lack of behavioral detail further limits completeness, though the core purpose is clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides complete descriptions for all three parameters (100% coverage), so the baseline of 3 applies. The tool description itself does not elaborate on parameters, but the schema fully documents them.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create') and the target resource ('a slave server instance for a Cloud DB for MSSQL instance'). The resource is specific enough to distinguish from sibling tools like ncloud_create_mysql_slave, though it doesn't explicitly contrast with them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when creating a MSSQL slave), but provides no explicit context about prerequisites, alternatives, or exclusions. It is purely a statement of purpose without additional usage guidance.

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

• ncloud_create_roleB
  3.3/5.0
  Behavior2/5

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

  The annotations already declare destructiveHint=false, and the description's dryRun mention duplicates the schema's parameter description. No additional behavioral context (e.g., required permissions, side effects on existing roles) is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with no filler. It front-loads the core action and adds a practical safety tip.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the schema covers all parameters, the description is minimal. It lacks usage guidance and broader context about role creation, but for a non-destructive create operation with a preview option, it is adequate yet not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% description coverage across all six parameters. The description adds no new parameter meaning beyond what the schema already states, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Create a new IAM role,' identifying the specific verb and resource. This distinguishes it from sibling tools like ncloud_list_roles and ncloud_delete_role.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_list_roles or ncloud_delete_role. The only usage hint is 'Use dryRun=true to preview without creating,' which is more about safe invocation than tool selection.

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

• ncloud_dns_create_domainB
  3.3/5.0
  Behavior2/5

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

  The only annotation is destructiveHint=false, and the description does not contradict that. However, the description discloses no additional behavioral traits: it does not mention that the created domain might need activation/apply, what state it enters after creation, or any name constraints beyond the schema. The verb 'Create' implies a mutation but adds little beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with zero filler. It immediately states the action and resource, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter tool with complete schema and no output schema, the description is mostly sufficient. However, it misses workflow context: a newly created Global DNS domain likely needs to be applied (see sibling ncloud_dns_apply_domain) to become effective, yet this is not mentioned. An agent might assume creation alone fully activates the domain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% – both 'name' and 'comment' have descriptive text. The tool description itself adds no parameter-specific meaning, so it receives the baseline score of 3 for a fully documented schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Create a new Global DNS domain', which is a specific verb (create) and resource (Global DNS domain). It distinguishes from siblings like ncloud_dns_create_records (records) and ncloud_dns_delete_domain (deletion).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, follow-up steps (e.g., applying the domain via ncloud_dns_apply_domain), or cases where a different tool would be more appropriate. The agent must infer usage solely from the name.

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

• ncloud_dns_create_recordsB
  3.3/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the verb 'Create'. Annotations only include destructiveHint=false, which indicates non-destructive but does not clarify batch behavior, idempotency, validation, or whether existing records are affected. The description carries a low disclosure burden but fails to add any meaningful behavioral traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It immediately states the action and target resource, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a simple create operation with a rich schema that documents all parameters. However, the description lacks context about multiple record creation (array input), how to obtain domainId, or any caveats about record types. It is minimally complete but leaves gaps for an agent to infer behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are well-documented in the schema. The description itself does not add additional parameter semantics, making the baseline 3 appropriate. No parameter meanings are explained beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Create DNS records for a specific Global DNS domain'. The verb 'Create' and resource 'DNS records' are specific, and 'for a specific Global DNS domain' adds scope. This distinguishes it from sibling tools like ncloud_dns_update_records and ncloud_dns_delete_records.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided about when to use this tool versus alternatives. The verb 'Create' implies usage when creating DNS records, but there is no mention of prerequisites (e.g., domain must exist), exclusions, or comparison with update/delete tools. This is essentially no guidance beyond the tool's name.

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

• ncloud_dns_update_recordsB
  3.3/5.0
  Behavior3/5

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

  The annotations (idempotentHint: true, destructiveHint: false) already indicate safety for retries and non-destructive behavior. The description adds no additional behavioral context, such as whether the operation replaces the entire record set or updates individual records, but it does not contradict 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the essential action without redundant words. It is appropriately concise and free of filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple update tool, the description is minimally sufficient given the rich schema and annotations. However, it omits important context such as the need to obtain existing record IDs (e.g., via list_records) and whether the records array replaces or patches existing entries. This could lead to incorrect invocation without additional research.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides complete descriptions for both parameters (domainId and records), including nested record fields. The description adds no extra semantic value beyond what the schema already documents, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Update') and resource ('DNS records') for a specific domain. However, it does not explicitly differentiate from the sibling tools ncloud_dns_create_records and ncloud_dns_delete_records, though the verb 'update' implies modification of existing records.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like create or delete records. It does not mention prerequisites (e.g., needing existing record IDs) or scenarios where this tool is appropriate, leaving the agent to infer usage from the tool name alone.

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

• ncloud_drm_get_siteB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this as a safe read operation, and the description aligns with that. However, the description adds no behavioral context beyond 'detailed information' — it does not mention what fields are returned, whether the site must be enabled, or any other behavioral traits. Given the annotation covers the safety profile, this is acceptable but minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that gets straight to the point. There is no redundant wording, and the key information (action + resource) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple read tool with one parameter and a readOnlyHint annotation. The input side is well covered by the schema. However, since there is no output schema, the description's phrase 'detailed information' is vague and does not specify what aspects of the site are returned (e.g., status, configuration, policy associations). This is a moderate gap, but overall the tool is simple enough that the description is minimally viable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the single parameter (siteId) with a clear explanation that it comes from ncloud_drm_list_sites. Since schema description coverage is 100%, the description adds nothing beyond what the schema already provides. The baseline 3 applies because the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('detailed information about a specific DRM site'), clearly indicating a read operation for a single site. It distinguishes from siblings like ncloud_drm_list_sites, ncloud_drm_create_site, and ncloud_drm_update_site by implying a specific site rather than a list or mutation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives. It does not mention that it complements ncloud_drm_list_sites, or that it is for retrieving details rather than creating/updating. The schema parameter description hints at a prerequisite (siteId from ncloud_drm_list_sites), but the description itself provides no usage context.

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

• ncloud_functions_list_packagesB
  3.3/5.0
  Behavior2/5

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

  The annotation readOnlyHint=true already establishes this is a safe read operation, so the description does not need to restate that. However, the description adds no additional behavioral context: no mention of platform scoping (the platform parameter defaults to 'vpc'), pagination, response format, or any constraints. The term 'all' could be misleading given the platform filter, but that nuance is not addressed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a one-sentence, front-loaded statement with no filler. Every word is essential and it is easy to scan. It is appropriately sized for the tool's simplicity, achieving maximum conciseness without losing clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has low complexity, a readOnly annotation, and a single documented parameter. But the description omits the platform-scoping behavior introduced by the schema, which is a relevant operational detail. There is also no output schema to clarify return structure, so the description carries the burden of implying what 'list' returns, but it only says 'list packages'. Overall, it's adequate but has visible gaps regarding platform filtering and return semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the only parameter 'platform' with enum values and a default, so schema description coverage is 100%. The tool description adds no extra meaning about parameters—it doesn't explain how platform affects the result set. This meets the baseline for high schema coverage, but doesn't enhance understanding beyond what's already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and explicitly names the resource 'Cloud Functions packages'. It clearly distinguishes this from sibling tools like ncloud_functions_get_package (which retrieves a single package) and create/delete_package (mutations). The word 'all' clarifies it is a collection-listing operation, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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. There is no mention of scenarios (e.g., 'when you need to enumerate all packages'), no prerequisites, and no exclusions. The only implied usage is the obvious one—list packages—so there is no explicit or contextual guidance beyond the action itself.

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

• ncloud_get_cache_target_subnetsB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares the operation is read-only, and the description's 'List' verb aligns with that. The description adds the context that subnets are specifically for a Cache instance, but does not disclose details like pagination, response shape, or prerequisites. With annotations covering the safety profile, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 10 words, front-loaded with the verb 'List'. It is efficient with no redundant wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a straightforward list operation with read-only annotation and no output schema. The description explains the core action, but it leaves gaps such as what makes a subnet 'available' (e.g., same VPC as the instance), whether regionCode defaults, and the expected response format. For a simple tool, this is moderately complete but not fully specified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema documents both parameters with descriptions (regionCode as 'Region code (KR, KRS)' and cloudCacheInstanceNo as 'Cloud Cache instance number'). Since schema coverage is 100%, the description doesn't need to add much, and it doesn't—it only references 'specific instance' which maps to cloudCacheInstanceNo. No further parameter semantics are provided beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists subnets available for Cloud DB for Cache within a specific instance, using a specific verb and resource. It distinguishes itself from sibling tools like ncloud_get_cache_target_vpcs (VPCs vs subnets) and other services' target_subnets by naming 'Cloud DB for Cache.' However, it doesn't explicitly mention alternatives or edge cases.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided for when to use this tool versus alternatives. There is no mention of using it when selecting subnets for a Cache instance, nor any exclusions. The sibling tools include analogous functions for MySQL/PostgreSQL/MongoDB, but the description doesn't clarify when this specific one is needed.

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

• ncloud_get_contract_usage_listB
  3.3/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, so the read-only nature is already disclosed. The description adds useful context about the returned content (metering type, usage quantity, service period) and the 3-month limit. However, it does not disclose pagination behavior or any other non-obvious aspects, and there is 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action 'Get contract usage list', and includes the key return details and constraint without any redundant wording. Every sentence adds value and the structure is efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema is rich and the readOnly annotation is present, but the description is minimal for a tool with 12 parameters and no output schema. It does not explain pagination, default page size, or how this tool differs from similar contract-related list tools. The description provides a basic understanding but leaves gaps for effective selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 12 parameters have detailed descriptions in the schema, so schema coverage is 100%. The description adds no extra parameter semantics beyond what the schema already provides, such as the meaning of 'per contract' or 'specified months' which map to existing contractNo and month fields. This meets the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get contract usage list' and lists specific return fields (metering type, usage quantity, service period) for specified months. It is specific and unambiguous, but it does not explicitly distinguish from sibling tools like ncloud_get_contract_usage_list_by_daily or ncloud_get_contract_summary_list, so it lacks sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 only mentions the 3-month range constraint, which is a parameter limitation rather than usage guidance. There are no explicit when-to-use or when-not-to-use instructions.

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

• ncloud_get_extended_statusB
  3.3/5.0
  Behavior3/5

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

  The description is consistent with the readOnlyHint annotation, and it adds the resource context (Extended Metric collection status). However, it does not disclose additional behavioral details such as what the status values mean, whether filtering is applied, or any response format nuances. Given the annotation already declares a safe read operation, this is a baseline acceptable disclosure 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no redundant or irrelevant content. It efficiently communicates the tool's purpose without wasting tokens.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple read operation with two well-described parameters and no output schema, the description provides adequate context on what the tool returns ('Extended Metric collection status'). However, it does not explain what 'status' entails or how to interpret the response, leaving some ambiguity for an agent unfamiliar with Cloud Insight. Still, for a getter of this simplicity, it is minimally sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides complete descriptions for both parameters: prodKey as 'Product key (cw_key)' and servers as 'Server instance numbers to check.' The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate since the schema covers all parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' with a clear resource: 'Extended Metric collection status for servers in Cloud Insight.' It identifies the domain (Cloud Insight) and scope (servers), distinguishing it from generic monitoring tools. However, it does not explicitly differentiate from sibling tools like ncloud_query_monitoring_data or ncloud_search_metric_list, so it falls 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.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or related tools. The description only states what the tool does, leaving the agent to infer usage context from the name and schema.

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

• ncloud_get_log_export_historyB
  3.3/5.0
  Behavior2/5

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

  The annotation readOnlyHint=true already discloses this is a safe read operation. The description adds no additional behavioral context, such as pagination behavior, result ordering, or what the history includes. It does not contradict the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no extraneous words, front-loading the core purpose effectively.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity and the presence of annotations and full schema coverage, the description is minimally adequate but lacks information about the returned history structure or any usage caveats. It is complete enough for a simple list operation but leaves some gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with each parameter (pageNo, pageSize, regionCode) having its own description and defaults. The tool description adds no parameter-specific information beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' and clearly identifies the resource as 'log export history in Cloud Log Analytics', which distinguishes it from sibling tools like ncloud_export_logs (which creates exports) and ncloud_list_export_buckets. The name itself is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_export_logs or ncloud_get_log_count_*. The description only states the action without explaining context, prerequisites, or when this tool is preferred.

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

• ncloud_get_mssql_target_subnetsB
  3.3/5.0
  Behavior2/5

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

  The readOnlyHint annotation already signals this is a safe read operation. The description adds no extra behavioral context beyond the purpose itself, such as filtering behavior, response format details, or constraints. It repeats the schema's scope without providing additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no wasted words. It is appropriately front-loaded, stating the verb and resource immediately, and earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing tool with good annotations, the description is adequate but minimal. It explains what it lists but does not elaborate on the return format or any additional semantics (e.g., whether it returns only unused subnets). Since there is no output schema, a bit more detail would have been beneficial, but the core function is clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes both parameters (cloudMssqlInstanceNo and regionCode), so the description does not need to add parameter details. It doesn't, and since schema coverage is 100%, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  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 resource ('subnets available for Cloud DB for MSSQL'), and adds the scope 'within a specific instance'. It effectively distinguishes this tool from general subnet listing tools and similar ones for other database types, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case (listing subnets for a particular MSSQL instance) but provides no explicit guidance on when to use it versus alternative tools, such as ncloud_get_mssql_target_vpcs or equivalent tools for other database engines. No exclusions or alternative recommendations are mentioned.

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

• ncloud_get_nas_volume_detailB
  3.3/5.0
  Behavior2/5

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

  The readOnlyHint annotation indicates a safe read operation, but the description adds no behavioral context beyond that. It does not disclose error behavior, response structure, or any additional operational characteristics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for the simplicity of the tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple one-parameter read-only nature, the description is functional but sparse. It does not explain what 'detailed information' includes, how to obtain the instance number, or what the response looks like, which limits completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage with a clear description of 'nasVolumeInstanceNo' as the NAS volume instance number to query. The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets detailed information about a specific NAS volume instance, using a specific verb ('Get') and resource ('NAS volume instance'). It distinguishes itself from list tools like ncloud_list_nas_volumes by emphasizing a single instance.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit usage guidance is provided. The description does not mention when to use this tool versus alternatives (e.g., list first, then get details), nor does it state any prerequisites or context for use.

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

• ncloud_get_nat_gateway_detailB
  3.3/5.0
  Behavior2/5

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

  The description adds minimal behavioral context beyond the readOnlyHint annotation. It simply repeats that it fetches details, without disclosing what specific data is returned, any error conditions (e.g., what happens if the instance does not exist), or rate limits. With annotations already signaling the read-only nature, the description should provide additional depth but fails to do so.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise, front-loaded sentence with no superfluous words. It states the action and object clearly, earning a perfect score for efficiency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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 well-documented parameter and no output schema, the description is minimally sufficient but not complete. It does not describe what 'detailed information' includes, nor does it mention typical use cases or output structure. The lack of an output schema means the description should compensate, but it does not, leaving some ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single parameter natGatewayInstanceNo, with a clear description 'NAT Gateway instance number to query'. The tool description does not add further meaning to the parameter, but the baseline of 3 applies because the schema already documents it adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('NAT Gateway') with scope ('specific' and 'detailed information'), clearly distinguishing it from sibling tools like ncloud_list_nat_gateways (lists all) and ncloud_create_nat_gateway/delete_nat_gateway. It unambiguously communicates the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention that it should be used when a specific NAT Gateway instance number is known and a single entity's detailed data is needed, nor does it contrast with the list operation. The usage context is only implied by the tool name and sibling list.

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

• ncloud_get_process_pluginB
  3.3/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the readOnlyHint annotation. It does not disclose return format, errors, permissions, or pagination, and the 'specific server instance' scoping duplicates the schema parameter description.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One short, front-loaded sentence with no extraneous words. It efficiently conveys the verb, resource, and scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter get with no output schema, the description is minimally sufficient, but 'configuration' is vague and does not indicate what the returned data contains. It lacks explanatory richness but does not mislead.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for instanceNo, so the description adds no parameter-level meaning. The baseline of 3 applies because the schema already fully documents the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the resource ('process monitoring plugin configuration') scoped to a specific server instance. This distinguishes it from list/add/remove/set plugin siblings, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for a specific server instance' implies usage when targeting an individual instance, but no explicit when/when-not guidance or alternative tools are mentioned. Context is clear but exclusions are absent.

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

• ncloud_get_product_demand_cost_listB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds useful context: the 3-month period limit and the inclusion of discount breakdowns in the return. However, it does not disclose pagination behavior, error cases, or level of detail (e.g., whether results are aggregated per product or per product+service), so it is moderately helpful 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the main verb and resource, and every word adds value. It covers purpose, return contents, and a key constraint (max 3 months) in 27 words. No redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 8 parameters, no output schema, and only a read-only annotation, the description is moderately complete. It explains the core return (per-service billing amounts with discount breakdowns) but omits details about pagination (pageNo/pageSize), the meaning of access-scope parameters (isPartner, isOrganization, memberNoList), and how the productDemandTypeCode filter narrows results. Given the tool's complexity, this is a clear gap but not wholly inadequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 mentions 'max 3 months', which is already in the schema for endMonth ('max 3 months range'), adding no new meaning. The description does not clarify relationships between optional parameters (isPartner, isOrganization, memberNoList) or filter behavior, leaving the schema to do the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Get billing cost list grouped by product/service type.' It also details return contents (per-service billing amounts with discount breakdowns) and a period constraint (max 3 months). However, it does not explicitly differentiate itself from the many sibling cost tools (e.g., ncloud_get_demand_cost_list, ncloud_get_product_demand_cost_by_discount_list), so it lacks explicit sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need cost data grouped by product/service type, but it provides no explicit guidance on when to choose this tool over alternatives. Given the extensive list of sibling cost-related tools, this is a notable gap. No when-not-to-use or alternative tool names are mentioned.

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

• ncloud_get_root_password_listB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this as a read operation, and the description's 'List' is consistent with that. The description adds minimal behavioral context (the resource being listed) but does not disclose any additional traits such as pagination behavior, what 'can retrieve root password' implies (e.g., permission requirements), or how results are returned. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence with no filler or redundant wording. It is front-loaded with the main verb and object, making it easy to parse quickly. Despite being short, it conveys the essential purpose without unnecessary elaboration, which is appropriate for this simple tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple nature of the tool (3 optional params, readOnly annotation, no output schema), the description provides the core what-it-does statement. However, it lacks broader context about how this fits into the workflow (e.g., typically used before ncloud_get_root_password), what 'can retrieve root password' means operationally, and whether the list is all instances or only those with accessible passwords. The schema covers parameter details, so the description is minimally adequate but not fully contextual.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all three parameters (pageNo, pageSize, rootPasswordServerInstanceNoList), so the schema itself provides clear semantics. The description does not add any additional meaning beyond the schema, such as default values, parameter relationships, or formatting expectations, thus meeting the baseline but not exceeding it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('server instances that can retrieve root password'), which clearly indicates the tool's function. It distinguishes from the sibling tool 'ncloud_get_root_password' by focusing on listing eligible instances rather than retrieving a password, though it could be more explicit about that contrast.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as 'ncloud_get_root_password'. There is no mention of prerequisites, typical workflow (e.g., list instances first, then retrieve password), or whether filtering by server instance numbers is for narrowing results. The description leaves usage context entirely to inference.

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

• ncloud_get_server_imagesB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals a safe read operation. The description adds a constraint about supported hypervisor types, but does not disclose pagination behavior, default result size, or response structure. It is consistent with annotations but adds minimal extra behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states the core action and includes a useful parenthetical scope note. 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 11 optional parameters and no output schema, yet the description does not mention pagination, filter options, or that all parameters are optional. The Gen2/Gen3 note provides some scope context, but the description remains brief for a list operation with this many filters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all 11 parameters carry their own descriptions. The tool description does not add any extra parameter semantics beyond what is already in the schema, making the baseline score appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('server images'), and adds a scope note about Gen2 XEN and Gen3 KVM support. It is clear, though it doesn't explicitly call out distinctions from sibling tools like ncloud_nks_get_server_images or ncloud_ses_get_cluster_server_images.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives or service-specific image listing tools. The description simply states the function without context, prerequisites, or exclusions.

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

• ncloud_gtm_create_profileB
  3.3/5.0
  Behavior2/5

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

  The only annotation is destructiveHint=false, which is consistent with the description. However, the description adds no additional behavioral context such as idempotency, required permissions, or behavior on duplicate names. It does not contradict the annotations, but it also does not go beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a clear verb and resource. There is no redundant or unnecessary wording, making it highly concise for a simple create operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a straightforward create operation with a well-documented schema, but there is no output schema and no additional context about prerequisites, side effects, or success criteria. It meets the minimum viable standard but leaves some gaps for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% description coverage for all four parameters. The description itself adds minimal semantic value beyond the schema, merely noting that the profile is a domain, which is already captured in the 'name' parameter description. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (create) and the resource (a Global Traffic Manager profile, clarified as a domain). This distinguishes it from sibling tools like update, delete, list, and get profile.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an existing policy) or when to prefer create over update/delete. The usage is only implied by the verb 'Create'.

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

• ncloud_gtm_get_policy_resourcesB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares that this is a safe read operation, so the description does not contradict it. The description adds no additional behavioral context beyond what the annotation provides, but no further disclosure is needed for a straightforward GET operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that efficiently states the tool's purpose without any filler or redundant information. It is appropriately sized for a tool with one parameter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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 parameter, the description is minimally adequate. However, with no output schema, the agent is not informed about what 'resource details' entails (e.g., which resource types are included), leaving some ambiguity that could be clarified with a short explanation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for the single parameter (policyId with description 'Policy ID'), so the description is not required to compensate. The description's reference to 'a specific policy' aligns with the parameter but adds no new semantic information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb (Get) and resource (resource details for a specific Global Traffic Manager policy), making the tool's purpose immediately understandable. It distinguishes itself from list-oriented tools by specifying 'for a specific... policy', though it does not explicitly differentiate from the sibling tool ncloud_gtm_get_policy_detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives such as ncloud_gtm_get_policy_detail or ncloud_gtm_get_resource_types. The phrase 'for a specific policy' implies a prerequisite (having a policyId) but no clear context for choosing this tool over siblings.

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

• ncloud_gtm_get_query_countB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this as a safe read operation, so the description carries less burden. It adds the context that the data is 'time-series monitoring data,' which implies a temporal aggregation. However, it does not disclose details like filtering behavior, default domain selection, or response format beyond what the schema and annotation imply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that directly states the tool's function. No redundant words or filler. It is front-loaded with the action and resource, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only query tool with a fully documented schema and readOnlyHint annotation, the description is adequate. However, the absence of an output schema means the description should hint at return value structure; 'time-series monitoring data' is a minimal hint. It lacks details on how to interpret the data or specify a time range beyond baseTimeUnit.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters documented in the input schema. The description itself adds no parameter semantics beyond what the schema provides. The baseline of 3 applies since the schema handles the parameter documentation fully.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the resource ('GTM domain (profile) query count time-series monitoring data'). It identifies this as a monitoring data retrieval tool specific to GTM domains, which distinguishes it from other monitoring tools like ncloud_dns_get_query_count. However, it could be more explicit about the output type or that it returns a time series.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 prerequisites, context, or exclusions. Given the large number of sibling tools (e.g., ncloud_cdss_get_monitoring, ncloud_ses_get_monitoring), the lack of any usage direction is a significant gap.

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

• ncloud_hadoop_list_addonsB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already communicates the safe read-only nature, lowering the need for the description to repeat that. The description adds minimal context ('available') but does not disclose any additional behavioral traits such as filtering behavior or response scope.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. Every word contributes to clarifying what the tool does.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with annotations and complete parameter descriptions, the description is adequate but thin. It does not explain what add-ons are, how results are returned (no output schema), or any specifics about how the optional parameters affect the listing, leaving some ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters ('regionCode', 'cloudHadoopImageProductCode') are meaningful from their descriptions. The tool description adds no extra semantics beyond what the schema already provides, so it meets the baseline for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('available add-on components for Cloud Hadoop clusters'), making its purpose clear. It is reasonably distinct from sibling tools like ncloud_hadoop_list_image_products, though it does not explicitly differentiate itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, nor does it mention any prerequisites or context for choosing it over similar list tools. Usage context is only implied.

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

• ncloud_hadoop_list_cluster_typesB
  3.3/5.0
  Behavior2/5

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

  The annotation readOnlyHint=true already declares read-only behavior, and 'List' confirms it. However, the description adds no additional behavioral context such as pagination, return format, regional filtering semantics, or authentication requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of six words, perfectly concise and front-loaded. Every word contributes to the purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool, the description states the core function, but it does not explain the return structure (no output schema exists) or mention the typical use case (e.g., selecting types during cluster creation). Optional filters are documented in the schema, making it adequate but minimal.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (both parameters have descriptions), so the description does not need to repeat them. It does not clarify how 'cloudHadoopImageProductCode' filters cluster types, but the schema already labels it as a filter, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and identifies the resource 'available cluster types for Cloud Hadoop'. It clearly distinguishes from sibling tools like list_clusters (which lists actual clusters) and list_products (which likely lists service products).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as list_products or list_image_products. It does not mention prerequisites, typical use in cluster creation, or exclusions.

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

• ncloud_hadoop_list_notebook_componentsB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation declares this is a safe read operation, and the description is consistent with that. The description adds minimal context beyond the annotation—only the example of Jupyter versions hints at what the response contains. No additional behavioral details (pagination, auth, return structure) are disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One short, front-loaded sentence with zero wasted words. The verb 'List' leads immediately, and the parenthetical example adds useful specificity without bloat.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with full schema coverage and a readOnlyHint annotation, the description is minimally adequate. However, with no output schema, it could have explained the response format, and given the sibling tools, it could have clarified how 'components' differs from 'images' and 'products'.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so both parameters (regionCode, cloudHadoopImageProductCode) are already documented in the schema. The description adds no parameter-level meaning, meeting the baseline of 3 when the schema carries the full burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and identifies the resource as 'available notebook components' with a concrete example ('Jupyter versions'). However, it does not explicitly distinguish this from sibling tools like ncloud_hadoop_list_notebook_images or ncloud_hadoop_list_notebook_products, leaving potential ambiguity about what 'components' includes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No when-to-use guidance is provided. The description does not mention when this tool should be chosen over the similar Hadoop notebook listing siblings (list_notebook_images, list_notebook_products), nor does it note any prerequisites or exclusions.

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

• ncloud_kms_disable_auto_rotationB
  3.3/5.0
  Behavior2/5

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

  Annotations declare idempotentHint=true and destructiveHint=false, but the description adds no additional behavioral context such as reversibility, effect on scheduled rotations, or permission requirements. It provides no value beyond what annotations already convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that directly states the action. Every word earns its place, with no unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with annotations present, the description conveys the core purpose but lacks explanation of the effect on the key's rotation schedule or how it relates to other KMS rotation tools. It is minimally viable but leaves gaps in contextual understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% description coverage for the single parameter (keyTag), and the description adds no further parameter detail. Baseline 3 applies because the schema fully documents the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Disable') and clearly identifies the resource ('automatic key rotation for a KMS key'). It distinguishes this tool from sibling tools like ncloud_kms_enable_auto_rotation and ncloud_kms_rotate_key.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives such as ncloud_kms_enable_auto_rotation or ncloud_kms_update_rotation_period. The description simply states the action without providing context, prerequisites, or exclusions.

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

• ncloud_kms_enable_key_versionB
  3.3/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds no further behavioral context. It does not explain what happens if the version is already enabled, whether the operation is reversible, or any side effects on key lifecycle (e.g., canceling deletion schedules). The description relies entirely on the annotations and the verb itself.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no redundancy. It is front-loaded with the action and resource, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple state-change operation with full schema coverage and annotations, the description is minimally sufficient but leaves gaps: it does not mention key lifecycle context (e.g., enabling a disabled version, effect on rotation) or how this action differs from enabling the entire key. The tool is simple, but the description could offer more context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptive parameter definitions for keyTag ('unique identifier derived from key name') and version ('Key version number to enable'). The tool description adds no additional semantics beyond what the schema already covers, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Enable') and the specific resource ('a specific version of a KMS key'), making it distinct from sibling tools like ncloud_kms_disable_key_version or ncloud_kms_enable_key. The verb+resource combination is precise and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no guidance on when to use this tool versus alternatives such as ncloud_kms_enable_key (enabling the whole key) or ncloud_kms_disable_key_version. It neither mentions prerequisites (e.g., the version must be disabled) nor indicates any exclusions or preferred scenarios.

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

• ncloud_kms_get_acl_rule_listB
  3.3/5.0
  Behavior2/5

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

  The description adds no behavioral traits beyond the readOnlyHint annotation. It does not disclose any specific behavior such as what the list contains, ordering, pagination, or error conditions. The annotation already signals read-only, and the description merely confirms that with 'Get,' offering no additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that immediately states the action and resource. There is no redundant or unnecessary wording, and every word contributes meaning, making it an excellent example of conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one required parameter, and the description conveys the core function. However, there is no output schema, and the description does not describe the structure of the returned list (e.g., rule fields like IP, action, description). It also omits edge cases or prerequisites, making it adequate but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with keyTag described as 'unique identifier derived from key name.' The description does not add any extra meaning about the parameter, such as how to derive it or any format requirements. Since coverage is high, baseline is 3, and no value is added beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' and clearly identifies the resource: 'the list of IP ACL rules configured for a KMS key.' This distinguishes it from sibling tools like ncloud_kms_add_acl_rule and ncloud_kms_delete_acl_rule, which perform mutations, and it leaves no ambiguity about the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 that it is read-only or that to modify rules one should use add_acl_rule/delete_acl_rule. It only states what it does, not when to choose it, leaving the agent without clear usage direction.

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

• ncloud_kms_get_token_generatorB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates a safe read operation, so the bar is lower. The description adds minimal context beyond that (e.g., 'for a KMS key'), but does not disclose any additional behaviors such as response structure or error cases. It is consistent with the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no redundant words or filler. It front-loads the essential purpose and is appropriate for a simple read operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with one parameter and a read-only annotation, the description is minimally sufficient. However, with no output schema, it would benefit from a brief mention of what 'token generator information' includes or any notable return values, leaving some ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter keyTag, and the description does not add any meaning beyond what the schema already provides. The baseline of 3 applies since the description does not compensate with extra parameter detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (get) and resource (token generator information) within the context of a KMS key. It distinguishes itself from sibling tools like create/update/delete_token_generator by making the read intent explicit, though it does not name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus others, nor are any prerequisites or exclusions mentioned. The description simply states what it does without context for selection.

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

• ncloud_kms_signB
  3.3/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already communicates the non-mutating nature. The description adds useful constraints (8KB data limit, RSA2048/ECDSA key types) that are not in annotations. However, it does not disclose the return format or any error behaviors, which is a gap since there is no output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exactly two sentences, front-loaded with the core action and immediately followed by a key constraint. Every word earns its place; there is no redundant or vague language. It is concise and well-structured for quick agent parsing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (2 required params, both documented in schema) and annotations cover the read-only safety profile. However, the absence of an output schema means the description should have explained the return value or signature format, which it does not. The missing output detail prevents a higher score, though the basic operation is clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both data and keyTag having descriptions. The description repeats the '8KB' limit already present in the data parameter's schema description, adding no new parameter semantics. Thus, it does not go beyond what the schema provides, justifying the baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Generate a digital signature for data (up to 8KB)' with a specific verb and resource. It also adds a key type constraint (RSA2048 or ECDSA), which helps narrow scope. However, it does not explicitly differentiate from sibling tools like ncloud_kms_verify or ncloud_kms_encrypt, so it does not fully meet the highest bar.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description only states what it does and a key type constraint, not any preconditions (e.g., needing a compatible key) or exclusions. There is no mention of when to prefer sign over verify or other cryptographic operations.

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

• ncloud_kms_update_key_nameB
  3.3/5.0
  Behavior2/5

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

  Annotations already indicate idempotent and non-destructive behavior, but the description adds no additional behavioral context. It does not clarify that only the display name changes and the underlying key material remains unaffected, nor does it explain the relationship between keyTag and keyName during a rename.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence with zero redundancy. It is front-loaded with the core action and resource, making it extremely concise and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple operation with 2 parameters and helpful schema/annotations, the description is minimally viable. However, it omits useful context about side effects (e.g., whether the key tag changes, whether references remain valid) and does not explain the derivation of keyTag from keyName, which could confuse an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema (keyTag and keyName) with clear definitions, so the high schema coverage sets a baseline of 3. The tool description itself adds no parameter-level information, relying entirely on the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (update) and the resource (the name of a KMS key). It is specific and unambiguous, distinguishing itself from sibling tools like ncloud_kms_update_memo or ncloud_kms_update_rotation_period by targeting the key name itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 that it only updates the name, nor does it reference related tools or prerequisites such as how to obtain the keyTag.

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

• ncloud_kms_update_memoB
  3.3/5.0
  Behavior2/5

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

  Annotations already declare the operation as idempotent and non-destructive. The description adds no extra behavioral context (e.g., constraints, side effects, prerequisites) beyond restating the action, so it provides minimal value beyond the structured data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter update tool with annotations and a clear schema, the description is functional but lacks usage context, alternatives, or return-value information. It does not obstruct understanding but is not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive parameters. The description adds no additional meaning beyond what the schema already states about 'memo' and 'keyTag', 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('update') and resource ('memo/description of a KMS key'), making the tool's purpose clear. It is distinct from sibling KMS tools like update_key_name and update_rotation_period, 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the name and description: it should be used to update the memo field of a KMS key. However, no explicit when-to-use or alternative guidance is provided relative to other KMS update tools.

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

• ncloud_kms_update_rotation_periodB
  3.3/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is known. However, the description adds no additional behavioral context, such as whether the change takes effect immediately, whether it applies to all key versions, or any side effects. It merely restates the tool's purpose.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with zero waste. It is front-loaded and immediately communicates the tool's function, achieving high conciseness without missing critical information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter configuration update, the description is adequate, but it lacks usage context (when to use vs. related tools) and does not mention any return value or post-conditions. With annotations covering safety and schema covering parameters, the description is minimally sufficient but not enriched.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters (keyTag and rotationPeriod) having clear descriptions. The tool description adds no extra parameter detail, but the schema already provides sufficient meaning, making the baseline score of 3 appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Update') and resource ('auto rotation period for a KMS key'), clearly stating the action. It distinguishes from sibling tools like ncloud_kms_rotate_key (manual rotation) and ncloud_kms_enable_auto_rotation/disable_auto_rotation by focusing on the period itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives, such as enabling/disabling auto rotation or manually rotating a key. It lacks any prerequisites (e.g., whether the key must already have auto rotation enabled) or contextual triggers for invoking this tool.

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

• ncloud_list_cache_backupsB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates this is a safe read operation, so the description does not need to restate that. However, the description adds no additional behavioral context such as what list of backups is returned, whether it includes automatic backups, or any filtering/ordering behavior. With the annotation covering safety, a 3 is appropriate for a simple list operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that conveys the essential information without any wasted words. It is front-loaded with the verb 'List' and clearly names the resource, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with one parameter and a read-only hint, the description is minimally adequate. However, there is no output schema and the description does not clarify what fields or extent of backup information will be returned, nor does it contrast with the similar sibling ncloud_list_cache_backup_details. This leaves gaps for an agent deciding between these tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the single parameter cloudCacheInstanceNo with a description 'Cloud Cache instance number'. Since schema coverage is 100%, the description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 is warranted.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  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 'backups for a Cloud DB for Cache (Redis/Valkey) instance', making the primary purpose obvious. It does not explicitly differentiate from sibling tools like ncloud_list_cache_backup_details or ncloud_list_cache_manual_backups, so it loses a point for missing sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention whether this includes automatic and manual backups, nor does it point to ncloud_list_cache_backup_details for more detailed information. The description simply states the operation without any contextual usage direction.

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

• ncloud_list_cache_config_group_versionsB
  3.3/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the readOnlyHint annotation. It merely restates the tool's purpose with 'List available' and doesn't disclose pagination, default region behavior, or response format. No value is added beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that communicates the tool's function without unnecessary words. It is perfectly front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one optional parameter and a readOnly annotation, so the description is minimally adequate. However, it lacks context about what a 'config group version' is, how regionCode affects results, and what response format to expect (no output schema exists). This leaves some ambiguity for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the only parameter (regionCode) with 'Region code (KR, KRS)'. The description itself adds no parameter details, so it does not enhance what the schema already provides. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('Cloud Cache config group versions'), clearly distinguishing it from sibling tools like ncloud_list_cache_config_groups and ncloud_list_cache_instances. It states exactly what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. There are no exclusions, prerequisites, or mentions of related sibling tools. The only context is the readOnly annotation, which doesn't help with usage scenarios.

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

• ncloud_list_metrics_groupsB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that metrics groups are rule templates, but does not disclose behavior like optional filtering by prodKey, pagination, or the shape of the list response.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence with no redundant information. It front-loads the action and object, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one optional parameter, the description is minimally adequate, but it omits mention of the filter parameter and any return characteristics (e.g., whether it lists all groups by default). Since there is no output schema, a bit more context about the result would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: prodKey is described as 'Product key to filter metrics groups'. The description adds no additional parameter details, earning the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('Get the list') and the resource ('Cloud Insight rule templates / monitoring item groups / metrics groups'), providing a parenthetical to clarify terminology. However, it does not explicitly distinguish this tool from the sibling 'ncloud_list_monitor_groups', which may cause confusion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no guidance on when to use this tool versus alternatives such as 'ncloud_list_monitor_groups' or 'ncloud_get_metrics_group'. There is no mention of exclusions, prerequisites, or typical use cases.

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

• ncloud_list_mssql_log_filesB
  3.3/5.0
  Behavior2/5

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

  The annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. However, the description adds no behavioral details beyond the literal operation—no mention of return format, pagination, filtering, or any side effects. It essentially restates the tool's name, providing minimal additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, short sentence that efficiently conveys the operation. It is front-loaded with the verb 'List' and contains no unnecessary words, making it appropriately concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter and a read-only annotation, but the description does not describe the output format or any edge cases (e.g., whether all log files are returned, how results are sorted). Without an output schema, the agent must infer what a 'log file' listing entails. It is adequate for a basic list operation but leaves gaps in expectations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% parameter coverage with the description 'Cloud MSSQL server instance number'. The tool description does not add any additional semantic meaning (e.g., format, constraints, examples) beyond what the schema already offers, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List log files for a Cloud DB for MSSQL server instance' uses a specific verb ('List'), clearly identifies the resource ('log files'), and specifies the target ('Cloud DB for MSSQL server instance'). This distinguishes it from similar sibling tools like ncloud_list_mssql_log_backup_files, which is about log backup files rather than regular log files.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no guidance on when to use this tool versus alternatives such as ncloud_list_mssql_log_backup_files or ncloud_export_mssql_log. It simply states the action without any contextual usage notes or exclusions.

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

• ncloud_list_mysql_usersB
  3.3/5.0
  Behavior2/5

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

  The readOnlyHint annotation already signals a safe read operation, but the description adds no extra behavioral context such as pagination, response format, required permissions, or any side effects. It only repeats the basic listing function.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no redundant information. Every word contributes to defining the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with one well-documented parameter and a readOnly annotation, this is minimally adequate. However, since there is no output schema, the description could have mentioned what data is returned (e.g., user IDs, names) to make it more complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides complete coverage (100%) for the single parameter with a clear description ('Cloud MySQL instance number'). The tool description adds no further parameter guidance, so the schema carries the full burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and the specific resource ('users in a Cloud DB for MySQL instance'), making the tool's purpose unambiguous. It naturally distinguishes from sibling user-management tools like add/change/delete MySQL users.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_list_mysql_databases or ncloud_add_mysql_users. The description only states what it does, not when it's appropriate.

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

• ncloud_list_objectsB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already communicates the safe, read-only nature. The description adds the bucket scope but does not disclose behavioral traits such as pagination (marker, maxKeys), potential truncation, or that it returns only current object versions (not versions). Since annotations cover the safety profile, a middle score is appropriate, but the description could add more context about the listing behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of seven words: 'List objects in an Object Storage bucket'. It is front-loaded, unambiguous, and contains no filler or redundant content. It is appropriately concise for a simple list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 5 parameters and no output schema, the description is minimally adequate. It states the core purpose, and the schema covers parameter details. However, it lacks differentiating context (e.g., that this does not list versions) and gives no hint about the return shape or pagination behavior. Given the sibling `list_object_versions` tool, this is a notable gap in completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — every parameter (bucketName, marker, prefix, maxKeys, delimiter) has a full description. The tool description itself adds no parameter-level detail beyond what the schema provides. With high schema coverage, the baseline is 3, and no additional semantic value is offered.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'List objects in an Object Storage bucket'. It clearly states the action and target, but it does not explicitly distinguish from the sibling tool `ncloud_list_object_versions`, which lists object versions. The name `list_objects` vs `list_object_versions` provides implicit separation, but a 5 requires explicit differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives such as `ncloud_get_object` (retrieve a specific object), `ncloud_list_buckets` (list buckets), or `ncloud_list_object_versions` (list versions). The description provides no prerequisites, exclusions, or alternative tool references, leaving the agent to infer usage from the name and schema alone.

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

• ncloud_list_postgresql_logsB
  3.3/5.0
  Behavior3/5

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

  Annotations include readOnlyHint=true, and the description's 'List' verb aligns with a read-only operation. The description adds minimal context beyond the annotation, stating the object is 'DB server log files' but does not explain what is returned, any filtering capabilities, or region behavior. No contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the verb 'List' and clearly states the resource. No extraneous information or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description doesn't clarify what the returned list of log files looks like (e.g., file names, paths). It adequately conveys the core purpose but leaves expectations about return value structure unstated. Given the tool's simplicity and clear purpose, this is acceptable but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes both parameters (regionCode and cloudPostgresqlServerInstanceNo) with 100% coverage. The description itself adds no parameter-level details beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List) and the resource (DB server log files for a Cloud DB for PostgreSQL server instance). This makes the purpose unambiguous, though it does not explicitly differentiate from sibling tools like ncloud_export_postgresql_log or log listing tools for other database types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention that this tool is specifically for listing PostgreSQL log files, or that ncloud_export_postgresql_log should be used for exporting logs. The user must infer usage from the name.

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

• ncloud_list_route_tablesB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation covers the safety profile, and the description adds the 'current region' scoping detail. However, it does not disclose other behavioral traits such as response format, pagination, or that filtering parameters are available.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single succinct sentence that conveys the core purpose without unnecessary words. It is easily parsed and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list tool with no output schema, the description is minimal. It does not mention that results can be filtered, what fields are returned, or any limitations. While the schema provides parameter details, the description alone leaves some gaps for an agent deciding on invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for all four parameters. The description adds no additional meaning 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List), the resource (route tables), and the scope (current region). It is distinct from the related 'get_route_table_detail' and 'get_routes' tools, though it does not explicitly contrast with them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternative route table tools (e.g., ncloud_get_route_table_detail, ncloud_get_routes). The description does not mention filter usage, prerequisites, or exclusions.

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

• ncloud_list_scheduled_actionsB
  3.3/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, and the description aligns with that. The description does add the useful scoping detail that only 'not yet been executed' actions are included, but it does not disclose pagination behavior, response format, or behavior when no matching actions exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise sentence of 13 words, front-loaded with the verb 'List' and containing no filler or redundant phrases. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one well-documented parameter, the description is mostly adequate. However, since there is no output schema, the return shape, pagination, and ordering of results are not disclosed, leaving a notable gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter autoScalingGroupNo is fully described in the schema ('Auto Scaling Group number') with 100% schema coverage. The description adds no extra meaning 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.

  Purpose4/5

  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 clearly identified resource ('scheduled actions') and scope ('that have not yet been executed for an Auto Scaling Group'). This is clear and distinct from sibling tools like ncloud_put_scheduled_action or ncloud_delete_scheduled_action, though it does not explicitly reference those alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool vs alternatives, when not to use it, or prerequisites such as how to obtain the required Auto Scaling Group number (e.g., via ncloud_list_asgs). The description only states the basic operation without any contextual direction.

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

• ncloud_list_snapshotsB
  3.3/5.0
  Behavior2/5

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

  The annotation readOnlyHint: true already declares the operation is read-only. The description adds no extra behavioral context such as pagination behavior, default page size, ordering, or whether all snapshots are returned. It simply restates the listing function without expanding on observable behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no filler. It is front-loaded and easy to parse, making every word earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the schema covers parameters and annotations cover safety, the description lacks any context about when to use this tool versus similar snapshot listing tools. It also omits mention of pagination or filtering capabilities, which are part of the tool's expected behavior. For a simple list tool this is adequate but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All three parameters (pageNo, pageSize, blockStorageSnapshotInstanceNoList) have descriptions in the schema, achieving 100% coverage. The description itself does not elaborate on parameter meaning or usage, so it adds no extra semantics beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and the resource ('block storage snapshot instances'), making the tool's purpose immediately obvious. It also distinguishes itself from related tools like ncloud_list_nas_snapshots and ncloud_delete_snapshots by specifying the resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as ncloud_list_nas_snapshots or ncloud_get_snapshot_detail. There is no mention of pagination or filtering use cases, leaving the agent without context for selecting this tool.

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

• ncloud_ncr_get_tag_detailB
  3.3/5.0
  Behavior2/5

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

  The readOnlyHint annotation already indicates a safe read operation. The description adds no behavioral context beyond that, such as what fields are returned, authentication needs, or any rate limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 13 words, front-loaded with the verb and resource. No wasted words or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Adequate for a straightforward read tool, but it lacks any indication of what 'detailed information' includes (e.g., digest, size, creation time). Given no output schema, this would have been helpful for the agent to know what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of the parameters with clear one-line explanations (e.g., 'Tag name (reference) to query'). The description does not add any additional parameter semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' and identifies the exact resource: 'detailed information about a specific tag of a container image'. This clearly distinguishes it from sibling tools like list_tags or delete_tag.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as list_tags or get_image. The description merely states what it does without any contextual cues or exclusions.

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

• ncloud_ncr_update_imageB
  3.3/5.0
  Behavior2/5

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

  The annotations already declare idempotentHint=true and destructiveHint=false. The description adds no additional behavioral context, such as whether updating one field affects the other, overwrite semantics, or any side effects. It simply restates the action without enriching 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no unnecessary words. It is appropriately sized for a simple update operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With full schema coverage and annotations, the description covers the core purpose but leaves gaps: it does not clarify the relationship between the optional description and fullDescription fields, nor the expected response or behavior when no optional fields are supplied. No output schema is present, so return semantics are entirely unaddressed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all parameters, so the baseline is 3. The description does not add any meaning beyond the schema's parameter descriptions; it only mentions 'description' ambiguously without clarifying the separate description and fullDescription fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (update), the resource (container image description), and the location (registry). It distinguishes this tool from siblings like ncloud_ncr_delete_image or ncloud_ncr_get_image by specifying exactly what is updated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives or on prerequisites. It does not mention that description and fullDescription are optional or what happens if both are omitted. The description lacks context about the update scenario.

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

• ncloud_nks_reset_kubeconfigB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full responsibility for disclosing behavior. It indicates a mutating action ('reset') but does not explain side effects such as invalidating existing kubeconfig files, potential downtime, or required permissions. The lack of such detail is a significant gap for a write operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, straightforward sentence that gets directly to the point. It is appropriately concise with no redundant or irrelevant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the tool is simple with one parameter and no output schema, the description lacks essential context for a mutating operation. It explains what it does but not why or when it would be needed, nor the consequences. This is acceptable for a minimum viable description but leaves notable gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the only parameter (clusterUuid) with a clear description. The tool description adds no extra semantic value beyond restating that the operation targets a specified cluster. Baseline of 3 is appropriate given 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action (reset) and the resource (kubeconfig credentials for an NKS cluster). This distinguishes it from sibling tools like ncloud_nks_get_kubeconfig, which retrieves credentials, and other cluster management operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description only states what it does, not the situations that warrant resetting kubeconfig or any exclusions. This leaves the agent to infer usage from the name alone.

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

• ncloud_nks_update_access_entryB
  3.3/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds no behavioral context beyond the tool name. It does not explain whether kubernetesGroups are replaced or merged, whether the access entry must already exist, or what the response format will be. This is a minimal disclosure that adds no value 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.

  Conciseness5/5

  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 resource. It contains no filler or redundant wording, making it appropriately concise for a simple update operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple update tool with 3 parameters, all documented in the schema, and safe/idempotent annotations. However, the description omits which fields can be updated (e.g., kubernetesGroups) and does not state any preconditions or effects. It is minimally adequate but lacks completeness for an agent to fully understand the operation's behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with clear descriptions for clusterUuid, accessEntryNo, and kubernetesGroups. The description does not enrich the parameter meanings, but the schema already carries the burden, making this adequate per the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Update' and clearly identifies the resource as 'an IAM access entry for an NKS cluster'. This distinguishes it from sibling tools like create_access_entry, delete_access_entry, get_access_entry, and list_access_entries, which have different operations on the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as create_access_entry or delete_access_entry. It does not state prerequisites, exclusions, or context for when an update is appropriate. The only signal is the verb 'Update', which is implicit at best.

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

• ncloud_nks_update_secret_encryptionB
  3.3/5.0
  Behavior2/5

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

  There is no annotation contradiction; idempotentHint and destructiveHint are consistent with a non-destructive configuration update. However, the description adds no behavioral context beyond the annotations—it doesn't describe effects on existing encryption settings, cluster state requirements, or what happens if kmsKeyTag is omitted.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that states the core purpose. It is front-loaded and contains no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (2 params, no output schema) and existing annotations/schema coverage, the description is minimally adequate. However, it leaves ambiguity about the optional kmsKeyTag param and the exact behavior of 'configure' (e.g., enable, update, or disable encryption), so it is not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides full descriptions for both parameters (clusterUuid and kmsKeyTag), so the baseline is 3. The description adds no additional meaning about how the parameters interact or optionality, relying entirely on the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Configure') and the resource ('secret encryption for an NKS cluster'). It distinguishes from sibling tools like ncloud_nks_update_auth_type or ncloud_nks_set_oidc because no other tool targets secret encryption. The verb and object are 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.

  Usage Guidelines2/5

  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, nor any prerequisites or exclusions. It solely states what it does without context, leaving the agent to infer usage.

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

• ncloud_put_objectB
  3.3/5.0
  Behavior2/5

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

  With empty annotations, the description must disclose behavioral traits. It mentions dryRun preview but omits critical details for an upload operation, such as overwriting behavior, required permissions, or the effect on existing objects. This is a significant transparency gap for a write operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, front-loaded with the primary action. No extraneous words, and the dryRun hint is placed as a useful secondary note.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an upload tool with five schemas-described parameters and no output schema, the description is minimal but not dangerously incomplete. It lacks prerequisites (e.g., bucket existence) and return-value context, but the schema covers the parameter meanings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema documents all parameters. The description adds 'Use dryRun=true to preview,' which is redundant with the schema's dryRun explanation and does not clarify other parameters like body encoding or contentType.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb-resource pair ('Upload (put) an object to an Object Storage bucket') and distinguishes itself from siblings like get_object, delete_object, and list_objects. It also notes the dryRun preview, which is a clear behavioral scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as copy_object, initiate_multipart_upload, or upload_part. The description simply restates the tool's purpose without context or exclusions.

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

• ncloud_put_object_aclB
  3.3/5.0
  Behavior2/5

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

  Annotations are empty, so the description bears full responsibility for behavioral disclosure. It only says 'Set' without revealing side effects, idempotency, permission requirements, or that the existing ACL will be overwritten. No additional behavioral context is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's core purpose without unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple mutation tool with complete parameter documentation, the description is minimally viable. However, it lacks contextual details such as when to choose this over related tools, any behavioral caveats, or prerequisites (e.g., object existence), and there are no annotations or output schema to supplement.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter already has a clear description. The only semantic addition is 'using a canned ACL', which is already reflected in the 'acl' property's enum and description, providing no net new value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Set'), the resource ('access control list (ACL) of an object in Object Storage'), and the method ('using a canned ACL'). It distinguishes from sibling tools like ncloud_put_bucket_acl by explicitly mentioning 'object'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or point to related tools such as ncloud_get_object_acl or ncloud_put_bucket_acl for bucket-level ACL operations.

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

• ncloud_query_monitoring_dataB
  3.3/5.0
  Behavior3/5

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

  The `readOnlyHint: true` annotation already indicates this is a safe read operation. The description adds minimal behavioral context beyond stating that it returns metric data, but it does not disclose details such as time-range handling, default aggregation behavior, or any rate limits. It neither contradicts annotations nor adds substantial behavioral insight.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences that are front-loaded with the primary action. It contains no fluff or redundant detail, and every word contributes to conveying the tool's core function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only query tool with full schema coverage, the description is minimally adequate but leaves gaps: it does not describe the return value structure, how to interpret the time-series data, or the relationship between `cw_key` and `prodName`. However, the annotations and schema mitigate the absence of an output schema, so the description is acceptable but not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all parameters, so the schema already documents each field (e.g., `metric` examples, `interval` enums, `dimensions` structure). The description does not add any parameter-specific meaning beyond what the schema provides, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool queries time-series monitoring data from Cloud Insight for a specific product and metric. It uses a specific verb ('Query') and resource ('time-series monitoring data'), which distinguishes it from many non-monitoring tools, though it does not explicitly differentiate from the closely related sibling `ncloud_query_monitoring_data_multiple`.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as `ncloud_query_monitoring_data_multiple` or service-specific monitoring tools (e.g., `ncloud_cdss_get_monitoring`, `ncloud_ses_get_monitoring`). There is no mention of exclusions, prerequisites, or scenarios where this tool is the preferred choice.

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

• ncloud_remove_server_image_sharingB
  3.3/5.0
  Behavior2/5

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

  Annotations already provide destructiveHint=true and idempotentHint=true. The description's '⚠️ DESTRUCTIVE' repeats the destructive hint without adding new context such as irreversibility, permission requirements, or what exactly gets affected. The confirm=true instruction is already in the schema. Therefore no behavioral info 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence with a clear warning and instruction, front-loaded. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given its simplicity, the description covers the basic purpose and confirmation mechanism. However, it omits context such as required ownership/ACL permissions, reversibility, and any alternate tool guidance. For a destructive action, this is a notable gap, though annotations partially compensate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with each parameter having a clear description. The description adds no new parameter semantics beyond reiterating the confirm=true requirement, which the schema already specifies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Remove sharing permission for a server image' with a specific verb and resource, clearly distinguishing from add/set operations and from the member-server-image variant by naming 'server image' in the description.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives like ncloud_remove_member_server_image_sharing or ncloud_add_server_image_sharing. The description only mentions the confirm flag, which is a parameter instruction, not tool selection guidance.

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

• ncloud_send_monitoring_dataB
  3.3/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects, idempotency, rate limits, prerequisites, or error behavior. For a write operation, 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The single-sentence description is concise, front-loaded with the key action, and contains no filler. It earns its place, though it could be slightly more informative without becoming verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a nested schema and no output schema or annotations, and the description does not explain how to structure data entries beyond the schema, nor what happens after sending. It lacks context on return values, success criteria, and operational constraints, making it incomplete for a write operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for 100% of parameters, including nested fields like prodKey, data, metrics, and dimensions. The description adds no additional parameter semantics, but the schema coverage meets the baseline, so a score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Send), the resource (custom JSON monitoring data), and the destination (Cloud Insight), which distinguishes it from sibling query tools like ncloud_query_monitoring_data. The phrase 'user-defined metrics' adds specific scope, making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its use case (sending monitoring data for custom metrics) but provides no explicit guidance on when to prefer it over alternatives or any exclusions. With close sibling tools like ncloud_query_monitoring_data and ncloud_create_metrics_group, the usage context is only implicit.

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

• ncloud_ses_reset_passwordB
  3.3/5.0
  Behavior2/5

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

  With empty annotations, the description carries full responsibility for behavioral disclosure. It only states the action 'Reset' without mentioning side effects, permission requirements, reversibility, or impact on existing sessions—critical gaps for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that immediately states the purpose. No filler words, every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter reset operation with well-documented schema, this is minimally viable. However, the lack of behavioral transparency and usage guidance makes it incomplete for a mutation tool without annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides clear descriptions for both parameters ('Cluster instance number' and 'New admin password (8-20 chars)'), giving 100% coverage. The description adds no extra parameter meaning, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Reset the Search Engine admin account password' clearly states the specific action (reset) and target resource (Search Engine admin account password), distinguishing it from sibling tools like ncloud_cdss_reset_cmak_password and ncloud_nks_reset_kubeconfig.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, no prerequisites, and no exclusions. It only states the operation without contextual usage information.

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

• ncloud_set_nas_volume_return_protectionB
  3.3/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context, such as what enabling return protection actually does (e.g., prevents deletion) or any side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence with no redundant wording or unnecessary details. It gets straight to the point.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple configuration setter with full schema and annotations, this is minimally viable. However, it lacks context about what return protection means or when to use it, which limits completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters documented. The description adds no parameter-level detail beyond what the schema already provides, making baseline 3 appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Set' and clearly identifies the resource as 'return protection for a NAS volume instance'. This is distinct from other NAS operations like access control or size changes, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, what prerequisites exist, or how it compares to alternatives (e.g., ncloud_set_nas_volume_access_control). It simply states the action without contextualizing its typical use case.

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

• ncloud_set_subnet_network_aclB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, so the agent knows this is a safe, repeatable operation. The description adds no additional behavioral context, such as whether an existing ACL association is replaced or any side effects, but does not contradict 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the core purpose with zero wasted words. It is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with full schema coverage and safety annotations, the description is minimally adequate. However, it lacks context about behavior when a subnet already has an ACL or whether the network ACL must exist, leaving some gaps for a complex cloud environment.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers both parameters with descriptions (100% coverage), so the baseline is 3. The description does not add extra meaning beyond the schema; it only implies the parameters from the phrase 'for a subnet' and 'Network ACL'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Set the Network ACL for a subnet' clearly states the action (set) and the resource (Network ACL for a subnet). It is specific enough to distinguish from sibling tools like set_network_acl_description, though it does not explicitly mention that it assigns an existing ACL to a subnet.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. There are no mentions of prerequisites, valid scenarios, or exclusions, which is a clear gap given the large set of sibling tools.

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

• ncloud_sourcedeploy_get_canary_analysis_reportB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint: true annotation matches the 'Get' verb, so no contradiction. The description does not provide additional behavioral context beyond what annotations already convey, such as error behavior, response contents, or permissions. With annotations covering safety, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It is concise but slightly under-specified; however, it is not verbose or bloated. It earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description should at least hint at what the report contains, but it does not. It also lacks context about the canary analysis workflow, such as how to get step numbers or how this report relates to canary approval/rejection. This is minimal for a tool with 4 required parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so a baseline of 3 is appropriate. The description adds no extra meaning beyond the schema, such as whether stepNo is 0-based or 1-based, or any format expectations. The parameter descriptions in the schema are sufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Get), the resource (canary analysis report), and the scope (for a specific step). It distinguishes itself from siblings like ncloud_sourcedeploy_get_canary_analysis_steps, which retrieves all steps, by focusing on a single step's report.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided. The description does not mention when to use this tool versus alternatives, how to obtain the stepNo, or any prerequisites such as first calling get_canary_analysis_steps. It only implies the tool is for retrieving a report for a known step.

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

• ncloud_sourcedeploy_get_scenarioB
  3.3/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, and the description simply says 'Get detailed information', which is consistent with a read operation. The description adds no behavioral context beyond the annotation—no mention of response format, pagination, required permissions, or error cases.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that immediately communicates the tool's purpose. It contains no redundant wording or unnecessary detail, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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 could explain what 'detailed information' includes, but it does not. The tool is a simple getter with three self-explanatory parameters and a read-only annotation, making it minimally sufficient, yet it leaves expectations about the response and the hierarchical relationship between projectId, stageId, and scenarioId unexplained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage with each parameter (projectId, stageId, scenarioId) clearly defined. The description itself adds no additional semantic meaning beyond what the schema already provides, so it meets the baseline but does not enhance parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' and resource 'detailed information about a specific deployment scenario', clearly indicating a read operation for a single scenario. It differentiates from sibling tools like list_scenarios by emphasizing 'specific', though it does not enumerate what the detailed information includes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The wording 'specific deployment scenario' implies this tool is used when you already have the scenarioId and need details, as opposed to listing scenarios. However, there is no explicit guidance on when to use this versus alternatives like list_scenarios or get_stage, and no exclusions or prerequisites are stated.

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

• ncloud_sourcedeploy_get_sourcecommit_branchesB
  3.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this as a safe read operation. The description merely says 'Get', which is consistent with the annotation but adds no additional behavioral context (e.g., whether pagination is supported, whether default branches are included, or any rate limits). There is no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that conveys the essential purpose without any filler. It is appropriately sized and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one parameter, read-only, no output schema), and the description covers the basic operation. However, the lack of differentiation from similar sibling tools and absence of any additional context (e.g., which repository types apply, whether it is scoped to sourcedeploy projects) leaves some gaps. It is adequate but not rich.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the only parameter, repositoryName, is described as 'Name of the SourceCommit repository'. The description text does not add any extra parameter context beyond what the schema already 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the resource ('list of branches in a SourceCommit repository'). It is unambiguous about what the tool does, though it does not differentiate from sibling tools like ncloud_sourcecommit_list_branches or ncloud_pipeline_list_sourcecommit_branches, which may serve similar purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives (e.g., ncloud_sourcecommit_list_branches). The description does not provide context for when this sourcedeploy-specific variant is appropriate, nor does it mention any exclusions or dependencies.

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

• ncloud_stop_serverB
  3.3/5.0
  Behavior3/5

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

  Annotations declare idempotentHint=true and destructiveHint=false, and the description does not contradict them. The description adds that target instances are 'running' but does not explain the post-stop state, restartability, or side effects. With annotations covering safety, this is acceptable but not deeply informative.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that efficiently conveys the action and scope. There is no repetition, filler, or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With one required parameter, idempotent and non-destructive annotations, and a clear sentence, the description is minimally sufficient. However, it lacks information about expected results (e.g., operation status or how to verify) and how to obtain server instance numbers, which would aid an agent in a full workflow.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the sole parameter serverInstanceNoList as a list of server instance numbers to stop. The description adds no additional format, constraints, or semantic detail beyond the schema, so the baseline for high schema coverage applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb (Stop) and resource (running server instances) and clearly indicates support for multiple instances. It does not explicitly distinguish from sibling lifecycle operations like ncloud_interrupt_server or ncloud_terminate_server, but the core 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.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_start_server, ncloud_reboot_server, ncloud_interrupt_server, or ncloud_terminate_server. The description only states the action without any usage context or exclusions.

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

• ncloud_update_maintenanceB
  3.3/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false. The description adds minimal behavioral context beyond the word 'existing', which is redundant given the required maintenanceId parameter. No mention of side effects, permissions, or return details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no redundant words. It is concise and front-loaded with the core action and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a relatively simple update tool with a 100% schema coverage and non-destructive/idempotent annotations, the description is minimally sufficient. However, it does not explain the behavior of the 'dimensions' nested object, nor does it mention what the tool returns, leaving some gaps for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are already documented with descriptions. The description does not add additional meaning to any parameter, but the schema handles the semantics adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Update' and the resource 'existing planned maintenance schedule', which is specific and distinguishes from sibling create/delete/list/get tools. It also adds context 'in Cloud Insight'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus creating, deleting, or listing maintenance schedules. The description merely states the action without mentioning alternatives or prerequisites.

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

• ncloud_add_member_server_image_sharingB
  3.4/5.0
  Behavior2/5

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

  Annotations only declare destructiveHint=false, but the tool is still a mutation operation. The description does not disclose whether sharing is additive or replaces existing permissions, whether the operation is idempotent, or what happens if permissions already exist. It adds no behavioral context beyond the basic action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the core action and resource. There is no redundancy or filler; every word contributes to understanding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no output schema and minimal annotations, the description is too sparse. It omits important contextual details such as whether the operation is additive, whether target accounts must exist, or any error conditions. The agent lacks sufficient information to predict side effects or verify success.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters clearly documented in the schema. The description's phrase 'specified accounts' maps to targetLoginIdList but adds no additional semantic detail beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Add sharing permission'), the resource ('member server image'), and the target ('specified accounts'). It distinguishes itself from sibling tools like ncloud_add_server_image_sharing by explicitly naming 'member server image'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied by the action verb 'Add' - an agent can infer this is for granting sharing access. However, there is no explicit comparison with alternatives like ncloud_set_member_server_image_sharing or ncloud_remove_member_server_image_sharing, and no prerequisites or exclusions are mentioned.

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

• ncloud_attach_policy_to_groupB
  3.4/5.0
  Behavior2/5

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

  The description adds no behavioral information beyond the annotations. Annotations already declare idempotentHint=true and destructiveHint=false, and the description only restates the operation without disclosing whether it replaces existing policies, requires specific permissions, or affects group members. No contradiction exists, but no extra context is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that directly states the tool's purpose without redundant words. It front-loads the action and is easily scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (two required string parameters, no output schema, and annotations covering idempotency and non-destructiveness), the description is mostly complete. It clearly conveys the core function. However, it does not clarify whether the operation is additive or replaces existing policy attachments, which could be relevant for users. This minor gap prevents a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes both parameters (groupId and policyIdList) with clear descriptions, achieving 100% schema coverage. The tool description does not add additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Assign IAM policies to a group' clearly specifies the action (assign), the object (IAM policies), and the target (group). It distinguishes this tool from sibling tools like ncloud_attach_policy_to_sub_account and ncloud_detach_policy_from_group by naming both the resource and the recipient.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 scenarios where attaching policies to a group is preferred over attaching to a sub-account, nor does it reference detach operations or any prerequisites. The tool name suggests usage, but the description itself lacks explicit usage context.

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

• ncloud_cdss_get_node_specB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already communicates that this is a safe read operation. The description adds the qualifier 'current', which implies it returns live state rather than options, but it does not disclose details like return format, pagination, or whether all nodes are included. This modest addition is consistent with the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It states the verb and object clearly, making it easy to parse at a glance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 parameter and a clear purpose, the description is sufficiently complete. It explains what is returned (server spec details for nodes) and the required input (cluster instance). No output schema exists, but the description gives enough context for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the single parameter serviceGroupInstanceNo described as 'Cluster instance number'. The tool description does not add further parameter-specific meaning, but it confirms the parameter identifies the cluster for which node specs are retrieved. This matches the schema baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Get') and resource ('server spec details for nodes in a CDSS cluster'), making the tool's purpose unambiguous. It does not explicitly distinguish from sibling tools like ncloud_cdss_get_server_spec_list, but the focus on 'current ... details for nodes' provides enough differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_cdss_get_server_spec_list or ncloud_cdss_get_cluster_detail. The description does not mention any conditions or exclusions, leaving the agent without decision support.

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

• ncloud_change_mysql_specB
  3.4/5.0
  Behavior2/5

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

  The description is limited to the change operation and does not disclose behavioral details such as downtime, rolling upgrade behavior, permission requirements, or effects. Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds no additional behavioral context beyond that.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that front-loads the verb and resource, with no unnecessary words. It effectively communicates the core purpose without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the bare description, the tool definition benefits from complete parameter descriptions, annotations declaring idempotent and non-destructive behavior, and a clear purpose. It lacks an output schema and does not describe response format, but that is not required given the rich schema and annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all four parameters (100% coverage), including details about defaults and rolling upgrade behavior. The tool description itself adds no parameter-level information, so it does not go beyond the schema baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool changes the CPU/Memory specification of a Cloud DB for MySQL instance, using a specific verb ('Change') and resource ('server spec of Cloud DB for MySQL'). It distinguishes itself from sibling tools like ncloud_change_server_spec (general servers) and ncloud_ses_change_node_spec by specifying MySQL.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, such as ncloud_upgrade_mysql_version or ncloud_change_mysql_users. It does not mention prerequisites, such as requiring an existing instance, or exclusions, like when a different MySQL modification tool should be used. Parameter hints exist but do not constitute usage guidelines.

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

• ncloud_create_custom_schemaB
  3.4/5.0
  Behavior2/5

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

  Annotations only include destructiveHint: false, so the description carries the burden of behavioral disclosure. It adds no information about idempotency, validation rules, failure modes, or any side effects beyond the generic 'create'. The description essentially restates the operation without enriching the agent's understanding.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence with no filler or redundancy. It front-loads the action and resource, and every word contributes to the intended meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  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 a non-trivial nested fields parameter, yet the description provides no workflow context, return value expectations, or usage notes. It does not explain what a custom schema is for beyond 'custom metrics', why prodName is an array, or how field types map to metrics. The agent would need to rely heavily on the schema and external knowledge.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter having a basic description (e.g., fieldType enum, prodName as product names). The description text adds no extra parameter semantics, but the schema already provides adequate names and types, meeting the baseline for adequate coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create'), the resource ('a user-defined custom schema'), and the context ('in Cloud Insight for custom metrics'). This verb+resource+context pattern makes the tool's purpose specific and distinguishable from siblings like ncloud_update_product_schema or ncloud_create_custom_resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case via 'for custom metrics' but does not explicitly state when to use this tool versus alternatives or mention any exclusions or prerequisites. It provides enough context to infer purpose but stops short of clear guidance relative to the large sibling set.

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

• ncloud_create_deny_allow_groupB
  3.4/5.0
  Behavior2/5

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

  The description only restates the action with no additional behavioral detail. The annotation 'destructiveHint=false' is present, but the description adds nothing about return values, side effects, or required permissions. For a write operation, this is a minimal level of transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence with no fluff, directly stating the purpose. Every word earns its place and the tool is easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple create operation with a well-documented schema, the description is sufficient to understand the action and invoke it. However, it lacks any context about what a Deny-Allow Group is or how it relates to Network ACLs, and there is no output schema to describe return values, so it's not a perfect 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all 3 parameters with descriptions (100% coverage), so the baseline is 3. The description's phrase 'in a VPC' adds no new parameter semantics beyond the schema's vpcNo description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create') and clearly identifies the resource ('Network ACL Deny-Allow Group') and scope ('in a VPC'). It distinguishes from sibling list/get/delete/set tools, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, prerequisites (e.g., existing VPC), or alternatives like 'set_deny_allow_group_ips' for subsequent configuration. The agent is left without context for selecting this over other Deny-Allow Group operations.

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

• ncloud_create_mssql_instanceB
  3.4/5.0
  Behavior3/5

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

  The annotation destructiveHint=false is consistent with a create operation. The description adds the dryRun behavior, which is useful, but it does not disclose whether the operation is synchronous, what happens on success, or potential cost implications.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with no wasted words. It front-loads the primary purpose and adds a single actionable tip about dryRun.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a complex tool with 20 parameters, no output schema, and only a minimal annotation. The description does not mention return values, required setup steps, or how to choose among the many parameters. It relies entirely on the schema for context, which is insufficient for a creation tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 all parameters. The description adds no parameter-specific detail beyond repeating the dryRun flag's schema description, which provides minimal additional value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Create a new Cloud DB for MSSQL instance' with a specific verb and resource. It clearly indicates the tool creates an MSSQL instance, distinguishing it from related sibling tools like create_mssql_slave or list_mssql_instances.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 only mentions a dryRun flag but does not explain prerequisites, when to prefer creating a slave, or when to query existing instances first.

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

• ncloud_delete_rule_group_by_idB
  3.4/5.0
  Behavior2/5

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

  The description repeats the `destructiveHint` annotation with a warning emoji but provides no additional behavioral context. It does not disclose the confirmation requirement, idempotency details, side effects, or consequences beyond 'delete'. With annotations already providing the destructive hint, this adds no new transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise sentence with a clear warning prefix. Every word is purposeful, no filler, and the structure front-loads the destructive warning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite being minimal, the tool is simple and the schema/annotations cover the critical confirm flag and destructive/idempotent hints. The description is complete enough for an agent to understand the core operation, although it omits explicit mention of confirm=true, which is still available in the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All parameters are documented in the schema (100% coverage), and the description does not add any parameter-specific meaning. The phrase 'by product key and rule group ID' maps to the existing schema fields but adds no details beyond the schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States the exact operation: 'Delete a Cloud Insight event rule by product key and rule group ID.' This is a specific verb (Delete) and resource (Cloud Insight event rule) with the method of identification (product key and rule group ID), which distinguishes it from generic `delete_rule_group` and other rule-group related siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives like `ncloud_delete_rule_group` or `ncloud_delete_metrics_group_by_id`. The description only restates the operation and does not mention prerequisites, exclusions, or alternative tool choices. Implied usage is only that it needs product key and rule group ID.

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

• ncloud_drm_update_siteB
  3.4/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, establishing a safe, repeatable update. The description adds no behavioral context such as prerequisites (site must exist), effects on streaming, or validation of the FairPlay certificate. It does not contradict the annotations but provides little value beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, nine words long, and front-loaded with the action verb. Every word is meaningful, with no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is too terse for a tool with a nested fairPlayCert object and three required fields. It fails to clarify that policyId and siteName are required even when only updating the certificate, which could mislead an agent. There is no output schema, and the description does not address return values or side effects, leaving important gaps despite schema coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All four parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description's mention of 'policy binding, name, or FairPlay certificate' loosely maps to policyId, siteName, and fairPlayCert, adding some grouping but no additional semantics or clarity about required fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Update' and clearly identifies the resource as 'DRM site', further enumerating the updatable aspects (policy binding, name, or FairPlay certificate). This distinguishes it from sibling tools like ncloud_drm_create_site, ncloud_drm_get_site, and ncloud_drm_enable_site.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies an existing site via the 'Update' verb and lists what can be changed, but it lacks explicit when-to-use guidance or alternatives. It does not mention that policyId and siteName are required even when only updating the certificate, nor does it reference sibling tools to help an agent choose correctly.

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

• ncloud_export_mssql_backupB
  3.4/5.0
  Behavior1/5

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

  The annotation readOnlyHint=true contradicts the description's 'Export... to Object Storage', which implies a side-effectful write operation. The description adds no further context about permissions, asynchronous execution, or the actual impact, leaving the contradiction unresolved.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long and front-loaded with the primary function. The second sentence provides actionable guidance without any fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description omits critical behavioral details such as whether the export is asynchronous, what the response contains, or any required preconditions (e.g., bucket existence). Combined with the contradictory readOnlyHint annotation, the tool is under-described for an agent to fully understand its side effects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 adds value by connecting the cloudMssqlExportObjectList parameter to ncloud_list_mssql_backup_details, explaining where to obtain the file names for that list.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Exports Cloud DB for MSSQL backup files to Object Storage.' It uses a specific verb (export), resource (MSSQL backup files), and target (Object Storage), which distinguishes it from similar tools like ncloud_export_mssql_log.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a helpful prerequisite by directing users to ncloud_list_mssql_backup_details for available file names, but it does not explicitly state when to use this tool over alternatives (e.g., ncloud_export_mssql_log) or mention any exclusions.

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

• ncloud_export_mysql_logB
  3.4/5.0
  Behavior1/5

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

  The annotation readOnlyHint=true indicates no state changes, but the description says 'Export... to Object Storage,' which implies a write operation. This is a direct contradiction, scoring 1 per the rubric.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, zero fluff, front-loaded with the action. Very concise and well-organized.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description omits return value semantics (no output schema) and does not mention whether the export is asynchronous or requires special permissions. Combined with the annotation contradiction, the description is not complete enough for a 6-parameter side-effecting tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all 6 parameters. The description adds a pointer to ncloud_list_mysql_logs for obtaining the fileName, providing minimal additional context beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Export'), the resource ('Cloud DB for MySQL server log file'), and destination ('Object Storage'). It distinguishes from sibling export tools for other DB types (e.g., ncloud_export_postgresql_log) by specifying MySQL.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly directs the user to use ncloud_list_mysql_logs to discover available log files, providing a clear prerequisite and usage hint. It does not, however, explain when to avoid this tool or discuss alternative export methods, but the context is otherwise clear.

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

• ncloud_export_postgresql_backupB
  3.4/5.0
  Behavior1/5

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

  The description directly contradicts the annotation 'readOnlyHint: true'. Exporting a backup to Object Storage is a write operation with side effects, not a read-only operation. The annotation claims read-only while the description says 'Export', so the contradiction is severe.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two sentences, with the primary verb and resource front-loaded. Every word earns its place, and the reference to the listing tool is valuable without being verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is too sparse for an export operation with no output schema. It does not mention whether the operation is asynchronous, what the return value looks like, or any required permissions or side effects. The contradiction with the annotation also reduces trust in the completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with all parameters having descriptions. The tool description adds no extra parameter semantics beyond the schema, but the schema itself is sufficiently descriptive. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Export'), a specific resource ('Cloud DB for PostgreSQL backup file'), and a destination ('Object Storage'). It also references a sibling tool for obtaining file names, which helps distinguish it from similar export tools for other database types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs the user to use 'ncloud_list_postgresql_backup_details' to get available file names, providing clear prerequisite guidance. It does not explicitly mention when not to use it, but the tool name and context make the database type clear.

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

• ncloud_functions_get_action_activation_detailB
  3.4/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, and the description merely restates the operation ('Get...') without adding behavioral context such as what fields are included, whether the response includes logs, or any pagination/error behavior. It adds no disclosure beyond the name and annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no redundant words or filler. It communicates the core purpose efficiently and front-loads the action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the operation (a read-only get by ID), the description, combined with fully documented parameters and readOnlyHint annotation, provides sufficient context for an agent to select and invoke the tool. Though no output schema exists, the agent can infer the detailed nature of the response from the name and description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all four parameters, including enums for platform and explanations for actionName, packageName, and activationId. Since schema coverage is 100%, the description adds no additional parameter meaning, and a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get detailed information about a specific action activation' uses a specific verb (get), names the resource (action activation), and specifies granularity (specific, detailed). It clearly distinguishes from sibling tools like list-oriented ones (e.g., ncloud_functions_get_activations) by targeting a single activation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as ncloud_functions_get_trigger_activation_detail or ncloud_functions_get_action_activations. There are no usage scenarios, prerequisites, or exclusions stated.

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

• ncloud_get_credit_history_listB
  3.4/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already signals this is a safe read operation. The description adds value by specifying what the response contains (credit balance, usage history, validity periods), but it does not disclose additional behavioral details such as pagination behavior, authentication requirements, or rate limits. This is acceptable given the annotations cover the safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, only two sentences, and front-loads the primary action. It avoids unnecessary details and every phrase adds value. This is an ideal length for a simple list-query tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with no output schema, the description adequately explains the return payload (balance, usage, validity periods). It does not mention pagination behavior, but the schema's pageNo/pageSize parameters already hint at this. The tool is moderately complex with 8 optional parameters, but the schema covers them fully, and the description provides sufficient context for selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides full descriptions for all 8 parameters, which is 100% schema coverage. The description does not add any parameter-specific semantics beyond a vague hint of 'all or specific credits', which is already reflected in the schema (e.g., discountNoList, memberNoList). The schema carries the heavy lifting, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('credit history list'), and clearly explains the returned data (credit balance, usage history per service, validity periods). It does not explicitly distinguish this tool from sibling tools, but the resource name is specific enough to avoid ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide any guidance on when to use this tool versus alternatives, nor does it state any exclusions or prerequisites. The intended use is only implied by the tool's name and high-level description.

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

• ncloud_get_dashboard_widget_imageB
  3.4/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, and the description doesn't contradict that. It adds useful context by stating the return format is base64-encoded image data, but it doesn't disclose potential error conditions, image format details, or size limits. With annotations covering the safety profile, this score is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise with two sentences, front-loading the action and return format. Every word adds value, with no redundancy or irrelevant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only fetch with two well-documented parameters, the description adequately covers the essential behavior—downloads an image and returns base64 data. It doesn't explain how to obtain widget IDs, but sibling tools and the schema provide sufficient context, making it complete enough for this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% description coverage for both parameters (dashboardId and widgetId). The description adds no extra meaning beyond what the schema already includes, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Download' and identifies the resource as a 'dashboard widget image' from Cloud Insight, clearly stating what the tool does. It does not explicitly differentiate from siblings like ncloud_get_dashboard_widgets or ncloud_query_widget_preview, though the word 'image' provides some implicit distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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. It doesn't mention that other tools list widgets or preview data, or outline any prerequisites or related operations, leaving the agent to infer usage from the name and schema.

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

• ncloud_get_demand_cost_listB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds the 'max 3 months' range constraint and clarifies that return values include discounts, VAT, and payment status. However, it does not disclose pagination behavior or the effect of partner/organization flags, which are relevant for a tool with these parameters.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no irrelevant detail. It front-loads the core purpose and adds only essential return-value context. Every clause earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with 100% schema coverage and a readOnlyHint annotation, the description provides adequate context: it states what is returned and the range limit. It does not explain partner/organization semantics, but those are documented in the schema. The main gap is the lack of differentiation from close sibling tools, which is more of a usage-guideline issue.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all 7 parameters, achieving 100% coverage. The tool description adds no extra parameter information beyond what the schema already states (e.g., format of startMonth/endMonth, pageSize limits). Baseline 3 is appropriate since schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies a read operation for monthly billing cost data with a specific verb ('Get') and resource ('monthly billing cost list'). It adds useful context about what is included (discounts, VAT, payment status). However, it does not differentiate from similarly named sibling tools like ncloud_get_product_demand_cost_list or ncloud_get_contract_demand_cost_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus the many related billing/cost tools (e.g., ncloud_get_product_demand_cost_list, ncloud_get_contract_demand_cost_list). The description does not mention alternatives, prerequisites, or context such as whether this is the default/all-services cost view.

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

• ncloud_get_fabric_cluster_detailB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes that this is a safe read operation. The description adds minimal context by specifying 'specific' (implying a single cluster), but does not disclose response details, error behavior, or required permissions beyond what annotations imply. It is consistent with the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of nine words, directly stating the purpose with no fluff or redundancy. It is front-loaded and every word contributes.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 parameter, the description is adequate for basic invocation. The schema covers the parameter and annotations cover safety. However, it lacks guidance on what 'detailed information' includes or how to find the cluster number, which could be helpful for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with a descriptive parameter name and description ('Fabric cluster number to query'). The tool description does not add any extra meaning about the parameter's format, source, or usage beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get detailed information about a specific fabric cluster.' It uses a specific verb and resource and distinguishes from listing tools like ncloud_list_fabric_clusters by focusing on a single cluster. However, it does not explicitly name alternatives or clarify the relationship to sibling tools like ncloud_get_fabric_cluster_pools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 how to obtain the fabricClusterNo, whether to use it after listing clusters, or any prerequisites. There is no exclusionary or comparative language.

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

• ncloud_get_fabric_cluster_poolsB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this as a safe read operation, so the description does not need to repeat that. The description adds a small clarification ('physical resource pools') but provides no details on pagination, response format, or filtering behavior beyond what the schema already contains.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that immediately states the action and resource. It contains no filler or redundancy, earning the highest score for efficiency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple list operation with a readOnly annotation and a single, well-documented optional parameter. The description and schema together are sufficient for the agent to select and invoke the tool correctly, though the absence of an output schema means the agent must infer the return type from the phrase 'List available...'.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage: the sole parameter fabricClusterPoolNoList is described as 'Filter by fabric cluster pool numbers'. The tool description adds no extra meaning 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List available fabric cluster pools (physical resource pools)' uses a specific verb (List) and identifies the exact resource (fabric cluster pools), making the tool's purpose clear. It distinguishes the resource type from sibling tools like ncloud_list_fabric_clusters, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 related tools such as ncloud_get_fabric_cluster_detail or ncloud_list_fabric_clusters. It does not state any context, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name.

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

• ncloud_get_log_count_by_typeB
  3.4/5.0
  Behavior3/5

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

  The description is consistent with the readOnlyHint annotation ('Get' indicates a read operation). It adds minimal behavioral context beyond what the annotation already provides—there is no disclosure of pagination, time constraints, or return format. This is adequate but not rich, given the annotation covers the safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no redundant wording, front-loading the core action clearly. It loses one point because it omits usage guidance and contextual details, making it efficient but slightly under-specified for a complete entry.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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 two parameters and no output schema, the description adequately explains the main purpose. However, it leaves out details about the returned data structure, any time range constraints, and how the counts are aggregated, which could be important for an agent to fully use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for both parameters, so the baseline is 3. The description adds a small amount of meaning by clarifying that 'type' refers to 'server or log_name', which reinforces the enum but does not deeply enhance the schema's semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' and clearly identifies the resource as 'aggregated log counts by type', explicitly naming the grouping dimensions ('server or log_name'). This distinguishes it from sibling tools like ncloud_get_log_count_total or ncloud_get_log_count_recent, which focus on different aggregation scopes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or alternative tool names. The intended use case is only implied by the 'by type' phrasing and the enum values, offering no direct instruction for tool selection.

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

• ncloud_get_mongodb_instance_detailB
  3.4/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, and the description does not contradict that. However, the description adds no extra behavioral context beyond restating the tool's purpose; it does not describe the response format, any filtering constraints, or other operational details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no filler. It is front-loaded with the primary action and resource, and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only detail tool with a single required parameter and no output schema, the description combined with the schema and annotations provides adequate context. It clearly indicates what the tool does, and the parameter schema covers the input. No major gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with the parameter 'cloudMongoDbInstanceNo' described as 'Cloud MongoDB instance number to query'. The description adds no additional parameter semantics, but because the schema fully documents the parameter, baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get detailed information') and the resource ('specific Cloud DB for MongoDB instance'). It distinguishes from list tools (e.g., ncloud_list_mongodb_instances) and other database detail getters (e.g., ncloud_get_mysql_instance_detail).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool vs alternatives. It does not mention that listing instances is the prerequisite or that similar tools exist for other database types. Usage context is only implied by the word 'specific'.

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

• ncloud_get_mysql_target_subnetsB
  3.4/5.0
  Behavior3/5

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

  The tool is annotated as readOnlyHint=true, and the description's "List" verb aligns with this, so there is no contradiction. The description adds some context by indicating the subnets are scoped to a specific MySQL instance and intended for instance creation, but it does not disclose details such as whether only subnets in the instance's VPC are returned or how invalid instance numbers are handled.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the action and resource, and contains no unnecessary filler. The awkward "within a specific MySQL instance" wording is a minor structural flaw, but the overall length is appropriate.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple two-parameter read-only tool with no output schema, and the description provides a basic but sufficient understanding of the tool's purpose. It does not clarify return value shape, whether results are paginated, or how the subnets are selected, but for a straightforward list operation the missing details are not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both regionCode and cloudMysqlInstanceNo, so the schema already documents the parameters. The description only weakly reinforces that cloudMysqlInstanceNo identifies the specific MySQL instance and adds no meaningful format, syntax, or value guidance beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb "List" and identifies the resource as "subnets available for Cloud DB for MySQL instance creation," which clearly distinguishes it from MySQL VPC listing and other database subnet tools. However, the phrase "within a specific MySQL instance" is grammatically awkward and could be misinterpreted, slightly undermining clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended usage is implied: the user needs to provide a specific MySQL instance and expects subnets that can be used for instance creation. There is no explicit mention of when to choose this over get_mysql_target_vpcs or other subnet-related tools, and no exclusions or alternative guidance is provided.

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

• ncloud_get_nas_snapshot_config_historyB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates a safe read operation. The description adds the notion of 'configuration history' but does not clarify what historical changes are included, how far back the history goes, or the response structure. It adds minimal behavioral context beyond the annotation, which is acceptable given the annotation, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded, grammatically correct sentence with no redundancy or filler. It communicates the essential purpose efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, single-parameter, read-only tool, the description is mostly complete. It identifies what the tool retrieves and the schema defines the required parameter. However, since there is no output schema, the agent must infer what 'configuration history' includes; a brief mention of the response content would have made it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% because the only parameter, nasVolumeInstanceNo, has a description. The tool description does not add any additional semantic detail about the parameter. With full schema coverage, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (get) and the specific resource (snapshot configuration history for a NAS volume instance). It is specific enough to communicate the core purpose, but it does not explicitly distinguish this from sibling tools like ncloud_list_nas_snapshots or ncloud_get_nas_volume_detail, so it falls 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.

  Usage Guidelines2/5

  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 related operations such as creating snapshots, changing snapshot config, or listing snapshots, nor does it state any preconditions or exclusions. Context signals reveal siblings but the description itself offers no usage direction.

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

• ncloud_get_postgresql_target_subnetsB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this as a safe read operation, so the description doesn't need to repeat that. It adds some context by specifying subnets are for instance creation, but doesn't disclose filtering behavior, pagination, or response format. This is minimal additional value 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 14 words, front-loaded with the action 'List subnets'. It contains no redundant words or filler, making it highly concise and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with one required parameter and one optional parameter, the description conveys the core purpose effectively. The ambiguity around 'within a specific PostgreSQL instance' and lack of mention of response characteristics leave a small gap, but the tool is simple enough that this is largely sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for both parameters with 100% coverage, so the description doesn't need to elaborate. It doesn't add any semantic nuance beyond what the schema already states, such as the relationship between the instance number and the subnets returned.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and identifies the resource as 'subnets available for Cloud DB for PostgreSQL instance creation'. It distinguishes from sibling tools by naming PostgreSQL. However, the phrase 'within a specific PostgreSQL instance' is ambiguous because subnets aren't within an instance; it may mean subnets associated with a specific instance, which slightly detracts from clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus similar sibling tools like ncloud_get_postgresql_target_vpcs or ncloud_get_mysql_target_subnets. There are no alternatives, exclusions, or preconditions mentioned, leaving the agent to infer usage context.

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

• ncloud_get_price_listB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals a safe read operation, and the description aligns with this by using 'Get' and 'Retrieves'. The description adds useful context about the return content (pricing details including charging unit, rating unit, conditions, and promise discounts), but does not disclose potential limitations, pagination, or error behavior. This is acceptable for a simple read-only tool but not overly rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the core action ('Get price list by price numbers') and immediately followed by useful detail on what the response includes. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the readOnlyHint annotation, 100% schema parameter coverage, and no output schema, the description provides adequate context by listing what the response contains. It does not explain optional parameter usage (promiseNoList, payCurrencyCode) beyond the schema, but this is not a significant gap for a simple getter. The description is complete enough for an agent to select and invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all three parameters, so the schema already documents each parameter's meaning. The description mentions 'price numbers' and 'promise discounts', which maps loosely to priceNoList and promiseNoList, but adds no additional syntax, format, or constraint details beyond what the schema provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves a price list by price numbers and specifies the details included (charging unit, rating unit, conditions, promise discounts). This distinguishes it from generic product price list tools by focusing on price numbers as the key input, though it doesn't explicitly name sibling alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 like ncloud_get_product_price_list or ncloud_get_demand_cost_list. It implies usage context (looking up pricing plan details for specific price numbers) but offers no exclusions or comparison to other pricing-related tools.

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

• ncloud_gtm_create_geo_cidr_mapB
  3.4/5.0
  Behavior2/5

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

  The annotation destructiveHint=false is the only behavioral signal. The description adds no additional context such as idempotency, failure conditions on duplicate names, or whether the operation is synchronous. It does not contradict the annotation but also adds no value beyond it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that efficiently conveys the tool's purpose without any redundant or extraneous words. Every word contributes to the meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema fully documents the required parameters, and the description clearly states the action. Given the richness of the schema and the simplicity of a create operation, the description is largely complete. It lacks some behavioral details like return values or duplicate-name handling, but these are not essential for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% description coverage for all parameters, including the mapType enum and the nested detailedMapList structure. The description adds no parameter-specific meaning beyond what the schema already supplies, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create') and the resource ('new Geo or CIDR map') within the context of Global Traffic Manager. This distinguishes it from sibling operations like list, get, update, and delete on the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention that it should be used only for creating new maps, nor does it reference the update or delete siblings. There are no prerequisites or special cases described.

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

• ncloud_gtm_create_policyB
  3.4/5.0
  Behavior2/5

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

  The description does not add behavioral context beyond the annotation destructiveHint=false. It does not mention prerequisites, side effects, or what the response will contain. This is especially weak for a create operation without an output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that leads with the action and resource, followed by the key components. Every word is necessary and there is no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the schema being well-documented, the description does not explain the overall workflow or any relationship dependencies (e.g., that a policy belongs to a profile). It lacks guidance on how the nested monitor and resourceGroups structures fit together, and there is no output schema to clarify return values.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds a high-level summary that mentions 'load balancing, monitor, and resource groups', but this does little beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create'), the resource ('a new Global Traffic Manager policy'), and the key components ('load balancing, monitor, and resource groups'). This distinguishes it from related tools like ncloud_gtm_create_profile or ncloud_gtm_create_geo_cidr_map.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied by the verb and resource, but there is no explicit guidance on when to use this tool versus alternatives such as ncloud_gtm_update_policy or ncloud_gtm_create_profile. No alternatives or exclusions are mentioned.

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

• ncloud_gtm_update_policy_health_checkB
  3.4/5.0
  Behavior2/5

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

  Annotations declare idempotentHint=true and destructiveHint=false, so the safety profile is covered, but the description adds no behavioral context beyond restating the operation. It does not explain whether the update replaces or merges existing health check settings, or what happens when optional parameters are omitted.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that efficiently communicates the core purpose with no redundant words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite good schema coverage and annotations, the description omits critical behavioral details such as partial-update semantics, response contents, and prerequisites. This is a substantial gap for a mutation tool with 8 configurable fields and no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema provides 100% description coverage for all 8 parameters, including enums and descriptions. The description itself adds no parameter semantics beyond what the schema already documents.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Update' and identifies the exact resource ('health check configuration for a Global Traffic Manager policy'). It clearly distinguishes from sibling tools like ncloud_gtm_update_policy and ncloud_gtm_delete_policy_health_check.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use case is implied by the tool name and description, but there are no explicit guidelines about when to choose this over related tools such as ncloud_gtm_update_policy, which could also modify policy settings. No exclusions or alternatives are mentioned.

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

• ncloud_hadoop_list_notebook_productsB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation covers the safety profile, so the description doesn't need to repeat it. The phrase 'available server types' adds a slight nuance but does not disclose behavior beyond what the annotation implies, such as pagination, delays, or output format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that states the action and target resource clearly. No unnecessary words, no redundancy, and it is easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with two optional parameters and no output schema, the description is largely sufficient. However, it doesn't clarify the relationship with sibling tools like list_notebook_images, which could lead to ambiguity in selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides descriptions for both parameters (regionCode and cloudHadoopNotebookImageProductCode) with 100% coverage. The description itself does not add further context about parameter values or formats, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses 'List' as a clear verb and specifies the resource as 'available server types for notebook nodes'. It distinguishes from sibling tools that list notebooks, images, or components, though it doesn't explicitly name those siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites or context mentioned. The agent is left to infer that it's for selecting server types when creating notebooks, but no explicit advice is given.

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

• ncloud_initiate_multipart_uploadB
  3.4/5.0
  Behavior2/5

  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 does not mention that this is the first step of a multi-step process requiring subsequent upload_part and complete_multipart_upload calls, nor does it state that an upload ID is returned and must be managed. The description is too sparse to inform the agent about side effects or statefulness.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded and free of filler. It states the essential purpose without redundancy. No unnecessary words or details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is too brief for a complex multipart upload operation. It lacks critical context about the multipart workflow, such as the need to call upload_part and complete_multipart_upload after initiation, the requirement to abort if not completed, and the absence of an output schema means the return value is not explained. The agent would not know how to proceed after calling this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (key, bucketName, contentType) having a clear description. The tool description itself adds no extra parameter meaning beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('Initiate a multipart upload') and the resource ('a large object in Object Storage'), with a specific verb and scope. It distinguishes from sibling tools like ncloud_upload_part, ncloud_complete_multipart_upload, and ncloud_abort_multipart_upload, as 'initiate' is uniquely the starting step.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for a large object' implies a use case, but there is no explicit guidance on when to use this versus alternatives like ncloud_put_object for small objects or ncloud_upload_part for subsequent steps. No exclusions or workflow context is provided, so the usage context is only implied.

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

• ncloud_kms_enable_auto_rotationB
  3.4/5.0
  Behavior2/5

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

  Annotations provide idempotentHint=true and destructiveHint=false, which already indicate the safety profile. The description adds no additional behavioral context beyond the basic action—no mention of side effects (e.g., scheduling, key version changes), prerequisites, or what happens to existing rotation settings. With annotations present, the description fails to add value about the behavior of enabling auto rotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no superfluous words. It is front-loaded with the verb and resource. However, it is quite sparse and could include relevant context without becoming verbose, 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one parameter, no output schema), but the description does not cover prerequisites (e.g., key must exist, rotation period must be configured), the effect of enabling auto rotation, or return behavior. Given the low complexity, the description is minimally adequate but leaves important operational context unspecified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of the parameter (keyTag) with a clear description ('Key tag - unique identifier derived from key name'). The tool description does not mention keyTag at all, so it adds no meaning beyond the schema. Baseline of 3 is appropriate given high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb-resource combination ('Enable automatic key rotation for a KMS key') and clearly identifies the target resource. It distinguishes this tool from sibling tools like ncloud_kms_disable_auto_rotation and ncloud_kms_rotate_key by specifying the action (enable auto rotation) rather than manual rotation or disabling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for enabling automatic key rotation, but it does not explicitly state when to use it versus alternatives (e.g., manual rotation with ncloud_kms_rotate_key or disabling with ncloud_kms_disable_auto_rotation). No prerequisites, conditions, or exclusions are provided. Usage is inferred from the tool name and sibling context rather than explicit guidance.

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

• ncloud_kms_request_key_deletionB
  3.4/5.0
  Behavior1/5

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

  The description states 'Destructive' and explains the key enters REVOKE state with permanent deletion after the scheduled date. However, the annotation destructiveHint is false, directly contradicting the description. This is a serious inconsistency that misleads the agent about the tool's safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, front-loaded with the destructive warning, and uses two clear sentences to explain the lifecycle and cancellability. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with no output schema, the description covers the key behavioral facts: state transition, scheduled permanent deletion, and that it can be cancelled. It does not mention return values, but none are specified, and the lifecycle explanation is sufficient for an agent to understand the action's implications. Minor gap: no explicit prerequisite that the key must exist, but that is implied by requesting deletion of a specific key.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single parameter keyTag, with a description of 'Key tag - unique identifier derived from key name'. The tool description adds no additional parameter detail, so the baseline of 3 is appropriate because the schema already fully documents the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Request deletion of a KMS key') on a specific resource, and it distinguishes this tool from immediate-delete and cancel-deletion siblings by describing the scheduled deletion flow. The verb 'request' and the mention of REVOKE state make the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides context for when to use this tool: to initiate a cancellable, scheduled deletion of a KMS key. It notes that the action can be cancelled before the destroy date, implying an alternative cancel operation, but it does not explicitly name or compare alternatives like 'ncloud_kms_cancel_key_deletion' or 'ncloud_kms_delete_key' for immediate deletion. No explicit exclusion is given.

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

• ncloud_list_deny_allow_groupsB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this as a safe read operation, and the description does not contradict this. However, it adds no additional behavioral context such as pagination, result size limits, or whether the group numbers filter returns a list. The description carries minimal burden beyond the annotation, consistent with the midpoint on the scale.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no filler. It effectively conveys the tool's purpose in the fewest words possible, earning a perfect score for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no output schema, three optional filter parameters), the description is adequately complete. It names the resource and action, and the schema covers parameters. It lacks domain context about what a Deny-Allow Group is, but that is not strictly necessary for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (vpcNo, networkAclDenyAllowGroupName, networkAclDenyAllowGroupNoList) having its own description. The tool description adds no extra parameter semantics, but this is acceptable given the schema already provides full coverage. Baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List Network ACL Deny-Allow Groups' uses a specific verb ('List') and resource ('Network ACL Deny-Allow Groups'), clearly distinguishing it from related sibling tools like ncloud_get_deny_allow_group_detail and ncloud_create_deny_allow_group. However, it does not explicitly state the scope (e.g., all groups or filtered) beyond what the schema implies.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_get_deny_allow_group_detail or ncloud_list_network_acls. The description simply states what it does, leaving the agent to infer usage context from the name and schema.

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

• ncloud_list_groupsB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates a safe read operation. The description adds the context 'for managing sub account permissions' but does not disclose pagination behavior, result ordering, or the meaning of 'all' given the page/size parameters. It does not contradict the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It immediately communicates the tool's action and resource, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with two well-documented parameters and a readOnlyHint annotation, the description is sufficiently complete. It clearly states the tool's purpose, though it could mention what the return data would include or clarify that 'all' may require pagination.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for 'page' ('Page number (0-based, default: 0)') and 'size' ('Page output count (default: 10)'). The description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all IAM groups for managing sub account permissions' uses a specific verb ('List'), a clear resource ('IAM groups'), and adds context about sub account permissions. It clearly distinguishes from related tools like ncloud_create_group or ncloud_delete_group, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, such as when to use ncloud_list_sub_accounts or ncloud_list_policies. There are no exclusions, prerequisites, or explicit use-case scenarios mentioned.

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

• ncloud_nks_get_ip_aclB
  3.4/5.0
  Behavior2/5

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

  The annotation readOnlyHint=true already establishes this is a safe read operation. The description adds no behavioral context beyond that—no mention of what the configuration includes, any preconditions, or response format. It simply restates the tool's purpose without revealing any additional traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word carries meaning, making it appropriately concise for a simple read operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, read-only annotation, no output schema), the description is largely sufficient. However, it does not specify what the IP ACL configuration contains or what the response will look like, which would be useful without an output schema. A 4 reflects this minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (clusterUuid is described as 'UUID of the cluster'), so the schema fully documents the only parameter. The description does not add any extra semantic detail, earning the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get IP ACL configuration for an NKS cluster' uses the specific verb 'Get' and identifies a precise resource ('IP ACL configuration') and scope ('NKS cluster'). It clearly distinguishes from the sibling tool ncloud_nks_set_ip_acl, which modifies the configuration, and from other NKS getters like ncloud_nks_get_cluster.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 the complementary setter ncloud_nks_set_ip_acl, nor any exclusions or prerequisites. The agent must infer usage solely from the tool name.

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

• ncloud_nks_upgrade_clusterB
  3.4/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries the full burden. 'Uses PATCH with query parameters' is an implementation detail, but it does not disclose behavioral impacts such as potential downtime, rolling upgrade behavior, irreversibility, or required cluster state. This is a mutation operation without side-effect disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two short sentences with no redundant information. It front-loads the core purpose and adds a single technical note about the HTTP method, making it appropriately concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a cluster upgrade operation with no annotations, no output schema, and no supplementary context, the description is critically thin. It does not explain what happens during the upgrade, how to monitor progress, whether the upgrade is rolling or disruptive, or any version compatibility checks needed. This leaves the agent under-informed for a high-impact operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 adds no parameter-specific information beyond what the schema already provides, meaning it does not enhance the agent's understanding of maxSurge, maxUnavailable, or version constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (upgrade), the resource (NKS cluster), and the specific attribute (Kubernetes version). This distinguishes it from sibling tools like ncloud_nks_upgrade_node_pool by specifying 'cluster'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for cluster-level Kubernetes upgrades, but provides no explicit guidance on when to use this tool versus alternatives like ncloud_nks_upgrade_node_pool. No prerequisites, exclusions, or alternative recommendations are mentioned.

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

• ncloud_pca_activate_sub_caB
  3.4/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries the full burden. It only states 'Activate a Sub CA' without disclosing side effects, prerequisites (e.g., CA state), permission requirements, or reversibility. This is insufficient for a state-changing operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that immediately states the action and key inputs. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite complete schema coverage and no output schema, the description provides minimal context. It omits the activation workflow, prerequisite CA state, potential outcomes, or error conditions. For a CA activation operation, an agent needs more to fully understand the tool's role.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with detailed descriptions for caTag, certPem, and caChainPem. The description adds no additional parameter semantics beyond echoing 'signed certificate and CA chain', so it meets the baseline but doesn't enhance understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Activate'), the target resource ('Sub CA'), and the method ('using a signed certificate and CA chain (direct signing method)'). It distinguishes from sibling tools like ncloud_pca_sign_sub_csr by specifying the activation step and the direct signing method.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (when you have a signed certificate and CA chain) but does not explicitly name alternatives or exclusion conditions. The phrase 'direct signing method' hints at possible alternatives but lacks concrete guidance.

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

• ncloud_pca_update_crl_configB
  3.4/5.0
  Behavior2/5

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

  Annotations already indicate idempotency and non-destructiveness. The description adds the minimum 3-day constraint, but this is already present in the schema. No additional behavioral details are disclosed, such as whether updating the interval triggers immediate CRL generation or only affects future rotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no unnecessary words. It front-loads the action and then states the key constraint, making it easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity and rich schema with annotations, the description is mostly sufficient. It clearly states what the tool does and the minimum value. However, it omits context about whether the change is applied immediately or via a scheduled rotation, and does not reference related sibling tools; a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% parameter coverage with descriptions for both caTag and expiry. The description repeats the minimum 3-day rule but does not add new meaning beyond the schema, such as clarifying what a 'CA tag value' is or how expiry relates to CA expiry.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action 'Set' and the target 'CRL update interval for a Private CA', which is specific and distinguishes this tool from siblings like get_crl_config (view) and rotate_crl (immediate rotation). No ambiguity exists.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_pca_get_crl_config or ncloud_pca_rotate_crl. The verb 'Set' implies an update but gives no prerequisites, exclusions, or context for choosing it over related operations.

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

• ncloud_put_scheduled_actionB
  3.4/5.0
  Behavior2/5

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

  With empty annotations, the description carries the full burden of behavioral disclosure. It merely says 'Create or update' without explaining important semantics: whether an existing scheduled action is fully replaced, whether all parameters are required for updates, or how one-time vs recurring schedules interact. For a mutation tool, this is a significant transparency gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of ten words, front-loaded with the action verb. Every word earns its place, and there is no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 8 parameters, no output schema, and no annotations, yet the description provides minimal context. It does not explain scheduling concepts (one-time vs recurring using recurrenceInKST), the effect of updating an existing action, or expected response/behavior. For a complex ASG scheduling operation, this is incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with meaningful descriptions for all 8 parameters, so the baseline is 3. The description adds no additional parameter-level detail beyond what the schema already states, so no extra credit is warranted.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Create or update') and resource ('a scheduled action for an Auto Scaling Group'). This clearly distinguishes it from sibling tools like ncloud_list_scheduled_actions and ncloud_delete_scheduled_action, and also from ncloud_put_scaling_policy which targets a different resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the phrase 'Create or update' and the resource type, but the description does not explicitly state when to use this tool versus alternatives or mention any exclusions or preconditions. There is no guidance on choosing between this and related tools like delete_scheduled_action or put_scaling_policy, though the resource clarity partially compensates.

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

• ncloud_query_monitoring_data_multipleB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint=true annotation already declares this as a safe read operation. The description adds the scope of 'single request' and 'multiple metrics' but does not disclose other behavioral traits such as response format, pagination, or limits on the number of metrics, which could be relevant for a monitoring query tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with the main point front-loaded. However, the second sentence ('Supports querying multiple metrics at once') largely repeats the key point from the first sentence, creating slight redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has moderate complexity (5 params, no output schema). The description adequately conveys the core function but does not explain the return value structure, constraints on the metrics array, or how the interval/aggregation defaults affect behavior, leaving room for improvement.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all five parameters (metrics, timeStart, timeEnd, interval, aggregation) documented in the schema. The description does not add any extra parameter-level meaning beyond what is already in the schema, 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Query') and resource ('multiple time-series monitoring data from Cloud Insight'), and emphasizes 'multiple metrics at once' which distinguishes it from singular query tools like ncloud_query_monitoring_data. However, it does not explicitly name the alternative, so it stops short of 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for querying multiple metrics in a single request, which is useful context. However, it does not explicitly state when to use this tool versus alternatives (e.g., ncloud_query_monitoring_data for single metrics) or provide any exclusion criteria.

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

• ncloud_reboot_mysql_serverB
  3.4/5.0
  Behavior2/5

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

  With annotations already indicating idempotency and non-destructive nature, the description adds no further behavioral context such as expected downtime or connection impact. It simply restates the action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that gets straight to the point with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple nature of the tool, full parameter schema, and annotations covering safety, the description is adequate for selection and invocation. However, it lacks any additional context about side effects, but that is not critical for a straightforward reboot operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully documents the single parameter (cloudMysqlServerInstanceNo) with a description, and the tool description does not add additional semantics. Baseline 3 applies for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Reboot' and identifies the resource as 'Cloud DB for MySQL server instance', clearly distinguishing it from sibling reboot tools for other database types (e.g., PostgreSQL, MongoDB).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, nor any exclusions or prerequisites. It is a bare statement of the operation.

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

• ncloud_reboot_postgresql_serverB
  3.4/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds no context about operational effects like temporary downtime, connection interruptions, or required permissions. For a disruptive action, this absence of disclosure is a gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with zero waste. It conveys the essential information without any redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple reboot operation with one parameter and solid annotations, the description is sufficient. Adding a note about the operational impact (e.g., brief downtime) would make it fully complete, but the low complexity warrants a high score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the single parameter with 100% coverage, and the description adds no additional meaning beyond what the schema already provides. The baseline of 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Reboot') and the specific resource ('Cloud DB for PostgreSQL server instance'), making it unambiguous and distinct from sibling reboot tools for other database types like MySQL, MSSQL, MongoDB, and Cache.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, such as rebooting MySQL or regular servers. It lacks any context about prerequisites, use cases, or when this tool is the appropriate choice.

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

• ncloud_ses_get_cluster_acgB
  3.4/5.0
  Behavior2/5

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

  The annotations already declare readOnlyHint=true, and the description adds no additional behavioral context such as required permissions, rate limits, or what the response contains. It only restates the tool's purpose without revealing any behavioral traits beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that conveys the essential information without any redundant or filler words. It is well-structured and immediately front-loads the action and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one required parameter, no output schema, annotations present), the description sufficiently covers the action and resource. While it could mention what the returned rules look like, the low complexity and clarity of 'Get ACG rules' make it adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with a clear description for the single parameter ('Cluster instance number'). The tool description adds no extra semantic meaning beyond what the schema already 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and clearly identifies the resource ('ACG rules') and the target domain ('Search Engine Service cluster'). It expands the acronym ACG and distinguishes this tool from general ACG tools like ncloud_get_acg_rules and sibling cluster tools like ncloud_ses_get_cluster_detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 when NOT to use it, nor does it reference any sibling tools or alternative approaches (e.g., using ncloud_get_acg_rules for general ACG rules). The usage context is left entirely to the agent's inference.

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

• ncloud_ses_get_import_historyB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint=true annotation indicates a safe read operation, and the 'Get' verb is consistent. The description adds minimal context (specific resource scope) but does not disclose any additional behavioral traits like return format, pagination, or filtering behavior. With annotations covering the safety profile, this is acceptable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that contains no filler or redundant information. Every word contributes to the meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only history lookup with one parameter and no output schema, the description is mostly sufficient. However, it omits any detail about what the history includes (e.g., status, timestamps, import results), which would help the agent understand the tool's full scope. Still, the simplicity of the operation lowers the burden.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, serviceGroupInstanceNo, is fully described in the schema as 'Cluster instance number' (100% coverage). The description adds no additional parameter semantics beyond referencing the cluster, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves data import history for a Search Engine Service cluster, with a specific verb and resource. It is distinct from sibling tools like ncloud_ses_run_import and ncloud_ses_stop_import, though it does not explicitly differentiate itself from other history getters.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_ses_run_import, ncloud_ses_stop_import, or ncloud_ses_get_import_buckets. The description simply states what it does, leaving the agent to infer usage context.

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

• ncloud_ses_get_node_spec_detailB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates this is a safe read operation. The description adds the scope that it applies to each node in a cluster, but it does not disclose details about the response format, potential errors, or whether pagination or filtering is involved. This is acceptable given the annotation, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that conveys the essential purpose without any fluff. It is well-structured and front-loaded with the verb 'Get'.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 parameter and no output schema, the description is reasonably complete. It clearly states what is returned (server specifications) and the context (each node in a cluster). A more detailed enumeration of the specifications or potential limitations would improve completeness, but the current level suffices.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage: serviceGroupInstanceNo is described as 'Cluster instance number'. The description adds no additional meaning beyond this, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and resource ('server specifications for each node in a Search Engine Service cluster'), making the purpose specific and understandable. It does not explicitly differentiate from sibling tools like ncloud_ses_get_server_specs or ncloud_ses_get_node_list, but the phrase 'for each node' adds useful scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 any prerequisites, exclusions, or relationship to sibling tools such as ncloud_ses_get_cluster_detail or ncloud_ses_get_node_list.

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

• ncloud_ses_get_server_generationsB
  3.4/5.0
  Behavior3/5

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

  The description is consistent with the readOnlyHint annotation (a 'Get' operation), so no contradiction. However, it adds no behavioral insight beyond the annotation—no mention of response format, pagination, or limitations. With annotations covering the read-only aspect, the description is minimally adequate but not enriched.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise sentence that is front-loaded with the action ('Get') and resource ('available node server generations'). Every word earns its place; no unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a simple parameterless lookup, and the description names the exact data returned. However, it does not specify the output structure or when to use it relative to other SES lookup tools. Given the absence of an output schema, more detail on the return value could be expected, but the tool's simplicity mitigates this gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so parameter semantics are trivially covered. The description correctly omits parameter details since none exist, and the baseline for zero parameters is 4. No additional parameter explanation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves 'available node server generations' for 'Search Engine Service', using a specific verb and resource. It is distinguishable from siblings like ncloud_ses_get_server_specs and ncloud_cdss_get_server_generations by the resource term and service scope, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No information is given about when to use this tool versus alternatives like ncloud_ses_get_server_specs or ncloud_ses_get_node_products. There are no exclusions, preconditions, or contextual guidance provided.

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

• ncloud_set_lb_subnetB
  3.4/5.0
  Behavior3/5

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

  The description adds no behavioral context beyond what the annotations already indicate (idempotentHint=true, destructiveHint=false). It does not state whether existing subnets are replaced or appended, but the annotations cover the safety profile, so the description is not misleading.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no extraneous information. It effectively communicates the core action in a concise and front-loaded manner.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter operation with full schema coverage and annotations, the description is sufficient. It could mention whether subnets are replaced or appended, but given the tool's low complexity and the richness of the structured metadata, the current level of detail is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides clear descriptions for both parameters (subnetNoList and loadBalancerInstanceNo), and the schema description coverage is 100%. The description itself does not add extra parameter semantics beyond what the schema already documents.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Set' with the resource 'subnets for a load balancer instance', clearly identifying the operation. It does not explicitly differentiate from similar sibling tools like ncloud_nks_update_lb_subnet, which also updates load balancer subnets in a Kubernetes context, but the naming and phrasing make the target resource clear enough.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. There are no mentions of prerequisites, exclusions, or related tools, leaving the agent to infer usage entirely from the tool name and description.

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

• ncloud_set_route_table_descriptionB
  3.4/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the annotations. Annotations already indicate idempotentHint=true and destructiveHint=false, but the description does not mention that the existing description is overwritten or any other side effects. With annotations present, some additional context is expected, but none is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the verb and resource. Every word earns its place, with no unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with fully described parameters and supporting annotations, the description is sufficient. The only minor gap is that it does not explicitly state that the new description replaces the existing one, but this is implied by the verb 'update' and the parameter name. Given the low complexity, the description is complete enough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with clear descriptions for routeTableNo and routeTableDescription. The tool description does not add any extra semantic meaning beyond what the schema already provides, justifying the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Update the description of a route table' uses a specific verb ('update') and clearly identifies the resource ('route table') and attribute ('description'). This distinguishes it from sibling tools like ncloud_create_route_table, ncloud_delete_route_table, and ncloud_set_network_acl_description.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The usage is only implied by the name and description, which is minimal.

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

• ncloud_set_target_group_descriptionB
  3.4/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond what annotations already provide. Annotations state idempotentHint=true and destructiveHint=false; the description merely restates the action without mentioning permissions, side effects, or idempotency implications. There is no contradiction, but no added value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence: 'Set or update the description of a target group.' It is concise and free of unnecessary detail, efficiently conveying the tool's action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (two required string parameters), the annotation coverage, and the absence of an output schema, the description sufficiently conveys the core operation. It could mention expected outcomes or validation, but for a setter, this is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are already documented. The description does not add any extra meaning about the parameters (e.g., format, constraints, relationship between them), leaving the baseline at 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource combination: 'Set or update the description of a target group.' It clearly distinguishes from sibling tools that set descriptions of other resources (e.g., ncloud_set_lb_description, ncloud_set_route_table_description).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or contrast with related tools like ncloud_change_target_group_config or ncloud_get_target_group_detail.

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

• ncloud_sourcebuild_create_projectB
  3.4/5.0
  Behavior2/5

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

  Annotations only include destructiveHint=false. The description adds no behavioral context beyond the word 'Create', which is already evident from the tool name. No side effects, resource implications, or required dependencies are disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that is direct and front-loaded. It contains no redundant phrases and earns its place, though it is minimal.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 39 parameters, multiple platform-dependent required fields, and no output schema, the one-sentence description is insufficient. It does not orient the agent to different build platform modes (SourceBuild vs ContainerRegistry vs PublicRegistry) or the need for prerequisite lookup tools, leaving the agent to rely entirely on the extensive schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% parameter description coverage, so the baseline is 3. The description's 'full configuration' adds no parameter-specific meaning beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Create' with a specific resource 'SourceBuild project', clearly distinguishing it from sibling tools like ncloud_sourcecommit_create_repo and ncloud_sourcedeploy_create_project. The phrase 'new' reinforces the creation scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for creating a new project but provides no explicit guidance on when to use it vs. alternatives. It does not mention prerequisites (e.g., listing OS, compute, or runtime IDs first) or any exclusion conditions, leaving the agent to infer context from the name and schema.

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

• ncloud_sourcebuild_update_projectB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, which match the description's update operation. The description adds no further behavioral context beyond the obvious meaning of 'update', such as whether unspecified fields are preserved, what happens if the project does not exist, or any side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence with no redundant words. It is front-loaded and immediately communicates the tool's purpose, making it appropriately concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the high complexity (39 parameters) and lack of output schema, this one-line description is not sufficient. It does not explain update semantics, such as whether the operation is a partial update or a full replacement, or what the returned value represents. The schema provides parameter details, but the description fails to give an overall operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all 39 parameters. The tool description itself provides no parameter-level information, and the baseline of 3 applies because the schema takes on the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Update') and the specific resource ('existing SourceBuild project configuration'). It distinguishes this tool from siblings like create, delete, get, or list projects. The word 'existing' also implies a precondition that the project must already exist.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, such as ncloud_sourcebuild_create_project or ncloud_sourcebuild_delete_project. It does not mention that projectId is required, how partial updates behave, or any prerequisites or exclusions.

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

• ncloud_sourcecommit_list_tagsB
  3.4/5.0
  Behavior2/5

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

  Beyond the readOnlyHint annotation, the description adds no behavioral context. It does not mention pagination, filtering, return format, error behavior, or required permissions. The phrase 'all tags' is a scope, not a disclosed behavioral trait. Thus, it fails to provide additional transparency beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that immediately conveys the action and scope. It contains no redundant words or filler, making it highly efficient and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with a single well-documented parameter and no output schema, the description is largely sufficient. However, it omits details about the response format and pagination behavior, which would be valuable given the lack of an output schema. Despite this, the tool's simplicity and the readOnlyHint reduce the need for extensive explanations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage, the repositoryName parameter is already clearly documented as 'Name of the repository'. The tool description adds no extra meaning about this parameter, such as format, example, or constraints, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'List all tags in a SourceCommit repository'—a specific verb ('List'), resource ('tags'), and scope ('in a SourceCommit repository'). This distinguishes it from sibling listing tools like ncloud_sourcecommit_list_branches and ncloud_sourcecommit_list_repos by explicitly naming the resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, such as when to choose list_tags over list_branches or list_repos. It lacks any mention of exclusions, prerequisites, or alternative tools, leaving the agent without contextual selection help.

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

• ncloud_sourcedeploy_approve_canaryB
  3.4/5.0
  Behavior2/5

  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 only states the action 'Approve' without revealing side effects, irreversibility, permissions, or dependency on prior analysis steps. For a mutating operation, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that starts with the verb 'Approve' and immediately conveys the action and target. Every word is necessary, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is part of a canary deployment workflow, as evidenced by sibling tools like reject_canary and get_canary_analysis_steps. The description does not explain the workflow context, prerequisites, or consequences of approval. With no annotations or output schema, this leaves the agent without enough information to use the tool correctly in a multi-step process.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all three parameters (projectId, stageId, scenarioId), achieving 100% schema coverage. The description adds no additional parameter-level meaning, so it meets the high-coverage baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Approve' and identifies the resource as 'a manually analyzed canary version deployment', which clearly distinguishes this tool from siblings like reject_canary or get_canary_analysis_report. The qualifier 'canary' and 'manually analyzed' narrows the scope precisely.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'manually analyzed' implies this tool is used after a human has reviewed canary analysis, providing some contextual guidance. However, it does not explicitly state when to use this over alternatives like reject_canary or approve_deploy, nor does it mention exclusions or prerequisites.

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

• ncloud_sourcedeploy_approve_deployB
  3.4/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects, whether it is a final state change, if it triggers deployment, or if prior conditions must be met. For a mutating approval action, 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no filler. It is appropriately front-loaded, though it sacrifices some useful context for brevity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (3 required string params, no output schema, no annotations), the description is minimally adequate but does not explain the approval workflow, such as what happens after approval or whether it is reversible. More context would make it complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter having a clear description (projectId, stageId, scenarioId). The tool description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Approve a scenario deployment request' clearly states the verb and resource. The name and description make it distinct from sibling tools like reject_deploy, cancel_deploy, and request_deploy_approval, so 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its usage in an approval workflow but does not explicitly state when to use it versus alternatives such as reject_deploy or request_deploy_approval. No prerequisites (e.g., a pending approval) or exclusions are mentioned.

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

• ncloud_update_custom_resourceB
  3.4/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds no further behavioral context, such as whether resourceData replaces the entire resource or if the resource must exist. It does not contradict annotations, but also does not enrich them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence of eight words, front-loaded with the verb and resource, containing no redundant or extraneous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an update operation, the description lacks critical behavioral context: it does not specify whether resourceData replaces existing data, what happens if the resourceId does not exist, or what the response contains. Even with full schema coverage, the update semantics remain ambiguous, creating a significant gap for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all three parameters, achieving 100% coverage. The description itself adds no extra parameter semantics beyond what the schema already conveys, matching the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Update' and clearly identifies the resource as 'user-defined custom resource in Cloud Insight', which distinguishes it from sibling tools like create, get, list, and delete. It unambiguously states the action performed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when an existing custom resource needs modification, but it provides no explicit when-not-to-use guidance or references to alternatives. The context is clear from the tool name and sibling set, but no exclusions or additional 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.

• ncloud_add_acg_outbound_ruleA
  3.5/5.0
  Behavior3/5

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

  Annotations include destructiveHint: false, which provides a safety signal. The description adds that this is an additive mutation ('Add'), but does not disclose potential side effects (e.g., whether rules are appended, duplicate handling, or permission requirements). With annotations present, the baseline is lower, and the description adds minimal context beyond the action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no unnecessary words. It is appropriately terse and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (7 params, mutual exclusions) and the absence of an output schema, the description only covers the basic purpose. While the schema documents parameters, the description lacks preconditions, expected behavior, or result information, leaving important gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 7 parameters have rich descriptions in the schema, including mutual exclusions (ipBlock vs. accessControlGroupSequence) and conditional requirements (portRange for TCP/UDP). The tool description itself adds no parameter information, so it does not exceed the schema baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Add' and a specific resource 'outbound rule to an Access Control Group', clearly distinguishing it from inbound rule tools like ncloud_add_acg_inbound_rule. It precisely conveys the action and target.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool vs. alternatives such as ncloud_add_acg_inbound_rule, nor are prerequisites (e.g., existing ACG and VPC) mentioned. The description gives no context for selection.

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

• ncloud_add_mysql_usersA
  3.5/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond what the annotations already provide (destructiveHint=false). It does not mention permissions, idempotency, error scenarios, or side effects. The one-line description simply reiterates the tool's purpose without enriching the agent's understanding of the operation's behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that directly states the action and target. Every word is necessary, and it is front-loaded with the main purpose. There is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple add operation with a well-detailed schema, the description is minimally adequate. However, it lacks useful context such as whether the operation is idempotent, what happens if a user already exists, or any prerequisites. Given no output schema, the agent might benefit from more information, but the tool's simplicity keeps it at an acceptable level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with clear descriptions for both parameters (cloudMysqlInstanceNo and cloudMysqlUserList). The description does not add any extra meaning beyond the schema, so it stays at baseline. It does not clarify the allowed values for 'authority' (e.g., READ, DDL, CRUD) which are enumerated only in the schema but not as enums.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (add) and the target resource (users to a Cloud DB for MySQL instance). It distinguishes this tool from siblings like ncloud_add_mysql_databases, ncloud_change_mysql_users, and ncloud_delete_mysql_users by specifying the exact operation and object.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you need to add users to a MySQL instance. However, it does not explicitly mention when not to use it or provide alternatives such as ncloud_change_mysql_users for modifying existing users. The guidance is minimal and relies on the user understanding the verb 'add'.

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

• ncloud_add_network_acl_inboundA
  3.5/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the action itself. Annotations only declare destructiveHint=false, so the agent knows it's non-destructive, but nothing about rule evaluation order, reversibility, or conflict handling 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no waste, front-loading the core purpose. It is appropriately sized for a simple add-operation where schema carries the parameter detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the schema covers parameters, the description omits important context like priority ordering of rules, the mutual exclusivity of ipBlock and denyAllowGroupNo, and what happens when a rule already exists. It is sufficient for a basic understanding but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 adds no parameter-level detail, but the schema already provides meaningful descriptions for all 8 parameters, including examples and alternatives.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Add an inbound rule to a Network ACL' clearly states the action (add) and resource (Network ACL inbound rules). It distinguishes itself from sibling tools like ncloud_add_network_acl_outbound and ncloud_remove_network_acl_inbound by specifying the rule direction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (use for inbound rules) but provides no explicit guidance on when to choose this over alternatives, nor any exclusions. It does not mention related tools like the outbound counterpart, leaving the agent to infer from the name.

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

• ncloud_add_placement_group_serverA
  3.5/5.0
  Behavior3/5

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

  The description simply states the action without disclosing additional behavioral traits beyond what the 'destructiveHint: false' annotation already implies. It does not mention side effects, reversibility, or requirements. With the annotation covering the safety profile, the description adds marginal value, so a baseline score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with nine words, concisely and front-loaded with the action. Every word contributes to clarity, with no filler or repetition. It is optimally sized for a simple operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the operation (2 parameters, no output schema), the description is adequate at a basic level. However, it does not cover potential constraints (e.g., placement group capacity, server status) or explain the response format. For an agent, this is minimally sufficient but not rich enough to handle edge cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for both parameters ('Placement group number' and 'Server instance number to add'), giving 100% coverage. The description does not add extra meaning 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Add') and resource ('a server instance to a placement group'), clearly stating the operation. It distinguishes itself from the sibling tool 'ncloud_remove_placement_group_server' by the opposite action. The tool name and description are aligned, leaving no ambiguity about what it does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, prerequisites, or any exclusions. For example, it does not mention that the placement group must exist or that the server must not already be in a placement group. This leaves the agent without context for appropriate invocation.

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

• ncloud_add_routeA
  3.5/5.0
  Behavior2/5

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

  The description only restates the basic action and adds no behavioral context beyond the annotation's non-destructive hint. It does not disclose prerequisites, potential conflicts with existing routes, target validation, or side effects, which are important for a network operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no wasted words. It is appropriately concise and front-loaded, conveying the essential action immediately.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is minimal but the schema is detailed, covering all parameters. However, it does not explain the broader context of route tables or the outcome of the operation. Given the moderate complexity of the tool (networking resource), a bit more context would be helpful, but the current description is not wholly inadequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter having a clear description (e.g., targetTypeCode with allowed values, destinationCidrBlock with format). The description itself adds no parameter details, so it relies on the schema, which is sufficient. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description "Add a route to a route table" clearly states the action (add) and the resource (route to a route table), which distinguishes it from sibling tools like ncloud_remove_route or ncloud_list_routes. 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (when you want to add a route) but does not explicitly state when not to use it or mention alternatives. It lacks explicit exclusions or comparisons with related tools such as ncloud_remove_route.

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

• ncloud_cdnplus_get_monitoringA
  3.5/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this is a safe read operation. The description adds context about the type of data (traffic, requests) and the multi-instance, time-range scope, but it does not disclose return format, pagination, or other behavioral traits beyond the annotation. This is useful but not rich context, consistent with a 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, well-structured sentence that front-loads the action and resource, with no filler or repetition. Every phrase adds meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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 bears responsibility for explaining what the response will contain. It mentions traffic and requests, but it does not describe the response structure, aggregation level, or per-instance behavior. This is a clear gap, making the description minimally viable but incomplete for an agent needing to understand the full result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 reinforces that cdnInstanceNoList is for one or more instances and startDate/endDate form a time range, but it adds no new parameter details beyond what the schema already documents.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation ('Get CDN+ monitoring data') with specific details about what is retrieved (traffic, requests) and the scope (one or more instances over a time range). It is specific enough to distinguish from most sibling tools, though it does not explicitly differentiate from the similar ncloud_globalcdn_get_monitoring tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context: it is for retrieving CDN+ monitoring data over a time range for specified instances. However, there is no explicit guidance on when to use this tool versus alternatives (e.g., Global CDN monitoring) or any exclusions, so the guidance is mostly implied.

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

• ncloud_cdss_disable_public_domainA
  3.5/5.0
  Behavior2/5

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

  The annotations already declare idempotentHint=true and destructiveHint=false, so the description carries less burden. However, the description does not add any behavioral context beyond the action itself, such as prerequisites, reversibility, or effects on existing access. No additional transparency is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, front-loaded with the action, and contains no redundant or vague language. It earns its place efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, the description is minimally adequate. However, it lacks any context about prerequisites, response behavior, or relationship to sibling tools, which a more complete description could provide.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter serviceGroupInstanceNo is fully described in the schema as 'Cluster instance number' (100% coverage). The description adds no additional parameter context, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Disable') applied to a specific resource ('public domain for CMAK management tool access'). This is unambiguous and distinguishes the tool from siblings like enable_public_domain and disable_public_endpoint.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied by the tool's name and description: use it when you need to disable public domain access. However, there is no explicit guidance on when to prefer this over alternatives, such as the related enable_public_domain or disable_public_endpoint tools.

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

• ncloud_cdss_disable_public_endpointA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is known. The description adds the scope 'broker nodes' but does not disclose side effects (e.g., making broker nodes inaccessible from public networks) or any state change implications beyond the basic action. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence with no unnecessary words. It is front-loaded with the action and clearly scoped, making it easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With one parameter and no output schema, the description is simple but lacks context about when to use it, related enable/disable tools, and potential impact. The sibling CDSS tools and the presence of an enable_public_endpoint counterpart suggest more contextual information could be provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the sole parameter (serviceGroupInstanceNo) as 'Cluster instance number' with 100% coverage. The description does not add additional meaning about how to obtain or use the instance number, so it does not improve on the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Disable') and the target resource ('public endpoint') with a specific scope ('for broker nodes'). It distinguishes from sibling tools like ncloud_cdss_enable_public_endpoint and ncloud_cdss_disable_public_domain by naming the exact operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides only a single statement of the action with no guidance on when to use it, prerequisites, or alternatives. It does not mention the inverse relationship with enable_public_endpoint or any conditions under which this should be invoked.

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

• ncloud_cdss_get_server_generationsA
  3.5/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already conveys the safe read-only nature. The description adds only the semantic clarification 'hypervisor types' but does not disclose additional behaviors such as response format or pagination. This does not contradict the annotation, but adds minimal behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence of nine words, front-loaded with the action and resource. There is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool, the description is adequate. It explains what the tool returns (server generations/hypervisor types) but does not mention the exact return type or any potential edge cases. Given the tool's simplicity, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description carries no burden to explain parameter usage. The parenthetical '(hypervisor types)' adds useful meaning to the term 'generations', which is helpful given no schema provides parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource 'available server generations (hypervisor types)' with scope 'for CDSS'. This distinguishes it from sibling tools like ncloud_cdss_get_server_spec_list and ncloud_ses_get_server_generations, though it does not explicitly reference alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus other similar list tools (e.g., ncloud_cdss_get_server_spec_list, ncloud_cdss_get_node_products). It is a bare statement without any context or alternative references.

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

• ncloud_cdss_reset_cmak_passwordA
  3.5/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries the full burden. It only says 'reset' with no disclosure of side effects, whether the cluster will be interrupted, if a rolling restart is required, or if the existing session is invalidated. For a mutating action on a cluster, this is insufficient transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the purpose. It is concise with no filler or redundant information, matching the ideal length for a simple reset operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, and the description does not explain return behavior, expected confirmation, or whether the reset causes temporary unavailability. However, with only 2 well-documented parameters and a straightforward operation, the description is minimally sufficient but could benefit from context about post-reset effects or prerequisites.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters already described ('Cluster instance number' and 'New CMAK password (8-20 chars, letters+numbers+special)'). The description itself does not add further parameter meaning beyond what the schema provides, so baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Reset'), the target resource ('CMAK access account password'), and the scope ('for a CDSS cluster'). It uses a specific verb and distinguishes this from sibling tools like ncloud_cdss_restart_cmak and other CDSS management operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when a CDSS cluster's CMAK password needs resetting, but it does not explicitly state when to use it vs alternatives, nor does it mention any prerequisites or exclusions. The context is clear from the name but lacks explicit guidance.

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

• ncloud_cdss_upgrade_statusA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavioral expectations. It only says 'Get', implying a read-only operation, but does not explain what fields are returned, whether an upgrade must be in progress, or how to interpret status values. This is insufficient for an agent to know what to expect from the response.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that immediately states the purpose. It contains no filler or redundant information, 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one parameter, no output schema), but the description still leaves gaps: it does not specify what 'progress status' includes (e.g., percentage, current step), whether it can be polled, or what errors might occur if no upgrade is in progress. For a status tool, more detail would be valuable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents the single parameter (serviceGroupInstanceNo) as 'Cluster instance number', achieving 100% coverage. The description does not add any additional meaning, so the baseline score of 3 applies. It is clear enough but unremarkable.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves the progress status of a version upgrade operation, using a specific verb ('Get') and resource. This distinguishes it from sibling tools like ncloud_cdss_upgrade_version and ncloud_cdss_upgrade_precheck, which perform the upgrade and precheck respectively.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage after an upgrade has been initiated, but it does not explicitly state when to use this tool versus alternatives like ncloud_cdss_upgrade_version or ncloud_ses_get_upgrade_progress. There is no mention of prerequisites, polling patterns, or when not to use it.

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

• ncloud_change_mongodb_config_countA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond the action itself, such as no mention of side effects, long-running operations, or constraints. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence of 10 words, front-loaded with the verb 'Change'. It is concise and effective with no unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with two fully described parameters and safety annotations, but the description omits any constraints on configServerCount (e.g., allowed values, minimums) or operational effects (e.g., whether the change causes downtime). While annotations help, the description alone is not fully complete for an agent to anticipate all implications.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both parameters (configServerCount and cloudMongoDbInstanceNo). The description adds no parameter details beyond baseline, so scoring is at the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (change), the resource (number of Config servers), and the scope (MongoDB Sharded Cluster instance). It is specific and distinguishable from sibling tools like ncloud_change_mongodb_secondary_count and ncloud_change_mongodb_mongos_count by focusing on Config servers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, nor any exclusions or prerequisites. It simply states the function without any contextual direction.

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

• ncloud_change_mongodb_usersA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare the tool as idempotent and non-destructive. The description adds that it changes password within a MongoDB DB instance, but does not disclose behavioral details such as whether users must already exist, password format constraints, or impact on active connections. It provides minimal additional context 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the verb and target, with no unnecessary words or repetition of schema fields. It gets straight to the point.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple and parameters are fully described, but the description lacks important context for a mutation: no mention that it applies to existing users, no password constraints, and no indication of return value or async behavior (no output schema). It is adequate for basic invocation but leaves some practical questions unanswered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: both parameters have clear descriptions (instance number, list of users with name and new password). The description restates 'password' but adds no extra semantic detail beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation (change), target resource (user information/password), and scope (Cloud DB for MongoDB instance). The verb 'change' distinguishes it from sibling tools like ncloud_add_mongodb_users and ncloud_delete_mongodb_users, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that it updates existing users, distinguish it from add/delete operations, or note any prerequisites. The agent must infer usage from tool naming alone.

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

• ncloud_change_nas_volume_sizeA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false, which cover the safety profile. The description adds no further behavioral context (e.g., whether the operation is online, requires stopping the volume, or has billing implications), but it does not contradict 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence delivers the core purpose without wasted words. It is appropriately concise for a simple two-parameter operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only two parameters, full schema coverage, and non-destructive/idempotent annotations, the description covers the basics. However, it lacks usage context and any note about operational behavior or expected response, making it adequate but not complete for an agent unfamiliar with NAS resizing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both parameters are described with useful details (volumeSize ranges 500-10000 GB in 100GB increments, nasVolumeInstanceNo identifies the volume). The description adds no meaning beyond the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Change') and resource ('size of a NAS volume instance'), clearly distinguishing this tool from NAS siblings that create, delete, restore, or configure access control. 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.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states only the action and target, with no guidance about when to use this tool versus alternatives (e.g., creating a new volume, setting access control, or restoring from snapshot). No prerequisites or exclusions are mentioned.

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

• ncloud_change_target_group_configA
  3.5/5.0
  Behavior3/5

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

  Annotations declare the operation as idempotent and non-destructive, and the description does not contradict this. However, the description adds no extra behavioral context beyond listing the configurable parameters, which are already in the schema. It does not disclose immediate effects, protocol constraints, or potential impact on traffic.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  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 resource, with a parenthetical list of settings. Every word earns its place; there is no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate for a simple configuration change tool given the rich schema and safety annotations, but it is minimal. It does not mention return values, whether changes apply immediately, or any usage caveats. For a mutating operation without an output schema, slightly more context would be beneficial.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with all four parameters well described. The description lists three configurable aspects, adding a high-level summary but no new detail beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's purpose: changing target group configuration, specifically algorithm, sticky session, and proxy protocol. This is specific and distinguishes it from sibling tools like health check or description updates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, related tools, or specify that it is for modifying these particular settings while other tools handle health checks or descriptions.

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

• ncloud_change_target_group_healthA
  3.5/5.0
  Behavior3/5

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

  Annotations indicate idempotentHint true and destructiveHint false, covering the safety profile. The description adds no additional behavioral context beyond rephrasing the tool name, but it does not contradict the annotations. It could have mentioned immediate application or side effects, but annotations carry most of 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence that is clear and free of unnecessary words. It fully and accurately conveys the tool's purpose without padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich schema and annotations, the description is minimally adequate but lacks context on prerequisites, whether at least one health check parameter must be provided, or the impact of the change. Without this, an agent might invoke it incorrectly (e.g., with no parameters other than targetGroupNo).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptive documentation for all parameters (100% coverage). The tool description itself adds no parameter-level meaning beyond what the schema already contains, so the schema carries the semantic weight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description precisely states that it changes target group health check configuration, using a specific verb and resource. It clearly distinguishes this from sibling tools like ncloud_change_target_group_config, which likely modifies broader target group settings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided. The description does not explain when to use this tool versus alternatives like ncloud_change_target_group_config or ncloud_set_target_group_description, nor any prerequisites or conditions for invoking it.

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

• ncloud_copy_rule_groupA
  3.5/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries full burden. It discloses the copy operation creates a new rule group, but does not clarify whether the copy is a deep copy (including all rules and settings), whether the source is unaffected, or whether any permissions are required. The write-like nature of the operation is only implied by 'copy' and 'create a new one'.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single 12-word sentence that is front-loaded with the key verb and resource. It contains no filler or redundant information, making it highly concise and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only two simple parameters, no output schema, and no nested objects, the tool is relatively simple. However, the description does not specify what the response contains (e.g., new rule group ID) or any behavioral caveats like name uniqueness. It is minimally sufficient but leaves room for more detail about the copy semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both groupName and ruleGroupId have clear descriptions. The tool description adds minimal value beyond the schema, only reinforcing that the source is 'existing' and the new group is 'new'. Since the schema already documents parameter meaning, the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Copy') and the resource ('Cloud Insight event rule group'), with the explicit purpose of creating a new one. This distinguishes it from sibling tools like ncloud_create_rule_group (which creates from scratch), ncloud_update_rule_group, and ncloud_delete_rule_group.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when you want to duplicate an existing rule group, but it does not explicitly state when to use it over alternatives such as create_rule_group, nor does it mention any prerequisites or constraints (e.g., the source group must exist). No when-not-to-use guidance is provided.

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

• ncloud_create_acgA
  3.5/5.0
  Behavior3/5

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

  The description is minimal but consistent with annotations (destructiveHint=false). It adds the context that the ACG is created within a VPC but does not disclose post-creation state (e.g., initially empty rules) or return format, which the agent must infer.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words, earning a top score for efficiency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple create tool, the description is clear and the schema covers all parameters, but the absence of any note about the response structure or initial ACG state leaves moderate gaps. It is adequate but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed descriptions for all three parameters, including naming constraints for accessControlGroupName. The description adds no additional parameter semantics, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Create' with the explicit resource 'Access Control Group' and scoping 'in a VPC', clearly distinguishing it from sibling ACG tools like list_acgs or add_acg_inbound_rule.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as creating a Network ACL or adding rules to an existing ACG. The description lacks prerequisites (e.g., requiring an existing VPC) though vpcNo is marked required in the schema.

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

• ncloud_create_fabric_clusterA
  3.5/5.0
  Behavior2/5

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

  Annotations already indicate destructiveHint=false. The description adds no additional behavioral traits beyond what the name implies. It does not disclose any side effects, required permissions, or what happens after creation. For a create tool, it would be useful to mention that it is an asynchronous operation or that the new cluster is initially inactive, but no such context is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the primary action and resource. It avoids redundancy and includes a brief clarifying purpose ('for dedicated physical server grouping'). No fluff or irrelevant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple nature of the tool (3 params, no output schema), the description is minimally viable. It could be improved by noting any prerequisites (e.g., a fabric cluster pool must exist) or the outcome beyond just 'create', but it is not severely incomplete. Without an output schema, the description need not explain return values.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are already well-documented in the schema. The description does not add any extra meaning about parameters. Baseline of 3 applies because the schema handles the parameter semantics adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create'), the resource ('a new fabric cluster'), and the purpose ('for dedicated physical server grouping'). This distinguishes it from sibling tools like ncloud_list_fabric_clusters, ncloud_get_fabric_cluster_detail, and ncloud_delete_fabric_cluster, which handle other operations on the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: use when creating a new fabric cluster. However, it does not explicitly state when not to use it or mention alternatives (e.g., if you need to modify an existing cluster, use change_* tools). No exclusions or prerequisites are given, so it lacks explicit guidance beyond the verb 'create'.

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

• ncloud_create_member_server_imageA
  3.5/5.0
  Behavior3/5

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

  Annotations only include destructiveHint=false. The description adds the requirement that the source must be a running server instance, providing some context, but does not disclose other behavioral details such as asynchrony or impact on the source server.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that is direct and free of fluff. It efficiently conveys the core operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is minimal but sufficient for a simple create operation with clear schema. It could benefit from noting that member server image creation may be asynchronous or require the server to be in a specific state, but given the schema annotations, it's adequate for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add parameter-specific information beyond what's in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (create) and the specific resource (member server image) from a running server instance. It distinguishes from generic server image creation by naming 'member server image', aligning with sibling tools like ncloud_delete_member_server_images. However, it does not explicitly contrast with ncloud_create_server_image.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternative tools are mentioned. The description implies usage when you want to create a member server image from an active server, but lacks prerequisites or exclusions.

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

• ncloud_create_metrics_groupA
  3.5/5.0
  Behavior3/5

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

  The description aligns with the non-destructive annotation (destructiveHint: false) since 'Create' implies a benign write operation. However, it adds no additional behavioral context such as idempotency, permissions, validation rules, or what happens on duplicates. With annotations present, the absence of contradiction warrants a baseline 3, but no extra credit is earned.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It packs the core purpose and the Korean synonym into minimal words, making it easy to scan and remember.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 3 well-documented parameters and no output schema, the description could be more helpful by explaining the relationship between metrics groups and rule groups, or what the response includes (e.g., group ID). It is adequate for a simple create but omits surrounding context that sibling tools and the Cloud Insight ecosystem imply.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with prodKey, groupName, and metricList all documented in the input schema. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies as the schema already carries semantic weight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Create a new Cloud Insight rule template (감시 항목 그룹 / metrics group)' specifies a clear verb and resource, and explicitly names the Korean term to disambiguate from sibling tools like create_rule_group and create_monitor_group. It distinguishes the metrics group entity while staying concise.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_create_rule_group, ncloud_create_monitor_group, or ncloud_update_metrics_group. The description does not mention prerequisites, typical scenarios, or any exclusion criteria, leaving the agent to infer usage purely from the name.

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

• ncloud_create_placement_groupA
  3.5/5.0
  Behavior2/5

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

  Annotations only include destructiveHint=false, which is consistent with 'Create'. The description adds no context about side effects, idempotency, required permissions, or response format. Since annotations are minimal, the description carries the burden and falls short.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple with only two optional parameters and no output schema. The description and schema are adequate for basic invocation, but the lack of behavioral details and usage guidance leaves some gaps for an agent to fully understand the tool's effects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no parameter-specific meaning beyond what is already in the schema, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create'), the resource ('placement group'), and the purpose ('for physical server placement control'). This distinguishes it from sibling tools like list/get/delete placement group, which have different verbs and resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when you need to create a placement group), but it does not explicitly mention alternatives or exclusions. No guidance is given about prerequisites or when not to use it.

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

• ncloud_create_route_tableA
  3.5/5.0
  Behavior2/5

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

  Annotations only provide destructiveHint=false, and the description adds no additional behavioral context. It does not disclose side effects, permission requirements, or whether the operation is asynchronous or returns a resource ID, which is a notable gap for a mutating create operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that conveys the core purpose without any fluff or repetition. It is front-loaded and earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward create operation with well-documented schema parameters, the description is minimally adequate. However, it omits any mention of return values or side effects, and the lack of an output schema places more burden on the description to clarify expected outcomes.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters (vpcNo, routeTableName, routeTableDescription, supportedSubnetTypeCode) already have detailed descriptions in the schema. The tool description adds no extra parameter semantics, which is acceptable given the schema's completeness.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Create a new route table in a VPC' clearly states a specific verb and resource, and the VPC context distinguishes it from sibling route table operations like delete or list. It is unambiguous and easily understood.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied by the verb 'Create'—use when a new route table is needed. However, there is no explicit guidance on when to prefer this tool over alternatives, nor any mention of prerequisites or exclusions.

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

• ncloud_delete_metrics_groupA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true, and the description merely reiterates 'Destructive' with an emoji. It adds a small clarification that the target is a rule template but does not disclose irreversibility, effect on related rules, or that explicit confirmation is required. No contradiction with annotations, but limited extra behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with a warning symbol. Efficient and free of filler; every word conveys meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  As a destructive delete operation, the description is minimal but the schema and annotations fill critical gaps (parameter semantics, destructive flag). Missing usage differentiation and confirmation details are the main shortcomings, making it adequate but not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and both metricsGroupId and confirm are clearly described in the schema. The description adds no extra parameter meaning, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific action ('Delete') and clearly identifies the resource ('Cloud Insight rule template (metrics group)'). It even clarifies what a metrics group is, making the purpose unambiguous even for agents unfamiliar with Cloud Insight.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives like ncloud_delete_metrics_group_by_id or ncloud_delete_metrics_group_force. It does not mention the confirm parameter requirement or any prerequisites, leaving the agent without decision context.

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

• ncloud_detach_block_storageA
  3.5/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, which cover the safety profile. The description does not add behavioral context beyond the action itself, such as whether data remains intact, whether the server needs to be stopped, or what happens to the detached storage afterward.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is concise, front-loaded with the action, and contains no redundant information. It is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one parameter, full schema coverage, and annotations, the description is mostly complete. However, it omits any context about the effects of detaching (e.g., whether the storage remains attached to the account, whether the server must be stopped, or any post-conditions) which would be helpful for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single parameter blockStorageInstanceNoList, with a clear description. The tool description adds no additional semantics beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'detach', the resource 'block storage instances', and the target 'from their servers'. This is specific and distinguishes it from sibling tools like attach_block_storage or delete_block_storage.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when you want to detach block storage from servers) but does not explicitly mention alternatives or exclusions. The context is clear enough from the action, but there is no guidance on prerequisites or when not to use it.

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

• ncloud_dns_get_domain_detailA
  3.5/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, and the description merely echoes this with 'Get detailed information' without adding context such as what fields are returned, error behavior, or any special constraints. The description provides no behavioral insights beyond what the annotation already communicates.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no wasted words. It is front-loaded with the action ('Get') and resource ('detailed information') and is appropriately brief for a simple getter tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description should ideally indicate what kind of detailed information is returned (e.g., records, TTL, status). It only says 'detailed information', which is vague. For a simple one-parameter tool with a readOnlyHint, this is adequate but leaves room for improvement.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (domainId is described as 'Domain ID to query'). The tool description adds no additional parameter semantics beyond the schema, which is the baseline for high coverage. No further elaboration is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get detailed information about a specific Global DNS domain.' This clearly differentiates it from sibling tools like ncloud_dns_list_domains (which lists domains) and other DNS operations. The scope is explicit and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (when you need details for a specific domain) but does not explicitly state when to use this tool versus alternatives, nor does it name any sibling tools for comparison. Sibling differentiation is inherent from the name, but no direct guidance or exclusions are provided.

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

• ncloud_drm_get_site_logsA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds that it retrieves 'event logs', which clarifies the data type but does not disclose additional behaviors such as ordering, time range, or pagination behavior. Since the read-only nature is annotated, the description does enough for a simple read operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words or repetition. It efficiently conveys the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only log retrieval with full schema coverage and readOnlyHint annotation, the description is minimally adequate. However, it lacks any broader context such as whether logs are recent, how they are sorted, or when this tool should be preferred. Without an output schema, it would benefit from a brief note on return format or filter behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all three parameters (siteId, pageNo, pageSize) already have descriptions in the schema. The description does not add extra meaning beyond resourcing, but the schema fully documents the parameters. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the resource ('event logs for a DRM site'). It is specific enough to distinguish from sibling tools like ncloud_drm_get_policy_logs (policy logs vs event logs) and generic search_logs. The verb and resource are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention related tools like ncloud_drm_get_policy_logs or ncloud_search_logs, nor does it state any exclusions or prerequisites. The description is purely functional with no contextual usage direction.

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

• ncloud_export_cache_backupA
  3.5/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, and the description does not contradict this; 'export' implies copying data with no mutation of the source. The description adds the destination context ('to Object Storage'), but it does not disclose aspects like whether existing objects are overwritten, whether the operation is asynchronous, or any access requirements. It adds minimal behavioral context 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, short sentence that front-loads the action verb and resource. Every word is informative, and there is no redundant or extraneous content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, so the description should compensate by explaining the operation's outcome, but it only states the high-level function. The schema fully documents parameters, covering the inputs, but the description omits workflow details (e.g., why cloudCacheExportObjectList is a list, how it relates to a backup file, or post-export behavior). It is adequate but leaves gaps for a new agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all five parameters having descriptions. The tool description does not add parameter-specific detail beyond what the schema already provides, so the baseline of 3 applies. The description's mention of Object Storage aligns with the bucketName/folderPath parameters but adds no extra semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Export') and names the exact resource ('Cloud Cache backup file') and destination ('Object Storage'), clearly distinguishing it from sibling tools like list or create backup operations. It is unambiguous and directly states the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as ncloud_create_cache_manual_backup or other export backup tools (e.g., ncloud_export_mysql_backup). It does not mention prerequisites, ordering, or scenarios where this tool is preferred, leaving the agent without usage context.

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

• ncloud_functions_create_packageA
  3.5/5.0
  Behavior3/5

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

  The annotations already declare destructiveHint: false, and the description adds that the tool can update an existing package, which is useful beyond the annotation. However, it does not disclose other behavioral traits such as idempotency, required permissions, or the effect on existing actions/triggers within the package.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded with the action and resource. Every word earns its place, and there is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is minimal but combined with the fully-described schema, it provides a basic understanding. However, there is no output schema, and the description does not explain return values, error semantics, or the distinction between creation and update behavior in detail. For a simple create/update tool, this is adequate but not thorough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameters with descriptions, including platform enum, parameters object, description, and packageName. The description adds no additional semantic meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Create or update a Cloud Functions package' clearly identifies the action (create/update) and the resource (Cloud Functions package). It distinguishes itself from sibling tools that list, get, delete, or invoke packages/actions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like ncloud_functions_create_action or ncloud_functions_delete_package. The description does not mention prerequisites, constraints, or scenarios where this tool is preferred.

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

• ncloud_functions_get_trigger_activation_detailA
  3.5/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already communicates that this is a safe read operation, so the bar is lower. However, the description adds no behavioral context beyond the fact that it retrieves a specific activation; it does not disclose what fields will be returned, any permission requirements, or rate limit considerations. It is not contradictory, but adds minimal value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that delivers the core purpose without any filler or redundancy. It is perfectly concise and front-loaded, with every word contributing to meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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 should provide more detail about what 'detailed information' means or what the response contains. It also lacks context on how to obtain activationId, which is a required parameter. The schema and readOnly annotation provide some completeness, but the description alone leaves the user guessing about the return payload and the relationship to the list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage: all three parameters (platform, triggerName, activationId) include meaningful descriptions. The tool description itself adds nothing beyond the schema, so the baseline of 3 applies. The schema already explains the purpose of each parameter, and the description does not need to compensate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get detailed information about a specific trigger activation' clearly states a specific verb (get) and resource (trigger activation), and the qualifier 'specific' distinguishes it from list-style siblings like ncloud_functions_get_trigger_activations. It also aligns with the name, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives. It does not mention that this is the single-item detail counterpart to ncloud_functions_get_trigger_activations, nor does it describe any prerequisites such as obtaining an activationId first. The only clue is the word 'specific' in the description, which is 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.

• ncloud_functions_link_trigger_actionA
  3.5/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries full responsibility for behavioral disclosure. It states the core action and purpose but does not mention side effects (e.g., whether an existing link is replaced), prerequisites (e.g., trigger and action must exist), or idempotency. This is a meaningful gap for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, tightly written sentence with the verb and resource front-loaded. There is no redundate text, making it highly concise and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 3-parameter mutation with a complete schema and no output schema, this description is minimally adequate. It identifies the operation but lacks contextual details like prerequisites, idempotency, or error conditions. The agent can still invoke it correctly given the schema, but the description doesn't go beyond the bare minimum.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: all three parameters have meaningful descriptions in the schema (e.g., actionName format, platform enum). The tool description itself adds no parameter-specific details, so the baseline of 3 for full schema coverage is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Link' with a clear resource ('an action to a trigger') and adds purpose ('for event-based execution'). This clearly distinguishes it from sibling tools like ncloud_functions_unlink_trigger_action, which removes the link.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it (when you want event-driven execution by linking a trigger to an action) but doesn't explicitly state when not to use it or reference alternatives. The sibling unlink tool exists, yet the description doesn't mention it or any exclusions.

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

• ncloud_get_coin_history_listA
  3.5/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this as a safe read operation, and the description aligns with it ('Get'). The description adds that it returns balance, usage history, and status, but does not disclose additional behaviors such as pagination limits, required permissions, or any side effects. Since annotations cover the core safety aspect, this is acceptable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (two sentences) and front-loaded with the primary action. Every word contributes to clarifying purpose and scope, with no unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, and the description only gives a high-level summary of the return contents. It does not hint at the optional filtering parameters (e.g., isPartner, isOrganization, memberNoList) or pagination behavior, which are relevant for an agent deciding how to invoke this tool. The schema covers parameter details, but the description lacks sufficient context to fully guide usage for complex queries.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All six parameters have schema descriptions (100% coverage), so the schema carries the parameter meaning. The tool description does not add extra semantic value beyond what the schema already provides, but it does mention 'all or specific coins', which loosely relates to the filtering parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('coin history list'), and clearly states what it returns: 'coin balance, usage history, and status'. It also scopes the operation to 'all or specific coins assigned to the account', which differentiates it from other history/list tools in the sibling set.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or alternative tools. The description only states what it does, leaving the agent to infer usage context.

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

• ncloud_get_contract_usage_list_by_dailyA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the behavioral detail that results are broken down per contract, which goes beyond the name, but it does not describe pagination, response envelope, or any role/privilege nuances.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with no filler. It front-loads the main action and then states the key output detail, earning high marks for efficiency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and 12 parameters, the description could provide more context about response structure or filter behaviors. It covers the core intent but omits pagination behavior and how filters like contractNo, memberNoList, or productItemKindDetailCode interact, leaving some gaps for a complex tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the description is not required to detail parameters. It only reiterates the date range constraint (max 3 months) that the schema already documents, adding no extra semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' with a clear resource 'daily contract usage list' and states the return scope 'per contract' and 'date range (max 3 months)'. It effectively distinguishes itself from the sibling 'ncloud_get_contract_usage_list' by emphasizing 'daily', though it does not explicitly name the alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving daily usage within a date range and enforces a 3-month limit, which is helpful. However, it does not explicitly state when to use this tool over alternatives like ncloud_get_contract_usage_list or mention any exclusions or prerequisites.

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

• ncloud_get_init_script_detailA
  3.5/5.0
  Behavior2/5

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

  The readOnlyHint annotation already indicates a safe read operation, so the description only needs to add additional context. However, it adds none beyond restating the tool's purpose—no information about return format, error behavior, or any constraints. The description is consistent with the annotation but provides no extra transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the verb and resource, with no filler or repetitive content. It is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With one required parameter, readOnlyHint annotation, and no output schema, the description is minimally adequate. However, it does not indicate what 'detailed information' includes (e.g., script name, creation time, content), which could help the agent anticipate the response. For such a simple tool, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the single parameter initScriptNo described as 'Init script number to query'. The description adds no additional parameter semantics, but the baseline of 3 is appropriate when the schema fully documents the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('detailed information about a specific init script'), clearly distinguishing it from listing all init scripts or creating/deleting one. This matches the pattern of sibling tools like ncloud_list_init_scripts and ncloud_create_init_script.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the word 'specific' and the contrast with sibling 'list_init_scripts', but the description does not explicitly state when to use this tool over list/create/delete alternatives. No exclusions or prerequisites are mentioned.

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

• ncloud_get_metrics_groupA
  3.5/5.0
  Behavior2/5

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

  The annotation readOnlyHint=true already signals that this is a safe read operation. The description adds no additional behavioral context (e.g., return format, pagination, authentication needs, or any caveats) beyond what the annotation provides. It introduces the term 'rule template' but that is a semantic clarification, not a behavioral trait.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the action and resource. It contains no filler or redundant wording, earning every word.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has one parameter, no output schema, and simple semantics. The description states the purpose but lacks detail about what 'detailed information' includes (e.g., configuration fields, thresholds, associated rules). Since there is no output schema, the description could have elaborated on the returned content to be more self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: the single parameter metricsGroupId is described as 'Metrics group ID to retrieve details for'. The description adds minimal extra meaning by equating 'metrics group' with 'rule template' and noting 'Cloud Insight', but the schema already conveys the parameter's purpose. Baseline of 3 is appropriate given full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the resource ('specific Cloud Insight rule template (metrics group)'), and uses 'specific' to indicate a single-item retrieval. This distinguishes it from sibling tools like ncloud_list_metrics_groups (list all) and ncloud_get_rules_by_metrics_group (retrieve rules for a group).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you need detailed info about a specific metrics group, identified by an ID. However, it does not explicitly mention alternatives or prerequisites (e.g., obtain the ID via list_metrics_groups). The guidance is minimal and implicit, not explicit.

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

• ncloud_get_mssql_instance_detailA
  3.5/5.0
  Behavior2/5

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

  The readOnlyHint annotation already declares the tool read-only, and the description adds no behavioral context beyond that. It does not specify what 'detailed information' includes, any response format, or any additional side effects or prerequisites.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of nine words, front-loaded with the verb, and contains no superfluous content. Every word contributes to the meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter and a read-only annotation, so a short description is acceptable. However, 'detailed information' is vague and with no output schema, the agent might not know what fields to expect. It covers the essential use case but lacks specificity about the response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a clear description of the only parameter, so the description need not add parameter details. The tool description does not add meaning beyond the schema, but the baseline is met.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get detailed information') and the specific resource ('a specific Cloud DB for MSSQL instance'). The word 'specific' distinguishes it from list-type siblings, and the 'detailed' modifier indicates a detail-retrieval tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need details for a known MSSQL instance, but it does not explicitly mention alternatives or when not to use it. There is no guidance on first listing instances to obtain the required instance number.

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

• ncloud_get_schema_keysA
  3.5/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already signals a safe read operation, so the description does not need to repeat that. The description adds a small amount of context by specifying the data source ('available in Cloud Insight') and the exact item being listed (cw_key). However, it does not disclose what the returned list contains, whether it can be empty, or any other behavioral details beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that front-loads the action ('Get the list') and follows with the specific object. There is zero wasted language, and every word adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity (no parameters, no output schema), the description is sufficient to understand its purpose and output. It does not explain what cw_key is or how the list is ordered, but such details are unnecessary for this simple read-only retrieval.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description does not need to explain any input fields. The schema is empty with 100% coverage, and the description adds meaningful context about the output (the cw_key list). This meets the baseline for parameterless tools.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: retrieving a list of system schema product keys (cw_key) available in Cloud Insight. The verb 'Get' combined with the specific resource 'system schema product keys' makes the purpose unambiguous. However, it does not differentiate from sibling tools that also retrieve lists or keys, so it misses the top score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or related tools, leaving the agent to infer usage solely from the name and description. No context is given about which scenarios call for this tool rather than another.

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

• ncloud_gtm_get_lb_typesA
  3.5/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, so the description is not required to restate that this is a safe read operation. The description adds useful scope context (that these are for Global Traffic Manager policies), which goes beyond the annotation. However, it does not disclose any additional behavioral details such as whether the result is a list, how it is formatted, or if any special conditions apply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that immediately communicates the tool's purpose. It contains zero filler words and is front-loaded with the action verb 'Get'. Every word contributes meaning, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no parameters, no output schema, and a read-only annotation, the description is adequately complete. It identifies the domain (Global Traffic Manager) and the specific object (load balancer types). The lack of usage guidance is a minor gap, but given the simplicity of the tool, the description is sufficient for an agent to understand what the tool does and how to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters in the schema, so the baseline for this dimension is 4. The description does not need to explain any parameter semantics since there are none. The schema coverage is 100% (vacuously), and the description adds no parameter-related information, which is acceptable given the tool's simplicity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: getting available load balancer types for Global Traffic Manager policies. It uses a specific verb (Get) and resource (load balancer types), and it is not a tautology. However, it doesn't explicitly distinguish from sibling tools like ncloud_gtm_get_resource_types or ncloud_gtm_get_map_types, though the resource is specific enough to avoid major confusion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, nor does it mention any exclusions or prerequisites. It simply states what the tool retrieves, leaving the agent to infer usage context. This is a minimal but functional statement, but it lacks the explicit contextual cues that would help an agent decide between this and similar GTM lookup tools.

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

• ncloud_gtm_update_policy_resourcesA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'all resources' scope, implying a wholesale replacement of the resource set, which is meaningful beyond the annotations. However, it does not explicitly state that existing resources are overwritten or that the provided resourceGroups array becomes the complete new configuration.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence of nine words. Every word earns its place, and there is no redundant or boilerplate content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a moderately complex update tool with no output schema, the description covers the basic purpose but lacks usage guidance and explicit replacement/overwrite semantics. The schema compensates for parameter details, but the absence of any reference to related tools or operational context leaves gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both policyId and resourceGroups described in the input schema. The description adds little beyond the schema, though 'all resources' hints that resourceGroups represents the full desired set. Baseline 3 is appropriate since the schema already does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Update all resources for a specific Global Traffic Manager policy.' The qualifier 'all resources' clearly distinguishes this from the sibling tool ncloud_gtm_update_policy_resource (singular), making the scope unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_gtm_update_policy_resource (singular) or ncloud_gtm_get_policy_resources. There are no exclusions, prerequisites, or context about whether this is a full replacement operation vs. a targeted update.

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

• ncloud_hadoop_backup_configA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full transparency burden. It states what is backed up and the destination, but fails to disclose key behavioral traits such as whether the backup overwrites existing data, whether a bucket must already exist, or whether permissions are required for the Object Storage write. The word 'all' implies scope, but nuances like destructuring location or asynchronous nature are omitted.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the action verb and clearly states the object and target. Every word contributes to conveying the tool's purpose without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple with one required parameter and no output schema, so the description is reasonably adequate. However, it omits details about how the Object Storage bucket is selected, since no bucket parameter exists in the schema, and does not indicate whether the operation returns a job ID or status. These gaps leave some ambiguity for an agent invoking the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents both parameters with clear descriptions, achieving 100% coverage. The description adds no additional parameter-level semantics 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('backup') with a clear resource ('all cluster component configurations') and destination ('Object Storage bucket'), establishing exactly what the tool does. This clearly distinguishes it from sibling tools, which operate on clusters for creation, deletion, or listing but not for configuration backup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context (use when you need to back up Hadoop cluster configurations), but provides no explicit when-to-use guidance, prerequisites, or exclusions. No alternative tools are mentioned, and the description does not explain scenarios where this tool should not be used.

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

• ncloud_hadoop_change_node_countA
  3.5/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, and the description adds no further behavioral context beyond restating the purpose. It does not disclose potential outcomes or side effects of node removal, such as data rebalancing or whether the operation is asynchronous.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler words. Every part is meaningful, directly stating the action, resource, and scope of the operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple with full schema coverage and clear annotations, making the description minimally adequate. However, it lacks any note about operational aspects like async execution, prerequisites, or when not to use it, which would be helpful for a mutation tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and all parameters are described with sufficient detail in the schema. The description does not add additional semantics beyond what the schema already 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action (change worker node count) and resource (Cloud Hadoop cluster), with a parenthetical clarifying that this includes both adding and removing nodes. This distinguishes the tool from related operations like changing node specifications.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used for scaling worker nodes in a Hadoop cluster, but it does not provide explicit guidance on when to use it versus alternatives (e.g., changing node specs) or any exclusions. Clear context exists but no alternatives are mentioned.

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

• ncloud_hadoop_create_notebookA
  3.5/5.0
  Behavior2/5

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

  Beyond the annotation (destructiveHint=false), the description only adds the prerequisite of an existing cluster. It does not disclose that creation may take time, incur costs, or require specific cluster states. With annotations present, the bar is lower, but the description offers minimal additional behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no fluff. Every word earns its place, conveying the core action and attachment constraint efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (13 params, 6 required, no output schema), the description is thin. It provides the essential context but omits prerequisite details like the cluster must be in a certain state, the bucket must exist, or what the response contains. Schema covers params, but the description doesn't tie them together.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for all 13 parameters, so the schema already explains each parameter. The description adds no parameter-level meaning or relationships (e.g., the dependency on useNotebookBlockStorage). Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Create' with a clear resource 'Cloud Hadoop notebook instance' and adds a key qualifier 'attached to an existing cluster'. This clearly distinguishes it from sibling tools like ncloud_hadoop_delete_notebook or ncloud_hadoop_list_notebooks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for creating a notebook on an existing cluster, which gives context but no explicit alternatives or when-not-to-use guidance. It doesn't reference sibling tools or exclusion criteria, so it's not fully instructive.

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

• ncloud_hadoop_get_cluster_detailA
  3.5/5.0
  Behavior2/5

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

  The annotations already declare readOnlyHint=true, but the description adds no behavioral context beyond that. It does not disclose what kind of details are returned, potential exceptions, or any side effects (though none are expected). Since annotations cover the safety profile and the description adds nothing beyond a generic 'get' statement, the contribution to behavioral transparency is minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded and free of unnecessary words. It serves its purpose without extraneous information, achieving high efficiency with no waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple getter with two parameters and no output schema, the description is adequate but does not elaborate on what 'detailed information' includes. Since there is no output schema to explain return values, the description could have been more explicit about the response contents, but the tool name and purpose make it sufficiently clear for this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both 'regionCode' and 'cloudHadoopInstanceNo' having descriptions. The tool description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies. The description does not compensate for any missing schema details, but none are missing.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get detailed information about a specific Cloud Hadoop cluster' clearly identifies the action (get), the resource (Cloud Hadoop cluster), and the scope ('specific'), effectively distinguishing it from listing tools like ncloud_hadoop_list_clusters. This matches the verb-resource-scope ideal and differentiates from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (retrieve details for a specific cluster) but does not explicitly state when to use this tool instead of alternatives, such as listing clusters first to obtain the instance number. No exclusions or alternative tools are mentioned, making the 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.

• ncloud_hadoop_get_notebook_detailA
  3.5/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already indicates a safe read operation, and the description aligns with a read-only 'get' action. However, the description does not disclose what specific details are returned, whether any additional inputs are required (like region), or any other behavioral nuances, so it adds minimal context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded with the verb and resource. There is no redundant or extraneous wording, making it highly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only detail tool with complete parameter schema and a read-only annotation, this description is adequate but minimal. There is no output schema, and the description does not specify what 'detailed information' includes or whether the region code affects the result, 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions ('Region code' and 'Notebook instance number'), so the baseline is 3. The description adds no additional parameter semantics, such as the format of the instance number or the optionality of region.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'get' and identifies the resource as 'a specific Cloud Hadoop notebook', which clearly distinguishes it from listing or creating notebooks. However, it does not explicitly contrast itself with sibling tools like list_notebooks, though the 'specific' qualifier implies a single-resource lookup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: the tool is for retrieving details of a particular notebook, presumably when its instance number is known. There is no explicit guidance on when to use this versus other notebook-related tools, nor any exclusions or prerequisites.

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

• ncloud_hadoop_list_clustersA
  3.5/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already covers the safety profile of this read operation. The description adds only 'with optional filtering', which is a minimal behavioral trait already implied by the optional schema parameters. No additional context is provided about pagination defaults, response shape, or account/region scope, though the schema documents pageNo/pageSize defaults.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, front-loaded with the verb 'List'. Every word earns its place, with no redundancy or filler. It is appropriately sized for a straightforward list tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 10 optional parameters and no output schema, yet the description does not mention return value structure or pagination behavior beyond what the schema provides. It is minimally sufficient for a list operation, but gaps exist around default page size (1, which is unusual) and what cluster fields are returned. Given the tool's simplicity and high schema coverage, a score of 3 reflects adequacy with clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all 10 parameters documented in the schema. The description adds no parameter-specific meaning beyond the generic 'optional filtering' statement. Per the evaluation rule, a high-coverage schema sets a baseline of 3, which is appropriate here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'List Cloud Hadoop clusters'. The phrase 'with optional filtering' clarifies the tool's scope and distinguishes it from detail-oriented siblings like ncloud_hadoop_get_cluster_detail. The service name 'hadoop' in both tool name and description distinguishes it from other list_clusters tools (e.g., ncloud_nks_list_clusters).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool vs alternatives such as ncloud_hadoop_get_cluster_detail or ncloud_hadoop_list_cluster_types. There is no mention of prerequisites, pagination usage, or recommended filters. The description only states what it does, leaving the agent to infer usage from the name and schema.

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

• ncloud_hadoop_test_hive_metastoreA
  3.5/5.0
  Behavior3/5

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

  The annotation readOnlyHint: true already discloses that this is a safe read operation, and the description's 'Test connectivity' aligns with that. However, the description adds no extra behavioral context beyond the annotation—such as whether the test is synchronous, what success/failure looks like, or that it sends credentials to the target. With annotations present, the bar is lower, but the description adds minimal value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded with the verb 'Test' and clearly identifies the resource. No unnecessary words or repetition. It is appropriately sized for its purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a fairly simple purpose, and the schema and annotations cover parameter details and the read-only nature. However, there is no output schema and the description does not explain what the test result will look like (e.g., return values, error cases) or when a user would typically invoke this tool (e.g., before configuring a metastore). This is minimally adequate for a simple test tool but leaves some gaps in operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all six parameters have descriptions. The tool description adds the high-level context that this is for an external Hive metastore backed by Cloud DB for MySQL, but it does not provide any parameter-specific clarifications or explain how the parameters relate to the connectivity test. This matches the baseline of 3 where the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Test connectivity') and the specific resource ('external Hive metastore (Cloud DB for MySQL)'). This distinguishes it from sibling tools like ncloud_hadoop_save_hive_metastore, which is about saving configuration rather than testing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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. It does not mention prerequisites, exclusions, or that it might be a precursor to saving metastore settings. The context implied by the name is not expanded in the description.

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

• ncloud_interrupt_serverA
  3.5/5.0
  Behavior2/5

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

  Annotations are empty, so the description must carry the full burden of behavioral disclosure. It states that the tool 'interrupts' a server, which implies a disruptive action, but it does not explain what the interruption entails (e.g., forced shutdown, pause), whether it is reversible, or any side effects like data loss or service downtime. The vague term 'interrupt' could be misinterpreted without operational details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  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 purpose without any wasted words. It is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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 and no annotations, the description is functional but minimal. It omits operational details such as what 'interrupt' does differently from 'stop' or 'reboot', and what the expected outcome or response is. However, the simple structure means the description is not severely incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the only parameter, serverInstanceNo, as 'Server instance number to interrupt,' achieving 100% schema description coverage. The tool description itself adds no further parameter-level meaning, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'interrupt' with the resource 'server instance' and a clear purpose clause 'for diagnostics of abnormal behavior.' This distinguishes it from similar server lifecycle tools like stop, reboot, and terminate by indicating a diagnostic context, though it does not explicitly contrast with those alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for diagnostics of abnormal behavior' provides clear context for when to use this tool: when a server is behaving abnormally and needs interruption for investigation. It does not list alternative tools or exclusions, but the diagnostic intent is sufficient to guide selection among sibling server management tools.

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

• ncloud_kms_create_keyA
  3.5/5.0
  Behavior2/5

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

  Annotations only include destructiveHint=false, and the description adds no additional behavioral context such as permissions required, lifecycle side effects, key availability, or deletion behavior. Since this is a create operation, the agent has no information about what happens after creation beyond the schema's parameter hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is just two sentences, front-loaded with the primary action ('Create a new KMS key') and then lists supported types. Every word 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich schema covering all seven parameters, the description covers the core intent and key types. However, for a create tool with no output schema and no behavioral details, it is only minimally adequate; it could benefit from mentioning that key versions or rotation settings are handled via other tools, but it is not fatally incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% parameter coverage with descriptions for every field, including keyName constraints, keyType enum meanings, and optional parameters like isAutoRotation and rotationPeriod. The description adds no extra parameter guidance, but the schema already carries the burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Create' and identifies the resource 'KMS key', then lists supported key types (AES256, RSA2048, ECDSA). This clearly distinguishes the tool from sibling KMS operations like encrypt/decrypt/delete, which are present in the sibling list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by listing supported key types, signaling which scenarios this tool fits (e.g., creating symmetric AES256 or asymmetric RSA/ECDSA keys). However, it does not explicitly state when to choose this over alternatives like ncloud_kms_create_custom_key, nor does it mention any exclusions.

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

• ncloud_list_cache_config_groupsA
  3.5/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this as a safe read operation, so the bar is lower. The description adds the 'all' scope (no filtering), but does not disclose pagination behavior, response format, or whether results are paged by default. This is similar to the get_calls example but slightly less informative.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It conveys the action and resource efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list with two optional pagination parameters, the description is minimally viable. However, it lacks explicit mention of pagination or what the response contains, and with no output schema, the agent must infer return structure. The readOnly annotation helps, but the description does not go beyond the bare minimum.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both pageNo and pageSize have descriptions ('Page number for pagination' and 'Page size for pagination'). The description adds no extra parameter meaning, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all Cloud Cache config groups' clearly states a specific verb ('List') and resource ('Cloud Cache config groups'), and the word 'all' specifies scope. It distinguishes from sibling tools like ncloud_list_cache_instances and ncloud_list_cache_users by naming the exact resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 related tools (e.g., list cache instances, list cache backups) or specify conditions for use, leaving the agent to infer from the name alone.

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

• ncloud_list_ids_eventsA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description aligns with a read operation. It adds the subscription requirement, which is useful behavioral context beyond annotations, but does not disclose other behaviors like default pagination or error conditions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the primary action and scope, and contains no redundant or filler content. Every sentence adds information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description identifies the service scope and subscription prerequisite, while the schema documents parameters and defaults. However, there is no output schema and no mention of return format, pagination behavior, or how events are ordered, leaving some gaps for a listing tool with 10 parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all 10 parameters are already documented in the schema. The description adds no parameter-specific meaning beyond 'list events', but since schemas carry the full load, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists IDS intrusion detection events from Security Monitoring, using a specific verb and resource. It distinguishes from sibling event-list tools by specifying 'IDS' and 'Security Monitoring', though it does not explicitly name alternative tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear usage restriction ('Only for users subscribed to the Security Monitoring service'), indicating when not to use it. However, it does not mention alternatives or explicitly state when to use this tool over other event list tools.

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

• ncloud_list_mongodb_backupsA
  3.5/5.0
  Behavior2/5

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

  The readOnlyHint annotation already communicates that this is a safe read operation. The description adds no further behavioral information, such as whether both manual and automatic backups are listed, pagination behavior, or the structure of the returned data. It essentially restates the tool's static purpose without enriching the agent's understanding.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that conveys the core purpose without filler. It is well-structured and immediately understandable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with only one parameter and no output schema, the description is minimally viable but lacks detail on what the returned backup list contains or whether there are filtering options. It does not explain the distinction from the backup details tool, leaving some ambiguity for an agent needing to choose the right operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the single parameter (cloudMongoDbInstanceNo) with a clear description. The tool description adds no additional parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List), the resource (backups), and the scope (Cloud DB for MongoDB instance). It distinguishes itself from sibling tools like ncloud_list_mongodb_backup_details by focusing on backups generally rather than details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by naming the resource, but does not explicitly state when to use this tool over related siblings such as list_mongodb_backup_details or export_mongodb_backup. There is no mention of alternatives or exclusions, leaving the agent to infer the appropriate context.

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

• ncloud_list_mongodb_logsA
  3.5/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, and the description adds no behavioral context such as log types, filtering options, pagination, or response content. It merely restates the tool's action, so it provides minimal value beyond the structured annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that immediately states the action and resource. No extraneous words, and appropriately sized for this simple tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one fully-specified parameter, the description is minimally adequate for tool selection. However, it does not disclose what log data is returned, whether pagination applies, or how it differs from the export_mongodb_log tool, leaving gaps for an agent expecting complete context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter cloudMongoDbServerInstanceNo is fully described in the schema ('Cloud MongoDB server instance number'), and the description adds no additional semantics or usage details, consistent with the 100% schema coverage baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('server logs for a Cloud DB for MongoDB server instance'), clearly distinguishing this from sibling tools like ncloud_list_mongodb_instances or ncloud_list_mongodb_backups. The scope is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided about when to use this tool versus alternatives, such as ncloud_export_mongodb_log for exporting logs or ncloud_list_mysql_logs for MySQL. The intended use case is implied by the verb and resource, but exclusions/alternatives are absent.

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

• ncloud_list_mongodb_usersA
  3.5/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, and the description's 'List users' aligns with this safety profile without contradicting it. However, the description adds no behavioral context beyond what the annotation already conveys, such as return format, pagination, or filtering capabilities. With the annotation covering the read-only nature, a score of 3 reflects the minimal added value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence of nine words: 'List users in a Cloud DB for MongoDB instance'. Every word contributes meaning, with no redundancy or filler. It is appropriately concise for a simple list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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 well-documented parameter and no output schema, the description is minimally viable. It clearly states the action and resource. However, because no output schema exists, the description does not mention what fields the returned users contain (e.g., usernames, roles), which would enhance completeness. The readOnlyHint and schema cover safety and parameters, but the return payload remains unspecified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage: the only parameter, cloudMongoDbInstanceNo, is described as 'Cloud MongoDB instance number'. The tool description itself adds no additional meaning to this parameter. Baseline of 3 is appropriate as the schema fully documents the parameter, leaving the description with nothing extra to contribute.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List users in a Cloud DB for MongoDB instance' uses a specific verb ('List') and clearly identifies the resource (users within a MongoDB instance). It distinguishes from sibling tools like ncloud_add_mongodb_users, ncloud_change_mongodb_users, and ncloud_delete_mongodb_users by indicating a read-only listing operation, and from ncloud_list_mongodb_instances by focusing on users rather than instances.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 prerequisites, exclusions, or contrast with other list operations (e.g., list_mysql_users). The usage context is only implied by the tool name and description, not explicitly stated.

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

• ncloud_list_network_interfacesA
  3.5/5.0
  Behavior3/5

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

  The description states the scope ('current region'), which is useful context beyond the readOnlyHint annotation. It does not disclose behaviors like pagination (though pageNo/pageSize params hint at it), response format, or any limits on returned data. With readOnlyHint=true already indicating a safe read operation, the description adds minimal but non-zero value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that immediately states the action and scope. No wasted words. It is appropriately sized for a simple list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool is a simple list operation with readOnlyHint and a fully described schema (5 params, all optional), the description is mostly adequate. However, it could benefit from noting that no required parameters means it lists all interfaces by default, and that filters are available to narrow results. The return format is not described, but no output schema exists, so a bit more detail there would help.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add any parameter-level meaning beyond what the schema already provides. The schema itself explains filters (subnetNo, serverInstanceNo, networkInterfaceNoList) and pagination (pageNo, pageSize) sufficiently.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all network interfaces in the current region' uses a specific verb ('list') and resource ('network interfaces') with a scope qualifier ('current region'), making the purpose clear. It distinguishes from sibling tools like ncloud_get_network_interface_detail (which targets a single interface), though it doesn't explicitly mention that distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'in the current region' implies a regional scope, which provides some context for when to use this tool. However, there is no explicit guidance on when to use this vs alternative tools (e.g., get_network_interface_detail) or when not to use it. The presence of optional filters suggests use cases, but these are not spelled out in the description.

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

• ncloud_list_scaling_policiesA
  3.5/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this is a safe read operation, so the description does not need to repeat that. It adds the 'all' scope and ASG-specific targeting, but does not mention pagination behavior, return format, or potential empty results. This is adequate baseline transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no filler. Every word is essential and the description earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is minimal but adequate for a straightforward list operation. However, the claim of 'all' conflicts slightly with pagination parameters without explaining whether it auto-paginates, and the lack of an output schema means the return value is not described. It meets the minimum bar but does not exceed it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters (pageNo, pageSize, autoScalingGroupNo) are already documented. The description does not add any additional meaning beyond the schema, such as how pagination interacts with the claim of 'all'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('List'), the resource ('scaling policies'), and the scope ('for an Auto Scaling Group'), distinguishing it from other policy-listing tools like ncloud_gtm_list_policies or ncloud_list_policies. The singular required parameter autoScalingGroupNo reinforces the intended target.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given about when to use this tool over alternatives, such as ncloud_put_scaling_policy or ncloud_delete_scaling_policy. The context is implied by the name and description but lacks any stated exclusions or prerequisites.

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

• ncloud_list_subnetsA
  3.5/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes this as a safe read operation, lowering the burden on the description. The description adds 'all' and 'current region' as scope context, but there is no mention of pagination, response format, or default filter behavior, which would improve transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no unnecessary words. It efficiently states the action, resource, and scope in a compact form.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with readOnly annotation and fully described parameters, the description is adequate. However, the absence of an output schema and lack of details about pagination or response contents leave some gaps, and it doesn't point to related tools like ncloud_get_subnet_detail for detailed lookups.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage across all five optional parameters, so the description doesn't need to elaborate. It adds no parameter-specific meaning beyond what the schema already provides, matching the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and resource 'subnets' with a clear scope ('current region'). It distinguishes itself from singular ncloud_get_subnet_detail and service-specific subnet listers by being the general list tool, though it doesn't explicitly state it covers VPC subnets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'current region' provides clear context for when to use the tool, but there is no explicit guidance on alternatives or exclusions. It doesn't mention ncloud_get_subnet_detail for single-subnet lookups or service-specific subnet listers, leaving the choice somewhat implied.

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

• ncloud_nks_set_ip_aclA
  3.5/5.0
  Behavior2/5

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

  Annotations declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. However, the description does not disclose whether the provided entries replace the entire ACL list or are merged, nor any other behavioral side effects. This is a meaningful gap for a configuration setter.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that front-loads the action and resource. No wasted words, and the structure is clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With full schema coverage and annotations providing idempotence/safety info, the description is mostly adequate. The main missing piece is whether the ACL entries replace or append to existing rules, and there's no mention of expected output/return behavior, though the latter is less critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage: clusterUuid, entries, action, and address are all described. The description adds no parameter semantics beyond what the schema documents, but this is acceptable given full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Configure' with a clear resource ('IP ACL for an NKS cluster') and states the purpose ('restrict API server access'). This distinguishes it from siblings like ncloud_nks_get_ip_acl, which retrieves the configuration.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies this tool is used to set IP restrictions on a cluster's API server. It does not explicitly state when to use this over get_ip_acl or mention exclusions/alternatives, but the context is sufficient for common use cases.

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

• ncloud_pca_issue_end_certA
  3.5/5.0
  Behavior3/5

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

  With empty annotations, the description carries the burden. It discloses the outputs (private key, certificate, CA chain) but does not mention side effects, required permissions, security implications, or whether issuance is reversible. This is minimal but non-trivial.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with no filler, front-loading the core purpose and key outputs.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 12-parameter tool with no output schema, the description provides the core purpose and returns a brief list of outputs, but it omits return format, prerequisites, and error behavior. The schema compensates for parameters, so the description is moderately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with useful descriptions for all 12 parameters, including an enum for keyType. The description adds no parameter-specific meaning, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Issue') and the resource ('new end-entity certificate from a CA'), and the mention of returning private key, certificate, and CA chain distinguishes it from sibling tools like ncloud_pca_sign_end_csr or listing tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_pca_sign_end_csr or ncloud_issue_private_certificate. There are no contextual hints about prerequisites or exclusions.

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

• ncloud_pca_trim_caA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It states the core action (trimming expired certificates) but does not disclose whether this is destructive, irreversible, requires specific permissions, or what the response looks like. As a mutation 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that front-loads the action and purpose. It contains no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool, the description covers the action and intent, but it lacks context about the effects of the operation, whether it modifies the CRL permanently, and how it relates to the specified CA. It is minimally viable but has clear gaps for a mutation tool with no annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with the caTag parameter described as 'CA tag value'. The description does not add any parameter-specific context beyond the schema. Baseline 3 is appropriate since the schema fully documents the only parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Trim') and resource ('CRL' - Certificate Revocation List), and clarifies the purpose of cleaning up the revocation list. This clearly distinguishes it from sibling tools like get_ca_crl (fetch) or rotate_crl (likely regenerating the CRL).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating the goal ('clean up the revocation list'), but it does not explicitly state when to use this tool versus alternatives like rotate_crl or update_crl_config. There are no exclusions or alternative tool names mentioned.

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

• ncloud_pca_update_caA
  3.5/5.0
  Behavior1/5

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

  The description warns that setting DESTROYING will permanently delete the CA after 72 hours and is irreversible, which is useful behavioral context. However, this directly contradicts the annotation destructiveHint: false. The description clearly signals a destructive action while the annotation denies it, creating a serious inconsistency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences, warning first, then explaining the destructive behavior and irreversibility. Every sentence contributes essential information with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with only two fully documented parameters and no output schema, so the description covers the most critical aspect (DESTROYING consequences). However, the annotation contradiction undermines completeness by giving an agent contradictory safety signals, and the effects of DEACTIVATED status are not described.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes both parameters with 100% coverage. The description adds extra meaning for the status parameter by explaining the consequence of DESTROYING, which goes beyond the schema's enum listing. No additional info is provided for caTag, but the schema fully documents it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Update'), resource ('CA status'), and the valid statuses (ACTIVE, DEACTIVATED, DESTROYING). It is specific enough to distinguish from sibling tools like ncloud_pca_delete_ca.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (to change a CA's status) and warns about DESTROYING, but it does not explicitly contrast with alternatives (e.g., ncloud_pca_delete_ca) or state when NOT to use it. The guidance is helpful but not fully explicit.

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

• ncloud_put_bucket_aclA
  3.5/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries the full burden of behavioral disclosure. It states it 'sets' an ACL but does not mention whether this overwrites existing ACLs, requires specific permissions, is reversible, or what happens if the bucket does not exist. No side effects or prerequisites are disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the verb and resource. No redundant or filler information is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple two-parameter tool with complete schema and a clear description. However, the lack of behavioral context (permissions, side effects, return behavior) and absence of an output schema mean the agent is not fully informed about consequences, making it adequate but with gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both bucketName and acl fully described. The description adds minor clarification (canned ACL, Object Storage bucket) but does not provide meaningful semantics beyond what the schema already offers. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Set' with a clear resource 'access control list of an Object Storage bucket' and method 'using a canned ACL'. This clearly distinguishes it from sibling tools like get_bucket_acl and put_object_acl.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives. Usage is implied by the resource type (bucket ACL), but there is no mention of get_bucket_acl for reading or put_object_acl for object-level ACLs. Provides minimal guidance beyond the action itself.

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

• ncloud_put_bucket_versioningA
  3.5/5.0
  Behavior2/5

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

  Annotations are empty, so the description carries full burden for behavioral disclosure. It only states the action 'Set' without mentioning side effects, necessary permissions, reversibility, or consequences of changing versioning. As a mutation 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the verb 'Set' and directly states the resource and allowed values. There is no unnecessary information or padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with only two parameters and no output schema, so the description is minimally viable. However, as a mutation tool without annotations, it lacks behavioral context, usage guidance, and any mention of prerequisites or return behavior, leaving gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (both parameters have descriptions), so the baseline is 3. The description adds minimal value beyond restating the status enum and the bucket name, which the schema already documents. No additional parameter semantics are provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action 'Set' and the specific resource 'versioning state of an Object Storage bucket', with the allowed values '(Enabled or Suspended)' explicitly listed. This distinguishes it from sibling tools like ncloud_get_bucket_versioning, which reads the state, and other bucket operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for changing versioning state, but it does not explicitly state when to use it, prerequisites, or alternatives. It offers no exclusions or when-not-to-use guidance, so the agent must infer usage from the verb and resource.

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

• ncloud_resource_list_resourcesA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that NRN returns a single resource detail with tags and groups, which is useful behavioral context. However, it does not disclose pagination, filtering semantics, or response structure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, concise and front-loaded with the primary action. There is no wasted wording, and the NRN conditional is integrated efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate for a simple list tool with a detailed schema, but lacks output format, pagination information, or how filters combine. The NRN case is covered, but the general list behavior is under-specified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 10 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds only the NRN behavior with tags/groups, which is a minor addition beyond the schema. No significant semantic enrichment for other parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists resources managed in Ncloud, using a specific verb and resource. It also explains the NRN special case, but does not explicitly differentiate from other specific list tools such as ncloud_list_servers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides conditional usage guidance for when NRN is specified, but offers no alternatives or when-not-to-use guidance. It implies general resource listing but does not mention when to prefer this over sibling list tools.

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

• ncloud_ses_get_node_listA
  3.5/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes this as a safe read operation, and the description aligns with that. However, the description adds no further behavioral context such as whether the list includes all node statuses, pagination behavior, or what node attributes are returned.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no filler or redundant information. It clearly states the tool's action and target resource in minimal space.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has low complexity (one parameter, no output schema) and the read-only annotation covers the safety profile. However, the description does not indicate what the response includes or whether any filtering/pagination exists, which would be helpful for an agent planning to use the result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter, which is described as 'Cluster instance number.' The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('node list for a Search Engine Service cluster'), clearly indicating what the tool returns. It is distinct from sibling tools like get_cluster_detail or get_node_spec_detail, though it doesn't explicitly call out those differences.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context implies usage: when you need the node list for a specific SES cluster. However, there is no explicit guidance on when to use this instead of related tools (e.g., get_cluster_detail) or prerequisites like obtaining the serviceGroupInstanceNo.

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

• ncloud_ses_get_upgrade_progressA
  3.5/5.0
  Behavior2/5

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

  The description aligns with the readOnlyHint annotation (a 'Get' operation) and adds no additional behavioral context. It does not disclose return format, progress metrics, or any side effects. With annotations already covering the safety profile, the description adds minimal value beyond the obvious read nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the verb and resource. Every word earns its place, with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only getter with a fully documented schema and a readOnlyHint, the description is adequate. However, without an output schema, it does not explain what the response contains (e.g., progress percentage, status fields), leaving some ambiguity for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter, with the schema describing it as 'Cluster instance number'. The description adds no further parameter semantics, and the baseline of 3 applies when the schema fully covers parameter meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and identifies a clear resource ('version upgrade progress for a Search Engine Service cluster'). It distinguishes itself from sibling tools like ncloud_ses_upgrade_version and ncloud_ses_precheck_upgrade by focusing on retrieving progress rather than initiating or checking preconditions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context (monitoring progress after an upgrade) but provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. The naming and sibling set suggest a natural workflow, but that is inferred rather than stated.

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

• ncloud_ses_set_snapshot_api_keyA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false, so the safety profile is known. The description adds context that this key is for Object Storage access specifically for snapshots, but does not disclose whether the key replacement is immediate, whether existing snapshots are affected, or any other operational side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, well-structured sentence with no filler. It is front-loaded with the action and resource, and the parenthetical clarifies the frame without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the full schema coverage and the presence of annotations, the description is minimally viable. However, it does not explain the relationship to other snapshot operations (e.g., that this key may be required before creating or exporting snapshots), nor does it mention any prerequisites or side effects. For a simple configuration tool this is acceptable but not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds minimal context beyond what the schema provides: it clarifies that the access keys are for Object Storage access in the context of snapshots, but does not elaborate on how the keys are used or the role of the cluster instance number.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Set'), the resource ('API authentication key'), and the context ('for Object Storage access (for snapshots)'). This distinguishes it from sibling tools that manage snapshots or schedules, such as ncloud_ses_set_snapshot_schedule.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, prerequisites, or alternatives. It does not mention whether this should be called before snapshot creation or how it relates to other snapshot-related operations.

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

• ncloud_ses_set_snapshot_scheduleA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context (e.g., whether an existing schedule is overwritten, any required cluster state). It does not contradict 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the main action and object. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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 full schema descriptions, the description is adequate but lacks context about usage, prerequisites, or the expected effect of setting a schedule. It is not fully complete for a configuration-setting operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already described in the input schema. The description itself adds no parameter-specific details, but given the high schema coverage, the parameters are sufficiently documented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Set') and the resource ('snapshot scheduling' for a Search Engine Service cluster). It is specific and distinguishes from related tools like ncloud_ses_unset_snapshot_schedule and ncloud_ses_create_snapshot.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as ncloud_ses_unset_snapshot_schedule or ncloud_ses_get_snapshot_history. It does not mention prerequisites or situations where this tool should or shouldn't be used.

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

• ncloud_set_deny_allow_group_ipsA
  3.5/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds no extra behavioral context. It does not disclose that setting the IP list likely overwrites the entire list, which is a critical operational detail for a 'set' operation. The absence of this information makes the behavior ambiguous.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, focused sentence that communicates the core purpose with no redundancy or unnecessary detail. It is well-structured and immediately front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (two params, no output schema) and the schema covers parameter descriptions. However, the description fails to mention that the IP list is likely replaced in full, and it lacks guidance on when to use this tool relative to other deny-allow group operations. This leaves some gaps for an agent needing to understand the full effect and context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive parameter texts for both networkAclDenyAllowGroupNo and ipList. The description adds no additional parameter-level meaning, so it relies on the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Set') and the resource ('IP list for a Network ACL Deny-Allow Group'), distinguishing it from sibling tools like ncloud_set_deny_allow_group_desc or CRUD operations on deny-allow groups. This is a specific and unambiguous purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when one needs to set a deny-allow group's IP list, but it does not explicitly say when to use it over alternatives or mention that it replaces the existing list. There is no guidance on context or exclusions, leaving the agent to infer.

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

• ncloud_sourcedeploy_create_stageA
  3.5/5.0
  Behavior2/5

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

  Annotations only include destructiveHint:false, and the description adds no further behavioral context. It does not mention requirements like project existence, validation behavior, potential errors, or side effects beyond the act of creation. With annotations present, the bar is lower, but the description provides zero extra transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is direct and front-loaded. It contains no filler or redundant information, earning a perfect score for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the schema thoroughly documents parameters, the description lacks any context about the purpose of a deployment stage, prerequisites (e.g., project existence), or expected behavior/response. There is no output schema, so the description does not compensate for this gap. It is minimally viable but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so every parameter is already described. The tool description itself adds no additional parameter meaning. Baseline is 3, and there is no reason to score higher or lower.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create') and identifies a clear resource ('a new deployment stage in a SourceDeploy project'). This clearly distinguishes it from sibling tools like edit_stage, delete_stage, list_stages, and get_stage.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for creating a new stage, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or conditions. The verb 'create' gives context, but no explicit guidance is given.

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

• ncloud_sourcedeploy_get_objectstorage_bucketsA
  3.5/5.0
  Behavior3/5

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

  The annotation readOnlyHint: true already signals that this is a safe read operation, and the description's 'Get the list' is consistent with that. Beyond the annotation, the description adds minimal behavioral context, merely restating the retrieval purpose with a stage-configuration qualifier. No additional behavioral traits (pagination, sorting, permissions, or response details) are disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that immediately states the action and resource. Every word contributes meaningful context, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, no output schema, read-only annotation), the description adequately conveys the purpose and scope. It tells the agent what will be returned ('list of available Object Storage buckets') and the context ('SourceDeploy stage configuration'), which is sufficient for a parameterless listing tool. However, it does not describe the format or contents of the returned bucket list, which would be useful but not essential here.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool takes zero parameters, and the input schema confirms this with an empty properties object. With no parameters to explain, the description does not need to provide parameter semantics; the baseline of 4 for zero-parameter tools is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  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 clear resource ('list of available Object Storage buckets') with a scoping qualifier ('for SourceDeploy stage configuration'). This distinguishes it from general bucket listing tools like ncloud_list_buckets and from object-level tools like ncloud_sourcedeploy_get_objectstorage_objects, though it does not explicitly name these siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for SourceDeploy stage configuration' implies a use case, but the description offers no explicit guidance on when to choose this tool over alternatives (e.g., ncloud_list_buckets or ncloud_sourcedeploy_get_objectstorage_objects). It also does not mention exclusions or preconditions.

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

• ncloud_suspend_processesA
  3.5/5.0
  Behavior2/5

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

  The description does not add behavioral detail beyond the idempotentHint and destructiveHint annotations. It does not explain that suspension only affects future scaling activities, whether it is reversible, or that it does not modify existing instances. This leaves important context unstated for a state-changing operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence, front-loaded with the action and object. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate for a simple 2-parameter tool, but it omits how to discover valid scaling process codes (suggested by sibling ncloud_get_scaling_process_types) and the operational impact of suspension. Annotations and schema cover safety and parameters, but the description lacks these contextual pointers.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema documentation covers both parameters (autoScalingGroupNo and scalingProcessCodeList) with clear descriptions, so the baseline is met. The tool description adds no additional parameter semantics, such as allowed process codes or the relationship to ncloud_get_scaling_process_types.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Suspend') and resource ('scaling processes') and clearly identifies the target ('Auto Scaling Group'). It distinguishes from sibling tools like ncloud_resume_processes and other ASG operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used to suspend processes on an ASG but provides no explicit guidance on when to use it versus alternatives such as ncloud_resume_processes or setting desired capacity. There are no exclusions or prerequisites mentioned.

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

• ncloud_unassign_secondary_ipsA
  3.5/5.0
  Behavior2/5

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

  With empty annotations, the description carries the full burden of behavioral disclosure, but it only restates the action with a synonym. It does not mention whether IPs must be currently assigned, whether the operation is destructive/reversible, or what happens to the released IPs (e.g., return to pool). This is a significant transparency gap for a mutating operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It conveys the essential action efficiently, making it easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple operation with two fully-described parameters and no output schema, the description is minimally viable. It clearly states the core action, but lacks context about behavioral outcomes, prerequisites, or error conditions, which would be helpful for an agent deciding to invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides clear descriptions for both parameters (secondaryIpList and networkInterfaceNo), giving 100% coverage. The description adds no additional parameter semantics, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'unassign' with a clarifying synonym 'release' and clearly names the resource ('secondary IPs') and target ('network interface'). This unambiguously distinguishes it from the sibling tool ncloud_assign_secondary_ips.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating the action, but it does not explicitly explain when to use this tool versus alternatives, nor does it mention exclusions, prerequisites, or consequences. The need is inferred from the tool name and the presence of a corresponding assign tool.

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

• ncloud_update_product_schemaA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds minimal context by specifying 'user-defined custom schema' and 'Cloud Insight,' but does not disclose whether the update replaces the entire schema definition, merges with existing fields, or has any side effects. With annotations present, the bar is lower, but the description still lacks behavioral nuance beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It directly communicates the purpose without extraneous content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With complete schema documentation and annotations present, the description is adequate for a simple update tool. However, it does not clarify whether the 'fields' parameter represents a full replacement of the schema's field definitions or a partial update, which is a meaningful gap. No output schema exists, but that is consistent with many update operations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides full descriptions for all three parameters (prodName, cw_key, fields) including nested field objects, achieving 100% schema coverage. The description itself adds no additional parameter information, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb "Update" and the resource "user-defined custom schema in Cloud Insight," which precisely identifies the tool's action and scope. It distinguishes itself from related tools like ncloud_create_custom_schema, ncloud_delete_product_schema, and ncloud_get_product_schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as creating, deleting, or getting a schema. It does not mention any prerequisites, exclusions, or conditions under which updating is appropriate.

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

• ncloud_add_targetA
  3.6/5.0
  Behavior3/5

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

  Annotations provide destructiveHint=false, so the safety profile is covered. The description adds minor context by clarifying targets are server instances but does not disclose other behavioral traits like idempotency, failure conditions, or whether existing targets are affected.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that communicates the essential purpose with no redundant wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple mutation with two fully described parameters, no output schema, and annotations covering destructive behavior, the description is sufficient for basic use. It lacks mention of prerequisites (target group existence) or duplicate handling, but these are not critical given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters described (targetNoList and targetGroupNo). The description merely restates these concepts ('targets', 'target group') without adding format, relationships, or constraints beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Add) and the resource (target group), specifying that targets are server instances. This distinguishes it from siblings like ncloud_remove_target (removes) and ncloud_set_targets (likely replaces all targets).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives such as ncloud_set_targets or ncloud_remove_target. The context is implied but not stated, leaving the agent to infer when additive behavior is appropriate.

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

• ncloud_associate_public_ipA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds no behavioral details beyond the action itself, but it does not contradict the annotations. No extra context like side effects or preconditions is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, direct 9-word sentence that starts with the action verb and states the object. No wasted words, perfectly concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter action with full schema coverage and helpful annotations, the description is mostly adequate. It lacks usage guidance and behavioral context, but the tool's complexity is low, so the overall information is sufficient for basic invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%; both 'publicIpInstanceNo' and 'serverInstanceNo' have clear descriptions in the schema. The tool description adds no additional parameter semantics beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Associate' with clear resources: 'a public IP with a server instance.' It unambiguously distinguishes this tool from siblings like 'ncloud_disassociate_public_ip', 'ncloud_create_public_ip', and 'ncloud_delete_public_ip'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. It does not mention prerequisites, such as requiring an unassociated public IP or the server being in a valid state, nor does it suggest when to prefer the disassociate or create operations.

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

• ncloud_cdnplus_get_purge_historyA
  3.6/5.0
  Behavior2/5

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

  Annotations declare readOnlyHint=true, so the safe-read nature is known. However, the description adds no behavioral context beyond that—nothing about response format, pagination, default behavior when no purge IDs are given, or ordering. It essentially restates the schema, so minimal value added.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the action ('Get') and object, and includes the optional filter concisely. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only operation with two parameters and clear schema, the description is mostly complete. It states the main purpose and optional filtering, which is sufficient for an agent to invoke the tool. The lack of pagination or return-format details is a minor gap, but acceptable for a straightforward list/history endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters ('purgeIdList' and 'cdnInstanceNo') described in the schema. The description's phrase 'optionally filtered by purge IDs' adds no new meaning beyond the schema. Baseline 3 is appropriate since the schema handles the semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get', the resource 'CDN+ purge request history', and the scope 'for an instance', with an optional filter by purge IDs. It distinguishes from sibling tools like ncloud_globalcdn_get_purge_history and ncloud_cdnplus_request_purge by specifying 'CDN+' and 'purge request history'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need purge history for a specific CDN+ instance, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The context is clear enough for an agent to infer, but explicit guidance is missing.

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

• ncloud_cdss_enable_public_domainA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the risk profile. The description adds no extra behavioral context beyond the action itself, such as security implications of exposing CMAK publicly or reversibility. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It conveys the essential purpose efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter operation with annotations present and no output schema, the description is sufficient. It clearly states the action and required resource, though it omits usage guidance or side effects, which are not critical for this simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% covered for the single parameter serviceGroupInstanceNo with description 'Cluster instance number'. The description adds no further semantic detail, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Enable') and resource ('public domain for CMAK management tool access'), clearly distinguishing it from the sibling tool ncloud_cdss_disable_public_domain. It is unambiguous and precisely describes the tool's action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 (e.g., ncloud_cdss_disable_public_domain or enable_public_endpoint). It lacks any context about prerequisites, scenarios, or exclusions.

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

• ncloud_cdss_get_broker_infoA
  3.6/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, and the description's 'Get' verb is consistent. The description adds specifics about the returned data (endpoints, ports) but does not disclose additional behaviors such as list format, error conditions, or permissions. It adds modest value 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, information-dense sentence with no redundancy or filler. It is perfectly concise and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With one parameter, no output schema, and a clear purpose, the description sufficiently conveys what the tool returns. It mentions endpoints and ports, which covers the core output. Minor gaps: it does not specify whether the return is a list or object, or any prerequisites. Still, it is complete enough for this simple read-only tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter serviceGroupInstanceNo, which already has a description ('Cluster instance number'). The tool description adds no further meaning or context for this parameter, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('broker node communication info (endpoints, ports) for a CDSS cluster'), clearly distinguishing it from other CDSS tools like get_cluster_detail or get_monitoring. It precisely states what is retrieved.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description only states the action without contextual cues, exclusions, or references to sibling tools.

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

• ncloud_cdss_restart_kafkaA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false. The description adds minimal context by naming Kafka and ZooKeeper, but does not disclose operational details like network impact, downtime, or whether the restart is rolling vs. full. This is acceptable given the annotations, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no redundancy. It front-loads the action and resource, communicating the essential behavior efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple restart operation with one parameter and no output schema, the description provides the core purpose clearly. It could have added that this restarts all nodes in the cluster (distinguishing from per_node), but the description is adequate for the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single parameter serviceGroupInstanceNo has a clear description ('Cluster instance number'). The tool description does not add any additional meaning to the parameter, matching the baseline expectation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Restart') and the resource ('Kafka and ZooKeeper services in a CDSS cluster'). It distinguishes from sibling tools like restart_kafka_per_node and restart_all_services by specifying the exact services involved.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_cdss_restart_kafka_per_node or ncloud_cdss_rolling_restart. The description lacks any 'when to use' or 'instead of' context.

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

• ncloud_change_cache_usersA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds no further behavioral context, such as side effects on existing connections or partial failure behavior when changing multiple passwords. It does not contradict the annotations, so a baseline score is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence with no unnecessary words. It states the action and resource efficiently, making it easy for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutating tool with comprehensive schema coverage and clear annotations, the description provides enough context to select and invoke the tool correctly. It does not explain return values or sync/async behavior, but the schema and annotations compensate, leaving only minor gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with parameters like cloudCacheUserList and cloudCacheInstanceNo fully described. The description adds no extra semantic detail beyond confirming that passwords are being changed, which aligns with the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Change'), the resource ('DB user passwords'), and the target ('Cloud DB for Cache (Redis/Valkey) instance'). This distinguishes it from sibling tools like add_cache_users, delete_cache_users, and list_cache_users, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as adding or deleting cache users. The description explains the operation but does not mention scenarios (e.g., password rotation) or exclusions (e.g., cannot create new users). This leaves the agent without context for tool selection.

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

• ncloud_change_fabric_cluster_nameA
  3.6/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, and the description does not contradict them. However, the description adds no extra behavioral context such as uniqueness constraints, propagation delays, or cluster state requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, short sentence: 'Change a fabric cluster's name.' It is front-loaded and contains no unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple rename operation, the description covers the purpose, the schema covers parameters, and annotations cover safety. It is adequate, though it could mention any side effects or preconditions for a more complete picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters fully described (e.g., character limits). The description adds no further parameter semantics, relying entirely on the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Change') and clearly identifies the resource ('a fabric cluster's name'). It distinguishes from sibling tools like ncloud_change_fabric_cluster_description or ncloud_change_fabric_cluster_servers by explicitly targeting the name field.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for renaming a fabric cluster, but it does not explicitly state when to use this tool versus alternatives. No exclusions or conditions (e.g., cluster state requirements) are provided.

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

• ncloud_change_lb_listener_configA
  3.6/5.0
  Behavior2/5

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

  The description merely restates the tool's scope (protocol, port, SSL, TLS) without disclosing behavioral traits beyond annotations. Annotations already declare idempotentHint=true and destructiveHint=false; the description adds no further context about impacts, prerequisites, or side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One short sentence that front-loads the action and resource. No filler or redundant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given strong schema descriptions and annotations (idempotent, non-destructive), the description is adequate for a simple configuration change. No output schema exists, so return-value documentation isn't needed; conditional requirements are already captured in parameter descriptions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with descriptions, so baseline is 3. The description's mention of protocol/port/SSL/TLS merely echoes schema fields and adds no semantic value beyond what's already documented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool changes load balancer listener configuration, listing specific fields (protocol, port, SSL, TLS settings). This distinguishes it from sibling tools like ncloud_change_lb_config and ncloud_change_target_group_config, which target different resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternative guidance is provided. The name and description imply it's for modifying an existing listener, but it doesn't mention cases where create_lb_listener or change_lb_config would be more appropriate.

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

• ncloud_change_mongodb_mongos_countA
  3.6/5.0
  Behavior3/5

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

  Annotations (idempotentHint=true, destructiveHint=false) already establish the safety profile. The description adds the specific resource being changed but no additional behavioral context such as downtime, rolling nature, or constraints beyond the schema. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that fully communicates the tool's purpose. There is no redundant or filler content; every word is informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter operation with complete schema descriptions and robust annotations, the description is sufficient. It could mention the range (2-5) for mongosServerCount, but that is already captured in the schema, so no critical information is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters clearly documented in the input schema. The description adds no extra parameter-level meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Change') and resource ('number of Mongos servers in a MongoDB Sharded Cluster instance'). It clearly distinguishes from sibling tools that change other counts (secondary, config, shard) by naming the exact component being modified.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided on when to use this tool versus alternatives like change_mongodb_secondary_count or change_mongodb_shard_count. The intended use is only implied by the tool name and description, with no when-not or alternative suggestions.

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

• ncloud_change_mongodb_shard_countA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is known. The description adds minimal behavioral context beyond specifying the target resource (Sharded Cluster), but discloses no operational details such as whether the change is asynchronous, requires downtime, or has side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that immediately states the action and target, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity operation with fully documented parameters and safety annotations, the description is largely sufficient. It clearly states the resource type, but omits any mention of result behavior or preconditions, which would push it to a 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (both parameters have descriptions), so the schema already explains the parameters. The tool description does not add any additional meaning or format details for the parameters, keeping it at the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Change' and clearly identifies the resource ('number of shards in a MongoDB Sharded Cluster instance'), which distinguishes it from sibling tools that change other MongoDB counts (e.g., ncloud_change_mongodb_secondary_count, ncloud_change_mongodb_mongos_count).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, nor does it mention prerequisites or conditions. It only states what the tool does, leaving usage context unstated.

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

• ncloud_change_mysql_usersA
  3.6/5.0
  Behavior3/5

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

  Annotations declare idempotentHint=true and destructiveHint=false, matching the non-destructive modify behavior described. The description adds no extra behavioral context beyond the annotations, such as side effects or permission requirements, but does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the purpose. There is no redundant or filler information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although the description is brief, it is sufficient given the rich schema and annotations. The schema covers all parameter details, and annotations clarify idempotency and non-destructive behavior. No output schema exists, so return values need not be explained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with detailed descriptions for all parameters including password rules, authority enum meanings, and hostIp formats. The tool description itself adds little beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Change') and the resource ('DB user information ... for a Cloud DB for MySQL instance'). It names the specific fields (authority, password, hostIp) and distinguishes itself from sibling tools like add/delete/list MySQL users.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as ncloud_add_mysql_users or ncloud_delete_mysql_users. It does not mention prerequisites or scenarios where this tool is preferred.

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

• ncloud_complete_multipart_uploadA
  3.6/5.0
  Behavior2/5

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

  With empty annotations, the description carries full burden. It states the completion action but fails to disclose that this is a final, irreversible mutation, that it requires all parts to be successfully uploaded, or any error/return behavior. This is a significant gap for a state-changing operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence with 11 words, immediately clear and front-loaded. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 4 required parameters and no output schema, yet the description provides no information about the return value, prerequisites, or workflow relationship to sibling multipart tools. It lacks the behavioral context needed for an agent to understand the full completion step.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the description need not add parameter details. The mention of 'assembling previously uploaded parts' loosely relates to the 'parts' parameter but adds no extra semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Complete' and the resource 'multipart upload', clearly distinguishing it from related part operations like upload_part or abort_multipart_upload.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'previously uploaded parts' contextually indicates this is the final step after parts are uploaded, providing clear usage context. However, it does not explicitly mention alternatives or when not to use it, so it doesn't earn a 5.

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

• ncloud_create_load_balancerA
  3.6/5.0
  Behavior3/5

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

  The annotation only declares destructiveHint=false, which is consistent with a create operation. The description adds the dryRun preview capability, which is useful, but it does not disclose other behavioral traits such as whether the operation is synchronous, idempotent, or requires specific prerequisites.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description consists of two concise sentences that immediately communicate the purpose and a key usage tip. There is no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 10 parameters and no output schema, the description is adequate given the rich schema. It covers the essential purpose and a preview behavior, but could benefit from mentioning what the response will contain or that the operation is asynchronous.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage with detailed descriptions for all parameters, including constraints like 'Cannot be set for NETWORK type' for idleTimeout. The description adds no parameter-specific information beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Create a new load balancer instance.' This clearly differentiates from sibling tools like ncloud_list_load_balancers, ncloud_get_load_balancer_detail, and ncloud_delete_load_balancers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 only mentions using dryRun=true to preview, which is a usage tip but does not address tool selection or exclusions.

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

• ncloud_create_mongodb_instanceA
  3.6/5.0
  Behavior3/5

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

  Annotations only include destructiveHint:false, so the description carries the burden of behavioral disclosure. It adds the dryRun preview behavior, which is helpful. However, it doesn't disclose that creating an instance incurs costs, may be a long-running operation, or requires specific permissions. These are significant behavioral traits for a creation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exactly two short sentences, front-loaded with the action 'Create a new Cloud DB for MongoDB instance' and followed by a concise dryRun tip. There is zero wasted wording, and the structure is immediately scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a high-complexity tool with 25 parameters, 7 required, and no output schema. The description is only two sentences and doesn't explain how parameters interact (e.g., clusterTypeCode determines which product codes and shard counts are needed). It also doesn't mention what a successful creation returns or any prerequisites like VPC/subnet setup. The schema descriptions help, but the description itself is insufficient for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with descriptions for all 25 parameters, so the baseline is 3. The description's mention of dryRun adds no new semantic value since the schema already documents dryRun with a default of false. No additional parameter relationships or conditional logic are explained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Create' and identifies the resource as 'Cloud DB for MongoDB instance,' clearly distinguishing it from sibling tools like list_mongodb_instances, delete_mongodb_instance, and get_mongodb_instance_detail. The dryRun option is also surfaced, reinforcing the creation intent.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a useful usage hint for dryRun=true as a preview mode without creating. However, it doesn't explicitly state when to use this tool versus alternatives for managing existing instances or performing other MongoDB operations. Usage is implied by 'Create' but lacks explicit exclusions or alternative references.

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

• ncloud_create_mysql_instanceA
  3.6/5.0
  Behavior3/5

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

  Annotations only provide destructiveHint=false. The description adds the dryRun capability which is not in annotations, giving a preview without creation. However, it does not disclose asynchronous behavior, expected response, or any side effects beyond the creation itself.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences that are front-loaded with the action and resource. No unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the comprehensive schema, the description lacks context about the operation's outcome, such as return values, eventual consistency, or how to monitor creation progress. With no output schema, this leaves a gap for a tool with 26 parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameters with descriptions, including dryRun. The description repeats the dryRun behavior without adding new meaning beyond the schema, so it scores at the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (create) and the resource (Cloud DB for MySQL instance), distinguishing it from other database creation tools by naming MySQL specifically. The verb+resource pattern 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool over alternatives such as ncloud_create_postgresql_instance or ncloud_create_mysql_slave. It only implies usage through the tool name and the dryRun preview tip, which is more of a behavioral hint than usage guidance.

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

• ncloud_delete_postgresql_read_replicaA
  3.6/5.0
  Behavior3/5

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

  Annotations already mark destructiveHint=true and idempotentHint=true. The description adds the confirm=true requirement, but this is also documented in the schema parameter description, so it adds minimal new behavioral context 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence with a warning prefix; highly efficient and front-loaded. Every word adds value, and the structure is immediately clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with complete schema and annotations, the description covers the essential action and safety gate. It doesn't mention irreversibility or prerequisites, but annotations mitigate this and no output schema is expected.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema (100% coverage). The description does not add any parameter semantics beyond stating the confirm requirement, which is already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Delete') and resource ('Cloud DB for PostgreSQL Read Replica instance'), clearly distinguishing it from deleting the primary PostgreSQL instance or other resources. It is concise and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives such as ncloud_delete_postgresql_instance or ncloud_create_postgresql_read_replica. The context is implied but no alternatives or exclusions are mentioned.

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

• ncloud_drm_create_policyA
  3.6/5.0
  Behavior2/5

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

  Annotations only declare destructiveHint=false. The description adds minimal behavioral context beyond the creation action itself. It does not disclose prerequisites (e.g., needing an existing site), side effects, permissions required, or return value behavior. With sparse annotations, the description carries a heavier burden that it fails to meet.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the essential action and resource. Every word earns its place, with no unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite a complex schema with nested objects and no output schema, the description offers only a high-level summary. It does not mention the hierarchical structure (drmPolicyConfig containing per-DRM settings), any prerequisites like site creation, or expected results. The schema does a lot of heavy lifting, but the description leaves key contextual gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters and nested properties are already well documented. The description's mention of 'security settings' adds no additional meaning beyond what the schema already provides, keeping this at the baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create') and the resource ('a new DRM policy'), and specifies the three DRM security systems (Widevine / PlayReady / FairPlay). This distinguishes it from sibling tools like ncloud_drm_update_policy or ncloud_drm_delete_policy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates this is for creating a new policy (as opposed to updating/deleting existing ones), providing a clear usage context. However, it does not explicitly mention alternatives or when not to use it, which prevents a 5.

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

• ncloud_functions_list_triggersA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals a safe read operation. The description adds no further behavioral detail (e.g., pagination, filtering, or response structure), but it is consistent with the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no filler or redundancy. It is optimally concise and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one optional parameter, no output schema) and the read-only annotation, the description is mostly sufficient. It could optionally describe what fields are returned, but the core purpose is clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, 'platform', is fully described in the schema with an enum and default value. The tool description does not add extra meaning, but with 100% schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' with the resource 'Cloud Functions triggers', clearly distinguishing this from sibling tools like ncloud_functions_get_trigger or ncloud_functions_list_packages. It unambiguously states what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives. It does not mention preferred scenarios, exclusions, or relationships to sibling tools, so the agent is left without context for tool selection.

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

• ncloud_get_asg_detailA
  3.6/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true covers the safety profile, so the read-only nature is clear. However, the description adds no extra behavioral context (e.g., response format, error behavior, or rate limits). It does not contradict the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence of nine words. It is concise, scannable, and contains no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter and a read-only annotation. The description adequately conveys its purpose and scope, though it does not enumerate return fields, which would be helpful given no output schema is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description for autoScalingGroupNo is explicit and covers 100% of parameters. The description adds no additional meaning 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Get') and a clear resource ('detailed information about a specific Auto Scaling Group'). The word 'specific' distinguishes it from list-type siblings like ncloud_list_asgs, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as ncloud_list_asgs or ncloud_get_launch_config_detail. It does not state prerequisites, exclusions, or the relationship to other ASG tools.

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

• ncloud_get_cache_target_vpcsA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates a safe read operation, and the description adds context that these VPCs are specifically 'available for Cloud DB for Cache'. However, it does not disclose additional behavioral details such as whether results are scoped by region or response limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence with no unnecessary words. It is front-loaded with the verb and resource, making it immediately clear what the tool does.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with an optional parameter and no output schema, the description is largely sufficient. It lacks details on the response structure, but the function name and schema make the intent clear. A slightly richer description of the returned VPC information would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single optional parameter (regionCode) with a clear description of valid values. The tool description adds no further parameter semantics, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List VPCs available for Cloud DB for Cache' clearly states the action (list) and resource (VPCs for Cloud DB for Cache), distinguishing it from sibling tools like ncloud_get_cache_target_subnets or ncloud_get_mysql_target_vpcs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives such as ncloud_get_cache_target_subnets for subnets or other service-specific VPC lists. The description does not mention prerequisites or typical use cases.

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

• ncloud_get_dashboard_widgetsA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already discloses the read-only safety profile, and the description adds the scoping constraint that the operation is for a specific dashboard, not global. However, it does not add behavioral details such as return format, pagination, or required permissions, but given the low complexity and annotation coverage, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that fronts the key information (action and resource) with no filler or unnecessary repetition. It earns its place completely.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 parameter and no output schema, the description provides enough to understand what to expect (a list of widgets for the given dashboard). Although it omits details about widget structure or response format, the context is sufficient for this tool's complexity, so a 4 is justified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the single parameter 'dashboardId' with a clear description ('Dashboard ID to get widgets for'), so the schema carries the semantic load. The description only repeats the concept of a specific dashboard without adding syntax, format, or additional context, warranting the baseline score for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('Get the list of widgets') and the resource ('a specific Cloud Insight dashboard'), using a specific verb and scoping. It also implicitly distinguishes from siblings like ncloud_list_dashboards (lists dashboards, not widgets) and ncloud_get_dashboard_widget_image (gets widget image, not list).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states what the tool does but provides no explicit guidance on when to use it versus alternatives, such as ncloud_query_widget_preview or ncloud_get_dashboard_widget_image. There is no mention of prerequisites, exclusions, or context that would help an agent choose this tool over a sibling.

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

• ncloud_get_mongodb_image_productsA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals this is a safe read operation, lowering the bar. The description adds the word 'available' but does not explain behavior such as whether regionCode filters results, what happens when omitted, or whether all regions are listed. Since annotations cover the safety profile, a mid-range score is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise sentence that states the operation and the subject clearly. There is no tangential information, and the key information is front-loaded at the beginning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with a single optional parameter and a read-only annotation, the description is adequate. It does not explain output format or how the result is used, but the tool's scope is narrow and the purpose is evident from the name and description. Slight deduction for not mentioning the relationship between regionCode and results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single parameter (regionCode), so the schema fully documents the parameter. The description does not add any parameter-specific context beyond what the schema already provides, which aligns with the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List available MongoDB image product codes' uses a specific verb ('List') and identifies the exact resource ('MongoDB image product codes'). It clearly distinguishes from sibling tools like ncloud_get_mongodb_products and ncloud_get_mysql_image_products by naming the database type and the specific data being retrieved.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 prerequisites, exclusions, or why one would need image product codes. With many related MongoDB tools (e.g., ncloud_get_mongodb_products, ncloud_get_mongodb_target_vpcs), the lack of contextual usage guidance is a notable gap.

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

• ncloud_get_mysql_image_productsA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this as a safe read operation, and the description's 'List' is consistent with that. However, the description adds no behavioral context beyond the annotation, such as region-specific availability, pagination, or output structure. With annotations present, this is adequate but not enhanced.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the verb 'List', and ends with a useful parenthetical clarifying 'engine versions'. There is no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only listing tool with one optional parameter, the description and schema together provide enough context to select and invoke the tool correctly. It does not explain what the product codes are used for or whether results are region-filtered, but these are not essential gaps given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the only parameter, regionCode, including allowed values and default behavior, so schema coverage is 100%. The description itself adds no parameter-level meaning, but the baseline of 3 is appropriate since the schema carries the semantic weight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and identifies a clear resource: 'available Cloud DB for MySQL image product codes (engine versions)'. The parenthetical clarifies that this is about engine versions, distinguishing it from sibling compute-product tools like ncloud_get_mysql_products.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no explicit when-to-use guidance or mention of alternatives. The description does not say that this should be used before creating an instance or that ncloud_get_mysql_products is for compute specs. Usage is only implied by the list action itself.

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

• ncloud_get_nas_volume_access_control_rulesA
  3.6/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already indicates a safe read operation, and the description's 'Get' is consistent. The description adds that it returns a 'list' of rules, but it does not disclose details such as possible empty results, ordering, or response structure. This is acceptable for a simple getter with read-only annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that immediately states the action and resource, with no unnecessary words or repetition of the tool name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 well-documented parameter and no output schema, the description adequately conveys the purpose and expected return ('list of access control rules'). It is sufficiently complete for the agent to select and invoke the tool correctly, though a mention of the rule structure could enhance completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter nasVolumeInstanceNo, with a clear description ('NAS volume instance number') provided in the schema. The description adds no additional parameter semantics, which is fine given the schema already fully covers it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' and identifies the resource as 'access control rules configured for a NAS volume.' This clearly distinguishes the tool from sibling mutation tools like ncloud_add_nas_volume_access_control, ncloud_set_nas_volume_access_control, and ncloud_remove_nas_volume_access_control.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as the set/add/remove access control operations. The description simply states what it does without offering context, exclusions, or prerequisites.

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

• ncloud_get_network_interface_detailA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this is a safe read operation. The description adds minimal behavioral context beyond 'detailed information' and does not disclose return format, pagination, or error behavior. With annotations covering the safety profile, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence that immediately states the action and target. It is front-loaded and contains zero unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-by-ID operation with a single required parameter and readOnlyHint annotation, the description is sufficient. It does not detail what 'detailed information' includes, but the lack of an output schema is common for such tools and the context is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage with a clear description of 'networkInterfaceNo' as 'Network interface number to query'. The description adds no additional meaning beyond the schema, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('detailed information about a specific network interface'), clearly distinguishing it from the list operation ('ncloud_list_network_interfaces') by emphasizing a single specific interface. The name reinforces the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (like needing the networkInterfaceNo), exclusions, or related read tools, leaving the agent to infer usage from the name and parameter.

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

• ncloud_get_port_pluginA
  3.6/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=true, so the safe-read nature is covered. However, the description adds no additional behavioral context such as what happens if the instance does not exist, whether a default configuration is returned, or what the response contains. It provides no behavioral traits beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  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. No redundancy or extraneous information—every word contributes to conveying the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only getter with one well-described parameter and no output schema, the description is sufficient: it identifies the target resource and input. It could be more complete by hinting at the response format, but the tool's simplicity and the existing annotations make it adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single parameter instanceNo, which is already described as 'Server instance number'. The tool description merely repeats the idea of a 'specific server instance' without adding further semantic detail, so it meets but does not exceed the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('port monitoring plugin configuration') and scopes it to 'a specific server instance', which clearly distinguishes it from sibling tools like ncloud_list_port_plugins (listing all) and ncloud_add_port_plugin (adding). It unambiguously communicates the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when you need the port monitoring plugin configuration for a specific server instance, but it does not explicitly state when to use it versus alternatives (e.g., list_port_plugins to enumerate all, or add/set to modify). There are no exclusions or prerequisites mentioned.

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

• ncloud_get_postgresql_instance_detailA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already discloses that this is a safe read operation, and the description's 'Get' wording is consistent with that. The description adds no further behavioral context (e.g., what detailed information is returned), but the annotation covers the key safety dimension.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the tool's purpose, making it highly efficient and appropriately sized for a simple get-detail operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter, read-only detail lookup, the description is sufficiently complete. It clearly identifies the action and target resource, and the readOnlyHint annotation plus fully documented parameter reduce ambiguity. The absence of an output schema is not a significant gap for this simple operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully covers the only parameter (cloudPostgresqlInstanceNo with description 'Cloud PostgreSQL instance number to query'). The tool description adds no additional semantic value for the parameter, so a baseline score of 3 is appropriate given the 100% schema description coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' with a clear resource: 'detailed information about a specific Cloud DB for PostgreSQL instance.' It appropriately contrasts with sibling list tools by emphasizing a specific instance, though it does not explicitly name alternative tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: use this when you need details about one instance, as opposed to listing instances. No explicit when-to-use or why-this-over-alternatives guidance is provided, but the name and phrasing make the intended context reasonably clear.

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

• ncloud_hadoop_list_mysql_instancesA
  3.6/5.0
  Behavior3/5

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

  The description is consistent with the readOnlyHint annotation, which already signals a safe read operation. It adds some scoping context ('for Hive metastore integration') but does not disclose details like filtering behavior, pagination, or response format. This is similar to the high-calibration example where limited extra context earned a 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that leads with the verb and resource, with no redundant content. Every word adds value, making it highly efficient for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the tool is simple (2 params, read-only, no output schema), the description lacks critical contextual details: it does not explain how parameters filter results, what the returned list contains, or how this relates to Hive metastore setup. The ambiguous phrase 'for Hive metastore integration' could mean these instances are already integrated or are candidates, creating confusion. This is insufficient for an agent to reliably select and invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes both parameters ('Region code' and 'Cloud Hadoop instance number') with 100% coverage, so the baseline is 3. The description does not add any additional meaning about how these parameters affect the listing, nor does it clarify the role of 'cloudHadoopInstanceNo' in the Hadoop context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and the resource ('Cloud DB for MySQL instances') with a specific purpose ('for Hive metastore integration'). This distinguishes it from the sibling tool 'ncloud_list_mysql_instances' (generic MySQL listing) and other Hadoop-related tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for Hive metastore integration' implies when this tool is useful, but it does not explicitly mention alternatives or exclusions. There is no guidance on when to prefer this over 'ncloud_list_mysql_instances' or other similar tools, leaving usage context 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.

• ncloud_kms_get_key_activity_logsA
  3.6/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already covers the read-only nature. The description adds minimal context with the parenthetical '(usage history)', which clarifies the content of the logs but does not disclose other behavioral traits such as pagination behavior, required permissions, or return format. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that front-loads the verb and object. Every word contributes; there is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple retrieval tool with a fully described schema and a read-only annotation, the description is adequate. It conveys the core purpose and scope. However, it lacks explicit mention of pagination or prerequisite keyTag, though these are visible in the schema. Overall, it is complete enough for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%; all parameters (keyTag, pageNo, pageSize) have clear descriptions in the schema. The tool description adds no additional parameter semantics beyond what the schema already 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get'), the resource ('activity logs'), and the scope ('for a specific KMS key'). It distinguishes this tool from siblings like ncloud_kms_get_latest_use_info or ncloud_kms_get_key_info by focusing on activity/usage history.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. There is no mention of related tools like ncloud_kms_get_latest_use_info or when one might prefer this over other logging tools. The only inferred usage is from the tool name and description.

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

• ncloud_kms_get_key_version_listA
  3.6/5.0
  Behavior2/5

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

  The readOnlyHint annotation already indicates a safe read operation, but the description adds no additional behavioral context such as pagination, version states, or response format. It doesn't go beyond what the annotation already provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no redundant words. It is appropriately sized for a simple list operation and front-loaded with the action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one well-documented parameter and a readOnlyHint annotation, the description adequately covers the essential purpose. No output schema or complex behavior exists to require additional explanation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents keyTag with 'Key tag - unique identifier derived from key name' (100% coverage). The description does not add any parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get list of all versions for a specific KMS key.' It clearly differentiates from sibling tools like ncloud_kms_get_key_list (which lists keys) and ncloud_kms_get_key_info (which gets key info).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (listing versions of a key) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The context is clear, but no sibling differentiation or when-not-to-use guidance is given.

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

• ncloud_list_cache_backup_detailsA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description's 'List' is consistent with that. The description adds the behavioral detail that results include file paths, which is useful context, but does not disclose other traits like pagination or return format. With annotations covering the safety profile, this is a moderate score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the action, target, and a key detail (file paths) without any filler or redundancy. It is perfectly concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with two required parameters and a read-only annotation. The description covers the core purpose and an important output detail. It doesn't explain relationships to sibling list tools or edge cases, but given the low complexity and good annotations, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema documents both parameters with descriptions, giving 100% schema coverage. The description references a 'Cloud Cache server instance' which aligns with the parameter names, but it doesn't add meaning beyond the schema's parameter descriptions. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List) and resource (detailed backup information for a Cloud Cache server instance), and adds the specific detail 'includes file paths' to indicate granularity. However, it does not explicitly differentiate from sibling tools like ncloud_list_cache_backups, so it earns a 4 rather than a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (when detailed backup info with file paths is needed) but does not explicitly mention alternatives or when not to use it. This is adequate but not fully explicit.

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

• ncloud_list_cache_manual_backupsA
  3.6/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already declares this as a safe read operation. The description adds no further behavioral context, such as pagination behavior, default page size, or how the optional cloudCacheInstanceNo filter affects results. It does not contradict the annotation, but it contributes little beyond what the annotation already conveys.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that front-loads the primary verb and resource. It is concise with no filler or wasted words, making it highly scannable for an agent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of this list operation, the readOnlyHint annotation, and the fully documented optional parameters, the description is largely sufficient. It lacks an output schema or mention of return fields, but for a straightforward list tool with read-only semantics, this is acceptable. It could be improved with brief notes on pagination defaults, but it is not critically incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides complete descriptions for all three parameters (pageNo, pageSize, cloudCacheInstanceNo) with 100% coverage. The description does not add any additional meaning or usage details beyond what the schema already specifies, matching the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('List') and resource ('manual backups for Cloud DB for Cache instances'), clearly distinguishing it from sibling tools like 'list_cache_manual_backup_details' and 'list_cache_backups'. The phrase 'manual backups' differentiates it from other backup listing tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or explicitly contrast with similar sibling tools, such as 'list_cache_manual_backup_details' or 'list_cache_backups'. The description only states what the tool does, not when to choose it.

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

• ncloud_list_custom_resourcesA
  3.6/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already indicates a safe read operation, so the description does not contradict annotations. It adds the 'user-defined' scoping but does not disclose other behavioral traits such as pagination, result format, or authentication needs.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant wording. It conveys the tool's purpose efficiently and contains zero waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with two optional parameters fully described in the schema and a read-only annotation, the description is nearly sufficient. However, it lacks a note about alternatives or return value scope, which keeps it slightly below complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the description adds no parameter-level detail beyond the schema. The query and resourceTypeId parameters are self-explanatory from the schema, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get the list') and the resource ('user-defined custom resources in Cloud Insight'). This distinguishes it from sibling tools like get_custom_resource (which fetches a single resource) and create/update/delete custom resource variants.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as ncloud_get_custom_resource or ncloud_resource_list_resources. There is no mention of exclusions, prerequisites, or preferred use cases.

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

• ncloud_list_load_balancersA
  3.6/5.0
  Behavior3/5

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

  The annotations provide readOnlyHint: true, so the description correctly implies a safe read operation. It adds the useful scope 'current region' but fails to disclose that pagination parameters (pageNo, pageSize) exist, which means 'all' may require multiple calls. No contradiction with annotations, but limited behavioral depth beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear, front-loaded sentence with no filler or redundancy. Every word contributes to understanding the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with a readOnly annotation, full schema coverage of all parameters, and clear naming, the description is mostly complete. However, it does not mention the potential need for pagination when saying 'all', nor does it describe the return format (though there is no output schema). This small gap prevents a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 6 parameters are described in the input schema with 100% coverage, so the schema carries the full parameter meaning. The description adds no extra information about filters or pagination, earning the baseline score of 3 for a description that does not actively help explain parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all load balancer instances in the current region' uses a specific verb ('List'), resource ('load balancer instances'), and scope ('current region'), clearly distinguishing it from siblings like get_load_balancer_detail, create_load_balancer, or delete_load_balancers. The word 'all' also signals this is a broad list operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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. It does not mention that for a single load balancer's details one should use ncloud_get_load_balancer_detail, or that ncloud_list_lb_listeners is for listeners. The usage context is only implied by the verb 'list' and the resource name.

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

• ncloud_list_mssql_backup_detailsA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds that the list includes file paths, but no further behavioral context (e.g., pagination, response size, or error conditions) is disclosed. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single concise sentence with no redundancy, front-loaded with the action 'List'. Every word contributes; it is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate for a simple read-only listing tool with full schema coverage and an output-free response. However, it omits the fact that both instance and server instance numbers are required, and does not specify the scope beyond instance level. Slight under-specification of required context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with descriptions ('Cloud MSSQL instance number' and 'Cloud MSSQL server instance number'). The description adds no additional parameter information beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and resource 'detailed backup information for a Cloud DB for MSSQL instance', clearly distinguishing it from broader listing tools like ncloud_list_mssql_backups. The phrase 'including file paths' adds concrete scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives such as ncloud_list_mssql_backups or similar backup detail tools for other databases. It does not state any exclusions or prerequisites.

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

• ncloud_list_mysql_backupsA
  3.6/5.0
  Behavior2/5

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

  The readOnlyHint annotation already establishes the safe read-only nature, but the description adds no extra behavioral context such as pagination, response format, or scope limitations. It merely restates the action, contributing no insights beyond what annotations and the schema already provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no redundant words. It is perfectly front-loaded and every word contributes to understanding the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter list tool with readOnlyHint annotation, the description is adequate: it clearly states the action and resource. However, it does not mention the lack of backup details or the output structure (no output schema exists), leaving minor gaps for an agent that might confuse this with the sibling 'list_mysql_backup_details' tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with one parameter ('cloudMysqlInstanceNo') described as 'Cloud MySQL instance number'. The description offers no additional parameter detail, but since the schema fully documents the parameter, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List backups for a Cloud DB for MySQL instance' uses a specific verb ('List') and resource ('backups for a Cloud DB for MySQL instance'). It clearly distinguishes from sibling tools like 'ncloud_list_mysql_backup_details' and 'ncloud_list_mysql_instances', making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: call this when you need to list backups for a specific MySQL instance. However, it provides no explicit guidance on when to use this vs. closely related siblings (e.g., 'ncloud_list_mysql_backup_details') or any prerequisites/exclusions, leaving the agent to infer context from the tool name alone.

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

• ncloud_list_rolesA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint=true annotation already establishes that this is a safe read operation. The description adds the domain (IAM roles) but does not disclose behavioral details such as pagination behavior (i.e., page/size parameters) or that 'all' requires iterating over multiple pages. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise sentence with no filler or redundancy. It front-loads the core purpose and is appropriately sized for a simple list tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward read-only list tool with full schema coverage and a read-only annotation, the description provides adequate context. However, it could benefit from noting that results are paginated via the page/size parameters, which would clarify the scope of 'all'.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all four parameters (page, size, searchWord, searchColumn) with 100% coverage. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all IAM roles' uses a specific verb ('List') and a clear resource ('IAM roles'), distinguishing it from sibling tools like ncloud_list_policies and ncloud_list_groups. It fully conveys the tool's function in four words.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or contrasts with other list tools (e.g., list_policies, list_groups), leaving the agent to infer usage from the name alone.

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

• ncloud_list_serversA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the description does not need to establish safety. It does add context by specifying 'current region,' which is useful scoping information. However, it does not disclose details about pagination behavior or return format, which would add value 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, tightly packed sentence that states exactly what the tool does. There is no redundancy or unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with all optional parameters documented in the schema, the description is sufficient. It could mention pagination or that it returns a list of server instances, but these are implied by the tool name and the parameter schema. The lack of an output schema increases the need for some return guidance, but the overall context is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (vpcNo, pageNo, pageSize, serverInstanceNoList) having a clear description. The tool description adds no additional parameter meaning, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List'), identifies the resource ('server instances'), and scopes the operation ('in the current region'). This clearly distinguishes it from single-server actions like ncloud_get_server_detail or creation/management tools such as ncloud_create_server or ncloud_terminate_server.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description does not mention that for a single server one should use ncloud_get_server_detail, nor does it explain pagination or filtering options. The scope is limited to a single indicative sentence.

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

• ncloud_nks_create_node_poolA
  3.6/5.0
  Behavior3/5

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

  Annotations only include destructiveHint: false, which is minimal. The description adds the dryRun preview capability, but it does not disclose other behavioral aspects such as the mutating side effects, potential waiting time for provisioning, or what happens on validation failure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with no filler. It front-loads the core purpose and includes a practical usage tip, each sentence earning its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a complex operation with 12 parameters, nested objects, and no output schema, yet the description is minimal. It lacks crucial context such as return values, preconditions (e.g., the cluster must already exist), and logic around nodeCount vs autoscale, making it insufficient for fully informed invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% parameter descriptions, so parameters are already fully documented. The description only mentions dryRun, which the schema already explains ('If true, preview only'), adding no new meaning beyond the structured data.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Create a new node pool in an NKS cluster' with a specific verb and resource, distinguishing it from sibling tools like create_cluster, list_node_pools, and delete_node_pool. The added tip about dryRun=true also provides a distinct behavioral pointer.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a context: the node pool is created in an NKS cluster, and a specific usage hint: 'Use dryRun=true to preview.' However, it does not explicitly state when to use this tool versus alternatives (e.g., create_cluster or update_node_pool) or mention preconditions like the cluster already existing.

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

• ncloud_nks_get_kubeconfigA
  3.6/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the readOnlyHint annotation. It does not disclose what the kubeconfig response contains, authentication requirements, or any other operational details. The annotation already communicates that this is a safe read operation, so the description contributes little additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one sentence of ten words, front-loaded with the action ('Retrieve') and the resource ('kubeconfig'), making it concise and immediately parsable with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple getter with one parameter and a read-only annotation, the description is adequate. It could have mentioned the kubeconfig content or return format, but given the low complexity and the useful annotation, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the single parameter (clusterUuid with description 'UUID of the cluster'), so the schema coverage is 100%. The description's reference to 'a specified NKS cluster' mirrors the schema without adding new semantic detail. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Retrieve' and clearly identifies the resource as the kubeconfig for an NKS cluster. This distinguishes it from sibling tools like ncloud_nks_reset_kubeconfig (which resets) and ncloud_nks_get_cluster (which gets cluster info).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives or mention any prerequisites. Usage is implied by the tool's name and straightforward retrieval purpose, but no explicit guidance is provided.

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

• ncloud_nks_get_oidcA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates this is a safe read operation, and the description's 'Get' is consistent with that. The description adds no further behavioral context (e.g., whether the cluster must exist, error scenarios, or what specifically is returned), but it does not contradict the annotation either.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no redundant words. It front-loads the action and resource, and there is no filler or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one required parameter, no nested objects, no output schema) and the clear purpose, the description is largely complete. However, it does not describe the return value structure (e.g., what an OIDC configuration contains), which could be useful given there is no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%; the single parameter 'clusterUuid' is described as 'UUID of the cluster', which is adequate. The description does not add any extra parameter semantics beyond this, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the resource ('OIDC provider configuration for an NKS cluster'), and it distinguishes the tool from siblings like ncloud_nks_set_oidc by specifying a read operation. The naming and description are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No usage guidance is provided beyond the action itself. The description does not mention when to use this tool versus ncloud_nks_set_oidc (for configuring OIDC) or ncloud_nks_get_cluster (for general cluster info), nor does it specify any prerequisites or alternatives.

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

• ncloud_nks_list_access_entriesA
  3.6/5.0
  Behavior2/5

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

  The readOnlyHint annotation already discloses the safe read-only nature of the tool. The description adds no behavioral context beyond that, such as pagination, required permissions, or response format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler or redundant details. It is appropriately concise for a simple list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a very simple tool with one well-documented parameter and a readOnly annotation. The description is sufficient for selecting and invoking the tool, though it omits any mention of the return list structure. Given the minimal complexity, this is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single clusterUuid parameter with the description 'UUID of the cluster'. The tool description does not add meaning beyond reinforcing that the list is for an NKS cluster, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List'), a clear resource ('IAM access entries'), and a scope ('for an NKS cluster'). It distinguishes well from sibling tools like ncloud_nks_create_access_entry, ncloud_nks_update_access_entry, ncloud_nks_delete_access_entry, and especially ncloud_nks_get_access_entry.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied through the verb 'List' and the tool name, but there is no explicit guidance about when to choose this over ncloud_nks_get_access_entry or the mutation tools. No alternatives, exclusions, or preconditions are mentioned.

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

• ncloud_nks_list_node_poolsA
  3.6/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint: true, so the read-only nature is disclosed. The description adds that it lists 'all' node pools, implying a collection result, but does not mention pagination, response format, or any other behavioral traits. Since annotations cover safety, the description is consistent and adds minimal extra context, earning a mid-range score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 11 words, front-loading the verb and resource. Every word earns its place, and there is no redundancy or unnecessary verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (one required parameter, read-only annotation, no output schema), the description is nearly complete. It could mention what the response contains (e.g., node pool details) or note that it returns multiple items, but the core info needed for tool selection is present. The absence of an output schema shifts some burden, but the tool is simple enough that the description suffices.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clusterUuid described as 'UUID of the cluster'. The description merely repeats this by saying 'in a specified NKS cluster', adding no new semantic detail. The parameter is self-explanatory, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all node pools in a specified NKS cluster' uses a specific verb (list), resource (node pools), and scope (specified NKS cluster). It clearly distinguishes from sibling tools like ncloud_nks_list_clusters (lists clusters) and ncloud_nks_list_worker_nodes (lists worker nodes), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 prerequisites like needing an existing cluster UUID beyond the parameter name, nor does it exclude overlapping tools like ncloud_nks_list_clusters or ncloud_nks_get_cluster. Usage context is only implied by the phrase 'specified NKS cluster', not explicitly stated.

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

• ncloud_nks_list_worker_nodesA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares this as a read-only operation. The description adds minimal behavior beyond that—it identifies the resource scope ('in an NKS cluster') but doesn't disclose any additional traits like pagination, filtering, or required cluster UUID context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with clear structure, containing no unnecessary words or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one required parameter, read-only annotation, and no output schema, the description adequately conveys the core function. It lacks any mention of return content or edge cases but remains sufficient for basic selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single clusterUuid parameter ('UUID of the cluster'). The description adds no further semantic meaning beyond the schema, which is sufficient for a one-parameter tool, hence baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 'worker nodes in an NKS cluster', differentiating it from sibling tools like ncloud_nks_list_node_pools which operate on a different resource (node pools).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as ncloud_nks_list_node_pools or ncloud_nks_get_cluster. Usage context is only implied by the simple 'list' verb, with no exclusions or alternatives mentioned.

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

• ncloud_nks_set_audit_logA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate the operation is idempotent and non-destructive. The description adds minimal extra context by mentioning 'via Cloud Log Analytics', implying the audit logs are shipped to an external service. However, it does not disclose potential effects like overwriting existing audit settings, whether the cluster must exist, or any delay/activation behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the core action and resource. Every word earns its place, with no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter configuration tool with clear annotations and schema, the description provides adequate context for correct invocation. It does not explain prerequisites or effects of setting audit to false, but the simple nature of the tool and the existing structured metadata keep it mostly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage: 'audit' is described as a boolean enabling audit log collection, and 'clusterUuid' is described as the UUID. The tool description adds no additional meaning or usage details for these parameters, so it does not go beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Configure), the resource (audit log collection), and the target (an NKS cluster), while specifying the integration with Cloud Log Analytics. This distinguishes it from sibling NKS set tools like ncloud_nks_set_oidc and ncloud_nks_set_ip_acl, which target different configuration areas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, no prerequisites, and no exclusions. It is a single declarative sentence without any context about when to enable/disable audit logs or how this relates to other NKS cluster configuration tools.

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

• ncloud_nks_update_lb_subnetA
  3.6/5.0
  Behavior3/5

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

  Annotations already provide idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds a little context by specifying the target resource ('load balancer subnet') and cluster type ('NKS'), but it does not disclose additional behavioral details such as whether the update replaces existing subnet settings, requires both public and private subnets, or triggers any side effects. It neither contradicts the annotations nor goes far beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence: 'Update load balancer subnet for an NKS cluster.' It contains no fluff, repetitions, or extraneous information. Every word contributes to the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple update tool with full schema coverage and benign annotations, the description is reasonably complete. It identifies the action, resource, and scope, and the schema documents all parameters including required and optional fields. It does not explain return values or prerequisites, but no output schema exists and the operation is straightforward. The lack of guidance about optional parameter combinations or constraints (e.g., subnet must be in the same VPC) is a minor gap, but not critical for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage, with descriptions for all three parameters: clusterUuid, lbPublicSubnetNo, and lbPrivateSubnetNo. The description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline of 3 is appropriate. It implies that 'load balancer subnet' refers to the public/private subnet numbers, but the schema states this directly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Update'), a specific resource ('load balancer subnet'), and a clear scope ('for an NKS cluster'). It distinguishes itself from sibling NKS subnet tools like 'update_node_pool_subnet' and from generic load balancer tools like 'set_lb_subnet' by naming both the resource and the cluster type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, no prerequisites, and no exclusions. It does not mention when updating a load balancer subnet would be necessary, nor does it reference sibling tools like 'ncloud_nks_update_node_pool_subnet' or 'ncloud_set_lb_subnet' for comparison.

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

• ncloud_pca_get_caA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already communicates safe read-only behavior, and the description is consistent with it ('Get' rather than modify). No additional behavioral details are disclosed—such as what happens for a non-existent tag or what 'detailed information' includes—so the description adds little beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single 13-word sentence that states the essential action and identifier method with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only lookup with one required parameter and no output schema, the description is adequate for selection and invocation. However, 'detailed information' is vague and does not clarify the response structure or edge cases, so completeness is good but not maximal.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with caTag documented as 'CA tag value (identifier)'. The description's phrase 'by its tag value' merely restates the parameter's purpose and adds no new meaning or format constraints. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource ('Get detailed information of a specific Private CA') and clearly indicates the lookup key ('by its tag value'). This distinguishes it from sibling tools like ncloud_pca_list_cas (list all) and ncloud_pca_get_ca_chain (get chain). The purpose is unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit usage guidance is given. The description does not mention when to prefer this tool over alternatives or note any prerequisites, exclusions, or fallback tools. The sibling context implies a get-vs-list distinction, but the description itself provides no such guidance.

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

• ncloud_pca_get_ca_chainA
  3.6/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already establishes the safe read-only nature. The description adds the output format (PEM) and resource type (Private CA) beyond the annotation, but does not describe error cases, return structure, or other behavioral traits. Given the annotation covers the main safety aspect, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence, nine words, front-loaded and direct. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one parameter, read-only, no output schema). The description conveys the purpose and the input's reference, which is sufficient for a basic retrieval operation. It could benefit from noting that the chain is for a Private CA only, but the name and description already convey that. Minor gaps prevent a 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the parameter caTag is documented as 'CA tag value'. The description clarifies that the tag refers to the Private CA whose chain is requested, adding slight context, but does not elaborate beyond the schema. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('Get'), the resource ('certificate chain (PEM) of a Private CA'), and is distinct from sibling PCA tools like get_ca and get_ca_crl. 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.

  Usage Guidelines2/5

  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, no prerequisites, and no exclusions. It simply states what it does, leaving the agent to infer usage from the name.

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

• ncloud_pca_get_ca_crlA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates this is a safe read operation. The description adds the output format (PEM), which is useful but minimal. It does not disclose additional behavioral traits such as error handling, rate limits, or whether the CA must exist. With annotations present, the bar is lower, and the description meets the minimum by not contradicting the read-only nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the action ('Get') and includes the key detail (PEM format). No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter, full schema coverage, and a readOnly annotation, the description is adequate. It specifies the output format (PEM) even though there is no output schema, covering the most critical return detail. It does not explain the response structure or error cases, but for such a focused retrieve operation, this is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with caTag described as 'CA tag value'. The description does not add extra meaning beyond the schema, but since the schema fully documents the parameter, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets the CRL of a Private CA in PEM format, using a specific verb ('Get') and resource ('CRL of a Private CA'). This distinguishes it from sibling tools like ncloud_pca_get_crl_config (configuration) and ncloud_pca_get_ca_chain (chain).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention when to prefer this over ncloud_pca_get_crl_config or ncloud_pca_rotate_crl, nor does it state any exclusions or prerequisites. The usage context is implied but not stated.

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

• ncloud_resource_attach_groupA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond the basic action, such as whether existing memberships are preserved or error scenarios. It does not contradict annotations, but it does not enrich them either.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no filler. It conveys the essential action and scope efficiently, earning a top score for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with annotations and no output schema, the description is adequately complete. It clarifies the 'add' semantics (not replace) and covers 'one or more' resources. Slight gap: it does not mention behavior when resources are already in the group, but this is minor for a basic attach operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes both parameters (groupId and nrnList) with 100% coverage. The description adds no additional parameter semantics, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Add one or more resources to a resource group' clearly states the action (add), the object (resources), and the destination (resource group). It effectively distinguishes the tool from siblings like detach_group and attach_tag by specifying the resource-group context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. With siblings like ncloud_resource_attach_tag and ncloud_resource_detach_group, the description offers no context for selection or exclusions. The purpose implies usage but does not explicitly state it.

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

• ncloud_resource_list_groupsA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates this is a safe read operation, and the description's 'List' action aligns with that. However, the description adds no behavioral context beyond the annotation, such as pagination behavior details or return format, so it provides minimal added transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that immediately states the tool's purpose and key capabilities. It is front-loaded and contains no filler, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool, this description is largely complete: it states the action, resource, and optional parameters. The absence of an output schema is acceptable for a list operation, and the low complexity means the description does not need to explain much beyond what is provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, with each parameter clearly documented (page, size, groupName). The description simply mentions 'name filter and pagination' without adding further context beyond what the schema already provides. The schema carries the semantic weight, so the description adds little extra value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists resource groups with optional name filtering and pagination. It uses a specific verb and resource, which distinguishes it from most other tools in the sibling list, though it does not explicitly differentiate from similar tools like ncloud_list_groups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when you need to list resource groups, but it provides no explicit guidance on when to use it versus alternatives or any exclusions. There is no mention of when not to use it or what other tools might be better suited for related tasks.

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

• ncloud_resume_processesA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, so the description's addition of 'previously suspended' provides some context about the target state. However, it does not disclose behavior if called on non-suspended processes, potential asynchronous side effects, or what response to expect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter mutation with idempotent and non-destructive annotations, the description is adequately complete. It covers the operation scope, and the schema provides full parameter descriptions. No output schema exists, but given the tool's simplicity, the lack of return-value details is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both autoScalingGroupNo and scalingProcessCodeList have descriptions. The tool description does not add meaning beyond the schema; it does not clarify what scaling process codes are valid, though sibling tool ncloud_get_scaling_process_types exists for that purpose.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Resume') and the resource ('scaling processes for an Auto Scaling Group'), and the phrase 'previously suspended' clarifies the targeted state. It is distinct from sibling tools like ncloud_suspend_processes and ncloud_get_scaling_process_types, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage after processes have been suspended, but it does not explicitly state when to use this tool versus alternatives like ncloud_suspend_processes, nor does it mention any prerequisites or exclusions. The guidance is mostly implied by the verb 'resume'.

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

• ncloud_ses_create_clusterA
  3.6/5.0
  Behavior3/5

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

  Annotations provide destructiveHint=false, and the description adds the dryRun preview capability, which is a behavioral hint beyond the annotation. However, it does not disclose other important behaviors such as cost implications, requirement for existing VPC/subnet, or that creation may take time. With annotations present, the bar is lower, but the description still lacks meaningful behavioral context beyond the dryRun tip.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that covers the core action and a key usage tip. No wasted words, and the information is front-loaded. It is appropriately concise for the low-level of detail it provides.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a complex tool with 20 parameters and 14 required fields, yet the description is extremely sparse. It does not mention prerequisites like fetching product codes via getOsProductList, search engine version codes, or subnet selection. There is no output schema, and the description does not compensate by explaining the overall workflow or expected effects. The dryRun hint is useful but insufficient for such a complex operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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's mention of 'dryRun=true' adds no new meaning because the schema already documents the dryRun parameter as 'If true, preview only without creating.' No additional parameter semantics are provided beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: 'Create a new Search Engine Service cluster (G2)'. The verb 'Create' plus the specific resource 'Search Engine Service cluster' and version 'G2' make the purpose unambiguous and distinguish it from the sibling tool ncloud_ses_create_cluster_g3.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives one explicit usage hint: 'Use dryRun=true to preview.' However, it does not explicitly contrast with alternative tools or mention when to use G2 versus G3. Usage context is implied by the 'G2' label, but no exclusions or alternative suggestions are provided.

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

• ncloud_ses_get_node_productsA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation covers the safety profile, and the description consistently indicates a read operation ('Get'). It adds the G2 scope and product code context, but does not disclose further behavioral details such as pagination or response format. With annotations present, this level is acceptable but not extensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, tightly worded sentence that front-loads the core action and includes the service and generation context. No unnecessary information is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only lookup with one required parameter, the description provides the service (SES), generation (G2), and output type (product codes). It does not need to explain return values since it's a straightforward list and there is no output schema. Slightly more context about the output structure could be added, but it is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the single parameter (softwareProductCode) with a cross-reference to getOsProductList, achieving 100% coverage. The description itself does not add new parameter details, but the schema already carries the semantic load. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves available node server types (product codes) for Search Engine Service (G2), using a specific verb and resource. It distinguishes itself from related tools like ncloud_ses_get_server_specs by explicitly mentioning 'product codes', though it does not fully delineate when each should be used.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives, but it does mention the prerequisite parameter source ('from getOsProductList'), implying a workflow. This provides some contextual guidance but no explicit alternatives or exclusions.

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

• ncloud_ses_get_subnet_listA
  3.6/5.0
  Behavior3/5

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

  The description is consistent with the readOnlyHint annotation, but adds no additional behavioral context beyond the annotation. It does not mention pagination, auth, or return format, though the tool is a simple read-only list operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that communicates the tool's purpose and scope with no unnecessary words or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 parameter, the description is largely complete. It clearly states what it returns (subnet list) and its purpose (cluster creation). However, the lack of differentiation from the g3 variant and absence of any output schema details mean it is not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a clear description for vpcNo ('VPC number'). The tool description adds no extra parameter context, but the schema already fully documents the single required parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource 'available subnet list', with a specific context of 'for Search Engine Service cluster creation'. It distinguishes from other services' subnet list tools, but does not differentiate from the sibling tool ncloud_ses_get_subnet_list_g3.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for Search Engine Service cluster creation' implies when to use (as a prerequisite for cluster creation), but there is no explicit guidance on alternatives or exclusions. Given the presence of a similar sibling tool (get_subnet_list_g3), the description misses the opportunity to clarify which variant to choose.

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

• ncloud_ses_restart_clusterA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false. The description adds no additional context about the restart behavior (e.g., potential downtime, effect on running jobs, or confirmation requirements). With existing annotations, the description is acceptable but adds no extra transparency value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise, front-loaded sentence that clearly states the action and target. No wasted words or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a simple signature with one well-documented parameter, annotations cover safety/idempotency, and the description identifies the resource. Missing output schema is a minor gap, but for a restart operation, the essential information is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (the sole parameter 'serviceGroupInstanceNo' is described as 'Cluster instance number'). The description does not add any parameter-level information, but the schema already fully documents the required input, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Restart') and identifies the exact resource ('Search Engine Service cluster'). It clearly distinguishes this tool from sibling operations like delete, create, or upgrade, and matches the tool name precisely.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 prerequisites, situations where a restart is appropriate, or exclude use cases such as other restart operations for different services (e.g., CDSS restart tools).

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

• ncloud_set_desired_capacityA
  3.6/5.0
  Behavior2/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. However, the description adds no additional behavioral context beyond restating the function, such as the fact that setting the capacity may immediately trigger scaling activities, or that the value is subject to ASG min/max constraints. It provides no value 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence with no filler, front-loading the core action. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the operation (two parameters, no nested objects, no output schema) and the presence of helpful annotations, the description is nearly complete. It could briefly mention that the capacity may be constrained by the ASG's min/max settings, but overall it adequately covers the essential information for this low-complexity tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides complete descriptions for both parameters (autoScalingGroupNo and desiredCapacity), so the description adds no additional meaning. Coverage is 100%, which sets the baseline at 3, and the description does not enhance parameter understanding further.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Set the desired capacity for an Auto Scaling Group' uses a specific verb ('set') and a clear resource ('desired capacity for an Auto Scaling Group'), accurately distinguishing it from sibling tools like ncloud_update_asg (which updates broader ASG settings) and ncloud_put_scaling_policy (which configures scaling policies).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit usage guidance is provided. The intended use is implied by the tool name and description (manually adjusting ASG capacity), but there is no mention of when to choose this over alternatives, such as scaling policies or scheduled actions, nor any exclusions or prerequisites.

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

• ncloud_sourcebuild_get_build_historyA
  3.6/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, and the description's 'Get' is consistent with that. However, the description adds no behavioral details beyond what annotations already provide, such as pagination, ordering, or the structure of the returned history.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded with the verb and contains no filler. It is as concise as possible while still conveying the essential purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple interface (one required parameter), the readOnly annotation, and the clear naming, the description is adequate for an agent to understand what the tool does. A minor gap is the lack of any indication of what fields appear in the history, but the tool name and purpose make this mostly self-evident.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the only parameter 'projectId' with a clear description. The tool description adds no extra semantics beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get'), the resource ('build history'), and the scope ('for a SourceBuild project'). It distinguishes this from sibling tools like ncloud_sourcebuild_get_project (project details) and ncloud_sourcebuild_list_projects (all projects).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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. It does not mention that this is for reviewing past builds or that project details can be fetched using ncloud_sourcebuild_get_project. Intended usage is implied but not contrasted with other tools.

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

• ncloud_sourcecommit_delete_repoA
  3.6/5.0
  Behavior4/5

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

  The description adds value beyond the destructiveHint annotation by explicitly stating the operation is permanent and requires confirm=true to execute. This informs the agent of the irreversible nature and safety mechanism, which is useful context not present in structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with a clear warning prefix and essential instruction. Every word contributes meaning—no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive operation with two parameters and no output schema, the description covers the key facts: action, permanence, and the required confirm flag. It does not explain what happens when confirm is false, but this is inferable from the schema's default false value. Overall, adequate for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already fully documents both parameters. The description's mention of confirm=true restates the schema's own parameter description without adding new syntax, formatting, or constraints, so it meets the baseline but adds no extra semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Permanently delete') on a specific resource ('SourceCommit repository'), making the purpose clear. However, it does not explicitly distinguish from the sibling tool ncloud_sourcecommit_delete_repo_by_id, which likely deletes by repository ID rather than name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives, such as ncloud_sourcecommit_delete_repo_by_id. The only instruction is 'Set confirm=true to execute,' which is a parameter-level requirement rather than usage context or exclusions.

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

• ncloud_sourcecommit_get_repoA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates this is a safe read operation, so the description carries a lower burden. It adds the phrase 'detailed information' to indicate the scope of the response, but it does not disclose error behavior, authentication needs, or rate limits. It is consistent with the annotation but provides minimal extra context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that immediately states the action, resource, and key qualifier. It contains no superfluous words and earns its place fully.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only operation with one parameter and no output schema, the description gives enough to understand the tool's purpose. The sibling ncloud_sourcecommit_get_repo_by_id clarifies the differentiation by name, and the 'detailed information' phrase sets expectations for the return value. It does not specify exact fields or error handling, but these are not critical for this simple lookup.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, with the repositoryName parameter described as 'Name of the repository to query'. The tool description repeats the 'by name' qualifier but does not add new meaning, such as format constraints or how the name maps to the resource. Baseline 3 is appropriate since the schema already handles parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it gets detailed information about a specific SourceCommit repository by name. The verb 'Get' and the resource 'detailed information about a specific SourceCommit repository' are specific, and the 'by name' qualifier distinguishes it from the sibling ncloud_sourcecommit_get_repo_by_id.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that ncloud_sourcecommit_get_repo_by_id should be used when the repo ID is known, nor does it reference ncloud_sourcecommit_list_repos for enumeration. The agent has to infer the appropriate context from the tool name alone.

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

• ncloud_sourcecommit_list_branchesA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes this as a safe read operation. The description adds the specific behavioral detail that default branch info is included, which is useful, but it does not mention pagination, response structure, or any potential caveats. This is adequate given the annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It states the action, scope, and a key extra detail efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 provides enough information for a basic understanding. It clearly communicates the tool's purpose and highlights the inclusion of default branch info. However, it could be slightly more complete by noting what other fields are returned, but this is not critical for a straightforward list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers the only parameter (repositoryName) with a clear description ('Name of the repository'). The tool description does not add additional meaning to the parameter, as the schema already provides sufficient context. With 100% schema coverage, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and clearly identifies the resource ('all branches in a SourceCommit repository'). It also adds a useful detail about including default branch info, which distinguishes it from other branch-listing tools like ncloud_sourcebuild_list_branches or ncloud_pipeline_list_sourcecommit_branches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given about when to use this tool versus alternatives. The description does not mention exclusions or recommend other tools for related tasks, leaving the agent to infer usage solely from the tool name and context.

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

• ncloud_sourcecommit_set_default_branchA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds no further behavioral context, such as what happens if the branch does not exist or whether the previous default branch is affected. It does not contradict 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no unnecessary words. It is front-loaded and effectively communicates the tool's purpose without waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple mutation tool with complete schema and annotations, the description is sufficient. It clearly states the action and object. However, it lacks any mention of prerequisites or constraints (e.g., the branch must exist), and no usage guidance is provided, so it falls just short of excellent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with both parameters already explained ('Name of the branch to set as default' and 'Name of the repository'). The description adds no additional meaning beyond what the schema provides, which is adequate for a simple 2-param tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Set the default branch') and the resource ('SourceCommit repository'). It distinguishes from sibling tools like list_branches or edit_repo, which have different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions or direct to sibling tools for related operations, such as creating a branch before setting it as default.

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

• ncloud_sourcedeploy_get_deploy_historyA
  3.6/5.0
  Behavior3/5

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

  The description aligns with the readOnlyHint=true annotation and adds project scoping. It does not describe pagination behavior, response structure, or any operational side effects, but the annotation already covers safety. This adds some value beyond the annotation but is 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded with the action ('Get') and object ('deployment history list'). It contains no filler and is immediately understandable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, complete parameter schema, and read-only annotation, the description is nearly sufficient. It does not describe the return fields or pagination details, but the phrase 'deployment history list' implies the response shape, and the schema handles pagination parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of the parameters (projectId, pageNo, pageSize), so the description need not repeat them. However, it adds no extra semantic context about how the parameters relate to the returned history or why pageSize has a maximum of 100.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('deployment history list') scoped to a project. It clearly distinguishes from sibling get_deploy_history_detail (which retrieves a single history entry) and other sourcedeploy list tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives, nor any mention of prerequisites (e.g., needing a projectId from a list projects call). The usage context is only implicit from the name and description.

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

• ncloud_sourcedeploy_get_objectstorage_objectsA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals this is a safe read operation. The description adds minimal behavioral context by indicating that a list is returned, but it does not disclose pagination, ordering, permissions, or any other operational nuances. It is consistent with the annotation, so no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that immediately conveys the tool's purpose. There is no redundant wording or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool with full schema coverage and a readOnlyHint annotation, the description is largely sufficient. It clearly states what is returned (a list of objects) and the only required input is well-documented. Some guidance about pagination or relationship to generic Object Storage tools would improve it, but this is not critical for such a basic operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully covers the single parameter 'bucketName' with a description 'Name of the Object Storage bucket'. The tool description merely echoes this by saying 'in an Object Storage bucket', adding no additional semantic explanation beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource 'list of objects in an Object Storage bucket'. It differentiates from sibling tools like ncloud_sourcedeploy_get_objectstorage_buckets (which lists buckets) and ncloud_list_objects (which is a more generic Object Storage list operation).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as ncloud_list_objects or ncloud_get_object. It only states what the tool does, leaving the agent to infer appropriate usage from the tool name alone.

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

• ncloud_vodstation_list_categoriesA
  3.6/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already covers the safety profile, and the description adds the 'list all' scope and domain context. However, it does not disclose additional behavioral traits such as pagination behavior, result ordering, or whether only accessible categories are returned. The description adds minimal value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with zero wasted words. It is appropriately sized for a simple read-only list operation and communicates the core purpose directly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity, the readOnlyHint annotation, and full parameter schema coverage, the description is adequate. It is missing usage guidance and some return detail (since there is no output schema), but the succinct purpose statement is sufficient for an agent to select and invoke the tool without confusion. The lack of an output schema is partially mitigated by the phrase 'List all,' implying a list result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers both parameters (pageNo and pageSizeNo) with descriptions, giving 100% coverage. The description does not add any additional meaning about parameter usage or formatting, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and identifies the resource as 'VOD Station encoding categories,' clearly distinguishing it from sibling tools like ncloud_vodstation_list_channels and ncloud_vodstation_get_channel. The scope 'all' is explicit, leaving no ambiguity about what the tool returns.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, nor does it mention any prerequisites or exclusions. For a listing tool, it is implied that one would use it to fetch categories, but the description does not explicitly state when it should be preferred over related tools such as list_channels or create_category.

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

• ncloud_add_mongodb_usersA
  3.7/5.0
  Behavior2/5

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

  The only annotation is destructiveHint: false, which conflicts with nothing. The description adds no behavioral details beyond what the name suggests, such as idempotency, error scenarios, or prerequisites. With annotations covering the safety profile, the description still offers no extra context, so a score of 2 reflects the lack of added transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no redundant information, front-loading the action and target. It earns a 5 for efficiency and clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple add operation, the description is functional but minimal. It does not mention response behavior, side effects, or validation rules, and there is no output schema to compensate. While the schema covers parameters, the description alone provides limited context beyond the tool's purpose, so a 3 is reasonable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for both parameters and nested user fields. The description does not add any additional meaning or clarify parameter usage, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Add' with the resource 'users' and target 'Cloud DB for MongoDB instance', clearly distinguishing it from sibling tools like ncloud_list_mongodb_users, ncloud_change_mongodb_users, and ncloud_delete_mongodb_users.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: this tool is for adding users to a MongoDB instance. However, it lacks explicit guidance about when not to use it (e.g., for modifying existing users) or mentions of alternatives. The verb 'Add' alone implies creation, but no explicit exclusions are stated, so a 4 is appropriate.

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

• ncloud_add_mysql_databasesA
  3.7/5.0
  Behavior3/5

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

  The annotation destructiveHint=false already indicates the operation is non-destructive, and the description adds no additional behavioral context. It does not mention potential failure conditions, idempotency, or any side effects beyond the simple addition of databases. The description is consistent with the annotation but does not enrich it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that directly states the tool's action and target. There is no redundant or extraneous information, and it is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple and has full schema coverage for inputs, but there is no output schema and the description does not explain what the response conveys (e.g., status or job details). It also does not mention constraints like duplicate database names or instance state requirements. The description is minimally sufficient but leaves some gaps for a fully informed agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides full descriptions for both parameters (100% coverage), so the description does not need to compensate. The description itself adds no parameter-level detail, and the schema already explains that cloudMysqlInstanceNo is the instance number and cloudMysqlDatabaseNameList is the list of database names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Add' with a clear resource ('databases') and target ('Cloud DB for MySQL instance'), making the tool's purpose unambiguous. It naturally distinguishes itself from sibling tools like ncloud_delete_mysql_databases and ncloud_list_mysql_databases through the additive action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (when you need to add databases to a MySQL instance) but provides no explicit context about when to choose this tool over alternatives, nor does it mention any prerequisites or exclusions. It is minimally adequate but lacks the comparative guidance seen in stronger examples.

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

• ncloud_add_process_pluginA
  3.7/5.0
  Behavior2/5

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

  The only annotation is destructiveHint=false, so the description carries the burden of behavioral disclosure. It does not mention whether existing plugins are preserved, how duplicate names are handled, or if adding a wildcard affects monitoring behavior. The simple 'Add' action lacks important side-effect details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is composed of two concise sentences: one stating the action and target, the second explaining parameter usage. Every word adds value, and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple mutation tool, the core functionality is covered, but the description lacks guidance on how the addition interacts with existing plugins and omits any mention of the optional 'type' parameter (which defaults to vpcserver). Additional context about idempotency or the effect of wildcards would make it more complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents all three parameters, but the description adds valuable detail beyond the schema by noting that process names support wildcards (e.g., *abc*). This clarifies the intended format of the configList parameter, which the schema only describes as 'Process names to monitor'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states a specific verb and resource: 'Add process monitoring plugin(s) to a server instance.' This action is distinct from sibling tools like remove_process_plugin and set_process_plugins, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for adding plugins to a server instance and notes that wildcards are allowed. However, it does not explicitly contrast with the similar 'set_process_plugins' tool or specify when NOT to use this tool, leaving some ambiguity about the choice between additive and replacement operations.

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

• ncloud_cdnplus_get_usageA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true. The description adds context by specifying the type of data (transfer/traffic volume) and the ability to query multiple instances and a date range, but does not disclose response structure, pagination, or edge cases. It aligns with annotations and adds some value, but not deeply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence packs the essential action and scope with no redundant words. It is optimally concise and structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, so the description carries some burden for return values. It states the high-level data type (transfer/traffic volume) but omits details like per-instance granularity or units. For a simple read query, it is adequate but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with all four parameters documented (formats, defaults, array type). The description reinforces that multiple instances and a date range are involved, but does not add meaningful semantics beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb ('Get'), identifies the resource ('CDN+ usage data'), and clarifies scope ('transfer/traffic volume', 'one or more instances', 'date range'). This clearly distinguishes it from siblings like ncloud_globalcdn_get_usage and ncloud_cdnplus_get_monitoring.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context (usage data, transfer/traffic volume, multiple instances, date range) but does not explicitly state when to use this tool versus alternatives like monitoring tools, nor does it provide exclusions. Usage is implied rather than directly addressed.

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

• ncloud_cdss_create_clusterA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=false, and the description does not contradict that. It adds the dryRun preview behavior, but for a create operation that provisions cloud resources, it does not mention side effects like persistent resource creation, potential costs, or asynchronous execution. The description goes slightly beyond annotations but lacks deeper behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the core purpose and containing a useful tip. There is no fluff, and every word contributes to the tool's understanding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity (14 parameters, no output schema, minimal annotations), the description is somewhat under-specified. It does not mention prerequisites, expected response, or that related lookup tools should be consulted first. However, the rich schema descriptions partially compensate, and the core purpose is clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are fully documented in the schema. The description only reinforces the dryRun parameter and does not add additional semantic meaning. This matches the baseline for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Create), the specific resource (new CDSS (Kafka) cluster), and the generation (G2), which distinguishes it from other cluster creation tools like ncloud_ses_create_cluster and ncloud_nks_create_cluster. The dryRun tip additionally signals a validation mode, further clarifying scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (when provisioning a new CDSS Kafka cluster) and includes a practical tip about using dryRun=true to preview. However, it does not mention prerequisites such as needing a VPC, subnets, or looking up version/product codes via sibling tools like ncloud_cdss_get_kafka_versions, nor does it explicitly exclude alternatives.

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

• ncloud_cdss_get_config_group_detailA
  3.7/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates a safe read operation, so the description does not need to cover safety. It adds minimal behavioral context by mentioning 'including Kafka settings', which hints at response contents, but does not disclose potential nuances like pagination, errors, or required prerequisites. The description does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the tool's purpose and key scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the tool is relatively simple with one parameter and a read-only annotation, the description omits guidance on the response structure beyond 'details including Kafka settings'. With no output schema, the description should ideally clarify what fields or information are returned. The description is adequate but not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% since configGroupNo is described as 'Config group number'. The description does not add further meaning, such as format or where to obtain the value, but the baseline of 3 is appropriate given full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets Config Group details, using the specific verb 'Get' and identifying the resource. The addition of 'including Kafka settings' distinguishes it from the sibling tool ncloud_cdss_get_kafka_config, which focuses specifically on Kafka configuration.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving details of a specific config group, but it does not explicitly state when to choose this over alternatives like ncloud_cdss_list_config_groups or ncloud_cdss_get_kafka_config. No when-not or alternative tool references are provided, though the context suggests it's for full config group details.

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

• ncloud_cdss_restart_all_servicesA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false. The description adds valuable context by listing the affected components (Kafka, ZooKeeper, CMAK), which is not conveyed by the annotations alone. However, it does not disclose operational impact such as potential downtime or whether the restart is all-at-once versus rolling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that conveys the essential information without any filler. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description provides the core functionality. However, given the presence of sibling tools like ncloud_cdss_rolling_restart and ncloud_cdss_restart_kafka_per_node, some guidance on when to use this full restart versus those alternatives would complete the picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% because the single parameter 'serviceGroupInstanceNo' has a description ('Cluster instance number'). The description does not add any additional parameter semantics, but the schema already sufficiently documents this parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Restart'), the scope ('all services'), and the specific components ('Kafka + ZooKeeper + CMAK') in a CDSS cluster. This differentiates it from sibling tools like ncloud_cdss_restart_kafka and ncloud_cdss_restart_cmak, which target individual services.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide explicit guidance on when to use this tool versus alternatives. It does not mention why one would choose this over the rolling restart or per-node restart tools, nor does it state any prerequisites or exclusions.

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

• ncloud_cdss_rolling_restartA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, providing a safety baseline. The description adds the behavioral scope of 'rolling restart of all nodes' but does not disclose potential service disruption, async execution, or whether the operation requires a maintenance window. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that immediately conveys the operation and scope. It is front-loaded and contains no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate for a simple one-parameter operation, but it omits important context such as whether the API call is asynchronous, whether a precheck is recommended, or how to monitor the restart via related status tools. This leaves gaps for an AI agent planning a restart workflow.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the single parameter serviceGroupInstanceNo with the description 'Cluster instance number', so schema coverage is 100%. The tool description adds no further parameter-level explanation, leaving the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Perform' and clearly identifies the resource: 'a rolling restart of all nodes in a CDSS cluster'. It distinguishes from sibling tools like ncloud_cdss_restart_all_services and ncloud_cdss_restart_kafka by specifying 'rolling' and 'all nodes'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for rolling restarts but does not explicitly state when to choose this tool over alternatives, nor does it mention exclusions or prerequisites. Sibling tools such as ncloud_cdss_rolling_restart_precheck and ncloud_cdss_rolling_restart_status are not referenced.

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

• ncloud_create_cache_config_groupA
  3.7/5.0
  Behavior3/5

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

  The description adds context about the dryRun behavior, which is useful beyond the annotations' destructiveHint: false. It does not disclose other behavioral traits such as response format or side effects, but given the simple create operation and the annotation covering safety, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the primary purpose, and every word adds value. No fluff or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (4 params, no nested objects), but there is no output schema and the description does not mention what the tool returns or any post-create effects. This leaves a minor gap in completeness, but it is not critical for a basic create operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% parameter descriptions, so the description does not need to explain parameters. It mentions dryRun, but the schema already documents that, so no additional semantic value is added.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create') and resource ('Cloud Cache config group'), making it immediately clear what the tool does. It also distinguishes itself from sibling tools like ncloud_cdss_create_config_group and ncloud_delete_cache_config_group by naming the exact resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (to create a config group) and provides a useful hint about dryRun for previewing. However, it does not explicitly state when to choose this over alternatives or mention any prerequisites or exclusions, so guidance is only implied.

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

• ncloud_create_integrationA
  3.7/5.0
  Behavior3/5

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

  The description adds the behavioral detail that the integration is an 'outgoing webhook', clarifying the type of resource being created. However, it does not disclose side effects, validation rules, or response behavior beyond what the annotation (destructiveHint=false) already covers.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action word 'Create' and contains no unnecessary words. It is efficient and easily parsed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the description clearly states the purpose, it does not mention expected return values (no output schema), prerequisites, or post-creation behavior. For a tool with five parameters and no output schema, the description is minimal but the schema covers parameter details, making it adequate though sparse.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all five parameters (100% coverage), including the 'type' field with a default of 'OUT_GOING'. The description's phrase 'outgoing webhook' aligns with schema content but adds no additional parameter meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create a new Cloud Insight integration') and identifies the resource type with the clarifying phrase 'outgoing webhook'. This distinguishes it from sibling integration operations like update, delete, or list, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied by the verb 'Create' and the integration lifecycle (siblings include update and delete), but there is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or conditions stated.

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

• ncloud_create_nas_snapshotA
  3.7/5.0
  Behavior3/5

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

  Annotations only provide destructiveHint=false, and the description is consistent with this by indicating a create operation. The description adds the dryRun preview capability, which is useful behavioral context, but it does not disclose details like whether the operation is synchronous, requires specific permissions, or what happens upon success. With limited annotations, the description only partially compensates.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two short sentences that state the core purpose and a key usage tip. There is no wasted wording, and the most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 4 parameters, no output schema, and minimal annotations. The description covers the basic purpose and the dryRun option but does not mention the return value, prerequisites such as the NAS volume existing, or any side effects. Given the simplicity of the operation, it is adequate but leaves clear gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are already documented. The description's mention of dryRun=true is redundant with the schema's description of the dryRun parameter. No additional parameter semantics are provided beyond what the schema already offers, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Create' and the resource 'snapshot for a NAS volume instance', which is specific and distinguishes this from sibling tools like delete_nas_snapshot, list_nas_snapshots, and restore_nas_volume_with_snapshot. The scope is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a practical usage tip ('Use dryRun=true to preview') but does not explicitly state when to use this tool versus alternatives or mention any exclusions. The context is implied by the tool's name and description, but there is no comparison with other similar tools.

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

• ncloud_create_network_interfaceA
  3.7/5.0
  Behavior3/5

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

  The annotation destructiveHint=false is supplemented by the description's mention of dryRun=true for previewing, which adds useful behavioral context. However, the description does not disclose other behaviors such as side effects, potential failures, or the async nature of creation, leaving some burden unmet.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise—two short sentences that state the action and the key preview option. There is zero redundant information, and the most important detail (creation) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is minimal but the schema is rich, covering all parameters. However, it lacks context about when to use this tool in a broader workflow (e.g., required resources like VPC/Subnet), how it relates to other NIC operations, or what to expect after creation, making it only moderately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with every parameter already having a clear description. The tool description adds no additional parameter-level meaning beyond what the schema provides, so it stays at the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create a new network interface') with a specific verb and resource. It is distinct from sibling tools like delete_network_interface, list_network_interfaces, and attach_network_interface, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through the verb 'Create', but does not explicitly state when to use this tool versus alternatives or any prerequisites. The only guidance is the dryRun hint, which is a preview feature but not a full usage guideline.

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

• ncloud_create_postgresql_instanceA
  3.7/5.0
  Behavior3/5

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

  The annotation only includes destructiveHint=false. The description adds the dryRun preview behavior, which is helpful and not redundant with annotations. However, it does not disclose other behavioral traits such as required permissions, cost implications, or that certain settings (e.g., storage encryption) are immutable after creation—these are only in schema descriptions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exactly two sentences, with no wasted words. It front-loads the core purpose and adds the dryRun tip efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 24-parameter schema with 100% coverage, the description doesn't need to repeat parameter details. However, it lacks high-level context about dependencies (e.g., secondarySubnetNo when isMultiZone is true) or return values, and there is no output schema. The description is minimal but adequate when combined with the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 only mentions dryRun, which is already fully described in the schema ('If true, returns a preview without actually creating the instance'), adding no new semantic value for parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Create a new Cloud DB for PostgreSQL instance' with a specific verb and resource, clearly distinguishing this creation action from sibling tools like create_read_replica or delete. The dryRun mention adds further clarity about its behavior.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The only usage guidance is 'Use dryRun=true to preview without creating,' which provides a useful preview option. However, it does not explain when to use this tool versus alternatives (e.g., creating a read replica) or specify exclusion criteria. The 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.

• ncloud_create_vpc_peeringA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=false, so the description does not need to restate that this is a non-destructive operation. It adds the dryRun behavior, which is useful, but does not disclose other behavioral aspects like the need for the peering to be accepted by the target VPC, or that cross-account peering requires additional parameters. This is moderate additional context 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loads the primary purpose, and provides a practical tip in the second sentence. Every word earns its place; no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With seven parameters, no output schema, and minimal annotations, the description is somewhat sparse. It does not mention cross-account peering prerequisites (though the schema does) or the acceptance workflow involving accept_reject_vpc_peering. The schema covers parameter meanings, but the description leaves out operational context needed for correct invocation in more complex scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 seven parameters. The description only mentions dryRun, which is already described in the schema ('If true, returns a preview without actually creating the resource'), so it adds little semantic value beyond the structured field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Create a new VPC Peering connection between two VPCs.' It uses a specific verb with a specific resource and differentiates from sibling tools like list_vpc_peerings, get_vpc_peering_detail, accept_reject_vpc_peering, etc.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a concrete usage tip for dryRun ('Use dryRun=true to preview without creating') but does not clarify when to use this tool versus related alternatives such as accept_reject_vpc_peering. There is no explicit 'when to use' or 'when not to use' guidance, so the context is only implied.

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

• ncloud_drm_create_siteA
  3.7/5.0
  Behavior3/5

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

  Annotations only declare destructiveHint: false, and the description adds that the tool 'binds a DRM policy' and 'optionally registers a FairPlay certificate', which is useful context beyond the schema. However, it does not disclose potential side effects, prerequisites (e.g., whether the policy must exist), or what happens on failure. Given the sparse annotations, the description partially carries the burden but could be more transparent about the operation's effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single efficiently structured sentence: 'Create a new DRM site (binds a DRM policy; optionally registers a FairPlay certificate)'. It is front-loaded with the action and resource, and every word contributes meaning. No unnecessary content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 3 parameters, no output schema, and only the destructiveHint annotation, the description covers the core action but lacks details such as expected response, prerequisites for the policy or certificate, and any special constraints beyond what the schema states. It is adequate for a simple create operation but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: policyId, siteName, and fairPlayCert each have descriptions. The description adds minimal high-level context by linking policyId to 'binds a DRM policy' and fairPlayCert to 'optionally registers', but this does not go beyond what the schema already implies (fairPlayCert is not required). Per the baseline for high schema coverage, a score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Create a new DRM site', a specific verb+resource combination that distinguishes it from sibling tools like ncloud_drm_update_site, ncloud_drm_enable_site, and ncloud_drm_disable_site. The parenthetical adds concrete detail about binding a DRM policy and optionally registering a FairPlay certificate, which further clarifies the tool's scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is for creating new sites, but it does not explicitly state when to use it versus the update/enable/disable alternatives. No exclusions or alternative tool references are provided. The purpose is clear from the name, but usage guidance is only implied, not explicit.

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

• ncloud_drm_enable_siteA
  3.7/5.0
  Behavior3/5

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

  Annotations provide idempotentHint=true and destructiveHint=false, already covering the safety profile. The description adds minimal extra context ('activate' as a synonym) but no additional behavioral details such as effects on site status or logs. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no redundant wording. Every word contributes to conveying the action and object.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple state-change action with one parameter and helpful annotations, the description is adequate but not richly detailed. It omits return value expectations or preconditions, but given the tool's simplicity and annotation coverage, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (siteId with 'Site ID to enable'), so the description does not need to explain parameters. The tool description adds no further semantic value beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Enable (activate)' with a clear resource 'DRM site', immediately conveying the tool's function. It distinguishes itself from sibling tools like ncloud_drm_disable_site and ncloud_drm_update_site by its focus on activation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (enable a DRM site) but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or conditions. It is not misleading, but lacks explicit context.

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

• ncloud_execute_policyA
  3.7/5.0
  Behavior2/5

  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 not mention side effects (e.g., immediate capacity changes), prerequisites (e.g., that the policy must exist), idempotency, or whether the operation is asynchronous. This is a significant gap for a state-changing action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that immediately conveys the action and target. No filler or redundant information, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple tool with two fully described parameters, and the description adequately states what it does. However, without an output schema or annotations, it lacks details about the expected result, potential errors, or post-execution behavior, leaving some context gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides descriptions for both parameters (policyName and autoScalingGroupNo), covering 100% of the schema. The tool description adds no additional parameter-level meaning beyond what the schema offers, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'execute' and the resource 'scaling policy' for an Auto Scaling Group, distinguishing it from sibling tools like list, put, and delete scaling policies. The inclusion of 'manually' further clarifies the action's nature.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Manually execute' gives clear context for when this tool is appropriate – triggering a policy by hand rather than relying on automatic scaling. However, it does not explicitly mention alternatives or when not to use it, leaving some room for interpretation.

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

• ncloud_functions_get_actionA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, covering the read-only nature. The description adds that the response includes source code, which is valuable context beyond annotations. However, it does not describe the return structure, pagination, or any other behavioral traits, so it only partially enhances transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It conveys the tool's purpose and key output detail ('including source code') efficiently, making every word earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, so the description carries the burden of explaining return values. 'Detailed information' is vague, and only the inclusion of source code is specified. The description also does not mention that both packageName and actionName are needed to identify the action, though the schema requires them. Overall, it is minimally complete but has clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all three parameters (platform, actionName, packageName). The description does not reference parameters or add any meaning beyond what the schema already documents, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Get[s] detailed information about a specific action including source code', using a specific verb and resource. It distinguishes itself from list_actions (which would not return a single action's source code) and other get_* siblings by emphasizing 'specific action' and 'source code'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for retrieving detailed information about one specific action, but it does not explicitly state when to use it versus alternatives like list_actions, nor does it mention exclusions or prerequisites. The usage context is implied rather than explicitly guided.

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

• ncloud_get_block_storage_volume_typesA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the safe read-only nature is known. The description adds the region-scoped context, which is useful, but it does not disclose any additional behavior like pagination, default region behavior, or response structure. With annotations covering safety, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise, front-loaded sentence that clearly states what the tool does. Every word contributes value and there is no redundancy or extraneous content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one optional parameter and no output schema. The description conveys the primary purpose but does not clarify what happens when regionCode is omitted, whether a default region is used, or what the returned list items look like. Without an output schema, these gaps leave some ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 the single regionCode parameter with its format (KR, KRS). The description's mention of 'in the region' loosely aligns with the parameter but does not add new information beyond the schema, hence the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('list of block storage volume types') with a clear scope ('available in the region'). It is easily distinguishable from sibling tools, which focus on managing actual block storage volumes rather than querying type metadata.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'available in the region' implies usage for checking regional availability, but there is no explicit statement about when to use this tool versus alternatives or any exclusions. Since no similar sibling tool exists, the ambiguity is low, but guidance is still implied rather than stated.

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

• ncloud_get_cache_instance_detailA
  3.7/5.0
  Behavior3/5

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

  Annotations include readOnlyHint: true, which already declares the operation is read-only. The description adds context about the resource type (Redis/Valkey) but does not disclose other behavioral traits such as required permissions, response structure, or potential errors. Since annotations cover the safety profile, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no extraneous content. It efficiently communicates the essential purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one well-described parameter, read-only annotation), and the description is sufficient for basic invocation. However, with no output schema, the description doesn't explain what 'detailed information' will be returned or any prerequisites, leaving some context gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one parameter (cloudCacheInstanceNo) with a description 'Cloud Cache instance number to query', covering 100% of the schema. The tool description does not add additional meaning beyond this, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Get detailed information') on a specific resource ('a specific Cloud DB for Cache (Redis/Valkey) instance'). It distinguishes itself from sibling tools like ncloud_list_cache_instances (which lists all instances) and other get_*_instance_detail tools by specifying the cache product type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when you have a specific instance number and need details, but it does not explicitly state when to use this versus alternatives, nor does it mention exclusions. For example, it doesn't say to use list_cache_instances for a broad overview or to consult other detail tools for other database types.

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

• ncloud_get_maintenance_detailA
  3.7/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true, so the description does not need to restate safety. The description adds minimal behavioral context, only that it returns 'detailed information' without specifying what that includes. It does not contradict 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It clearly and efficiently communicates the core purpose of the tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter and a read-only annotation, but there is no output schema. The description is vague about what 'detailed information' includes and does not mention how to obtain the maintenanceId. It is adequate for a basic retrieval but leaves room for more context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the single parameter maintenanceId with the description 'Planned maintenance ID'. Since schema description coverage is 100%, the description adds no additional meaning beyond what the schema already provides, resulting in the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get detailed information about a specific planned maintenance schedule.' It uses a specific verb ('get') and resource ('planned maintenance schedule'), and the word 'specific' distinguishes it from list operations like ncloud_list_maintenances.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives. It does not mention that maintenanceId should be obtained from ncloud_list_maintenances or that this is the detail counterpart to list. No exclusions or alternative recommendations are provided.

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

• ncloud_get_member_server_image_detailA
  3.7/5.0
  Behavior3/5

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

  The readOnlyHint annotation already discloses the safe read-only nature, and the description is consistent with it. However, beyond that, the description adds little behavioral context: it does not describe what specific details are returned, any error conditions, or other traits. The annotation lowers the bar, but the description still offers minimal additional value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the tool's purpose. It contains no filler or redundant information, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only detail-getter with one parameter, the description is adequate but lacks an indication of what fields make up the 'detailed information'. Since there is no output schema, the agent is left guessing what will be returned. This prevents the description from being fully complete, though the simplicity of the tool means it is minimally viable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the parameter fully with the description 'Member server image instance number to query', and the tool description adds no extra semantic detail about the parameter. Since schema coverage is 100%, the baseline is 3, and the description does not go beyond that.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get detailed information') and the resource ('member server image instance'), making it easy to distinguish from list-type tools like ncloud_get_member_server_image_list and from the related ncloud_get_server_image_detail. The verb and object are 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (when you need details for a specific member server image instance, given you have its instance number), but it does not explicitly state when to use it versus alternatives. There is no mention of prerequisites or situations where another tool would be more appropriate, so it remains at the level of implied usage.

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

• ncloud_get_mongodb_target_subnetsA
  3.7/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, and the description's 'List' verb is consistent with that, so there is no contradiction. However, the description adds minimal extra behavior detail beyond the annotation; it does not mention pagination, response format, or instance filtering behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no filler or redundant wording. It is front-loaded with the action and resource, making it easy for an agent to quickly grasp the tool's function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple, with one required parameter, and the schema covers parameter semantics. However, there is no output schema, and the description does not indicate what a successful response contains (e.g., a list of subnet objects with IDs) or that results are scoped to the given MongoDB instance. It is minimally adequate but lacks richer contextual details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for both parameters (regionCode and cloudMongoDbInstanceNo), giving 100% coverage. The description adds no additional meaning about parameter usage or relationships, so it is at the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and the resource ('subnets available for Cloud DB for MongoDB'), which makes the tool's purpose unmistakable. It also distinguishes itself from sibling tools like ncloud_get_mongodb_target_vpcs and other database-specific target subnet tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives such as ncloud_get_mongodb_target_vpcs or the generic ncloud_list_subnets. The usage is implied by the name and description, but no exclusions or alternative references are given.

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

• ncloud_get_operation_statusA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description aligns with a read-only 'Check' operation. The description adds context about being for recently created/modified resources, but it does not disclose what kinds of statuses are returned (e.g., in-progress, success, failure) or whether it should be polled. Since annotations cover the safety profile, the description meets the minimum bar without adding extra behavioral detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states the essential purpose without any filler. Every word earns its place, making it highly efficient and easily parsed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only 2 parameters, a read-only annotation, and no output schema, the description conveys enough to understand the tool's basic function. However, it lacks any indication of what the response contains (e.g., status enum, progress indicator), which would be helpful since there is no output schema. The description is adequate but not fully complete for an agent that might need to interpret the result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides clear descriptions for both parameters (resourceId and resourceType), with 100% schema coverage. The description adds general context about the resource being recently created/modified but does not provide additional param-specific meaning beyond what the schema already documents. This aligns with the baseline 3 for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Check'), the resource scope ('current status of a recently created or modified resource'), and the required identifiers ('by type and ID'). It distinguishes itself from sibling get_*_detail tools by focusing on the operation status of recent changes rather than the resource's full configuration.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'recently created or modified' implies the tool should be used after create/update operations to monitor progress, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusion conditions. Usage 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.

• ncloud_get_product_discount_history_listA
  3.7/5.0
  Behavior3/5

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

  The readOnlyHint annotation already communicates that this is a safe read operation, lowering the bar. The description adds useful return context (discount details, per-service amounts) but does not disclose pagination behavior, default scope when no params are provided, or any special authorization requirements. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action, and every word adds value. It states the resource and then enumerates the key return fields without waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 8 optional parameters, no output schema, and no required params, the description gives a high-level return overview but leaves filtering/pagination context to the schema. It does not mention that all params are optional or how to scope the query by month/discount, which would help an agent. Adequate but with clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all 8 parameters individually described (e.g., pageNo, startMonth format). The description does not add parameter-specific semantics beyond the schema, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('product discount history list'), and specifies return contents (discount rate, eligible services, per-service usage/applied amounts). This clearly distinguishes it from sibling tools like ncloud_get_discount_list, which likely returns current discount information.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use guidance or alternatives are provided. Usage is implied by the verb 'get' and the resource name, but the description does not contrast with related tools such as ncloud_get_discount_list or ncloud_get_product_demand_cost_by_discount_list. This is adequate but not explicit.

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

• ncloud_get_vpc_detailA
  3.7/5.0
  Behavior2/5

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

  The description adds no behavioral detail beyond the readOnlyHint annotation. It does not state what fields are returned, whether authentication is needed, or any side effects. Since the annotation already declares read-only, the description offers no additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, front-loaded with the action, zero unnecessary words. Perfectly concise for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the tool is simple, the description lacks detail about what 'detailed information' includes (e.g., CIDR, status, name). With no output schema, the description should clarify the return value, but it remains vague. Adequate for a straightforward get-by-ID tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents vpcNo with a clear description, so the baseline is 3. The description adds no extra parameter semantics, but the schema coverage is 100%.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('VPC'), clearly indicating a read operation for a single VPC. It distinguishes from sibling tools like ncloud_list_vpcs by emphasizing 'specific'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies usage when a specific VPC needs to be examined, but does not explicitly mention alternatives like ncloud_list_vpcs for listing all VPCs or note when not to use it. Context is clear but exclusions are absent.

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

• ncloud_hadoop_list_objectsA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description's 'List' wording is consistent. The description adds minimal behavioral context beyond the annotation—it does not mention pagination, return format, whether directoryName is required for listing, or how the Hadoop instance linkage affects results. With annotations present, this meets the baseline but does not exceed it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. Every element ('List', 'objects', 'Object Storage bucket', 'linked to Cloud Hadoop') contributes to the core meaning, making it an appropriately sized and well-structured description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (1 required param, no output schema, readOnly annotation), the description plus schema covers the basics. However, it does not disclose the response shape (since no output schema exists) or clarify that bucketName/directoryName are optional filters and how they interact with the required cloudHadoopInstanceNo. It is minimally viable but leaves gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all four parameters are already documented in the schema. The tool description adds no parameter-level semantics beyond what the schema provides, which lands at the baseline of 3 per the rubric.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 precise resource ('objects in Object Storage bucket') and a distinguishing scope ('linked to Cloud Hadoop'). It clearly differentiates from siblings like ncloud_list_objects (generic Object Storage listing) and ncloud_hadoop_list_buckets (lists buckets, not objects).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'linked to Cloud Hadoop' implies when this tool is appropriate, but there is no explicit guidance on when to prefer this over ncloud_list_objects or other sibling tools, nor any exclusions stated. The usage context is inferable but not directly documented.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_encryptA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true annotation, the description adds value by noting size limits and key type support. However, it does not disclose the return format (e.g., ciphertext) or note that encryption may produce non-deterministic results, which would be useful behavioral context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the verb 'Encrypt', and every word contributes. No redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with full schema coverage and an annotation, the description is adequate but incomplete: it does not mention that the output is ciphertext or clarify the role of the 'context' parameter for convergent encryption. Since there is no output schema, some return-value information would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% description coverage for all three parameters (keyTag, context, plaintext). The tool description adds no additional parameter meaning beyond what the schema already states, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Encrypt data), the resource (KMS key), and includes specific constraints (up to 32KB, current key version, AES256/RSA2048). This distinguishes it from sibling tools like decrypt or sign.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for encryption and provides important constraints (size, key types), but it does not explicitly mention when to use this tool over alternatives like ncloud_kms_decrypt or ncloud_kms_sign. It lacks explicit exclusions or alternative references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_rotate_keyA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are empty, so the description must disclose behavior. It does state the primary effect (creating a new version) and a precondition (enabled key), but omits important details like whether old versions remain usable, permission requirements, or reversibility—leaving some behavioral ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence conveys the action, outcome, and a condition with no unnecessary words. It is front-loaded with the verb and immediately clarifies the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutating KMS operation with no output schema and empty annotations, the description is somewhat minimal. It does not explain side effects on existing key versions, required permissions, or how it relates to automatic rotation, leaving gaps for an agent deciding to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the sole parameter (keyTag) with coverage at 100%, so the description adds no additional parameter semantics. Baseline of 3 applies since the schema already handles parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb and resource: 'Rotate an active key to create a new version.' It specifies the outcome (new version) and distinguishes this from sibling operations like ncloud_kms_enable_auto_rotation, emphasizing manual key rotation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a condition ('Only enabled keys can be rotated') but no explicit guidance on when to use manual rotation versus automatic rotation or other key-management alternatives. It implies context but lacks exclusions or comparisons.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_verifyA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds behavioral context beyond this: it specifies that only RSA2048 or ECDSA key types are supported, warning that other key types will fail. This is useful operational knowledge not present in the annotations. It does not contradict the read-only hint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise—two short sentences. The action is front-loaded ('Verify a digital signature'), and the key type constraint is stated in a single additional sentence. No wasted words or redundancy with the schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a verification tool with no output schema, the description does not disclose the return value or behavior on signature mismatch (e.g., does it return false or throw an error?). This is important for an agent to interpret the result correctly. The key type limitation is covered, but the outcome semantics are missing, leaving a gap in completeness for a simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all three parameters ('data', 'keyTag', 'signature'), so the schema already explains each parameter. The description adds minimal parameter-level meaning, only implicitly linking 'data' and 'signature' via the verb 'verify'. This meets the baseline for fully documented schema parameters but does not exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Verify a digital signature against data' with a specific verb (verify) and resource (digital signature/data). It distinguishes from sibling tools like ncloud_kms_sign, encrypt, or decrypt by focusing on verification. The added constraint 'Only RSA2048 or ECDSA key types supported' further clarifies scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives is provided. The description merely states what it does and a key type limitation, but does not mention scenarios such as 'use to confirm authenticity of signed data' or exclude cases where another KMS operation might be more appropriate. The sibling ncloud_kms_sign is not referenced, leaving the agent to infer the relationship.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_asg_activity_logsA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true already in annotations, the description adds the scoping constraint 'scaling actions', clarifying what kind of logs are returned. It does not disclose additional behaviors such as pagination limits, event retention window, or any authentication prerequisites, but the annotation covers the safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence with 10 words, front-loaded with 'List activity logs'. It contains no irrelevant details and is optimally concise for a straightforward list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, but since there is no output schema, the description does not explain what the returned log entries contain (e.g., fields, timestamps). It also omits any default pagination behavior or time range. The essential scope is clear, but for a tool returning data, a bit more detail would make it comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema documents all three parameters with descriptions (100% coverage), including 'Page number for pagination', 'Page size for pagination', and 'Auto Scaling Group number'. The description adds no further parameter meaning, so it relies on the schema – meeting the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 'activity logs (scaling actions) for an Auto Scaling Group'. It precisely differentiates this from general activity log tools (like ncloud_get_activity_logs) and other ASG management operations by specifying the log scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied: use when you need scaling actions for an ASG. However, there is no explicit guidance on when not to use it, nor any mention of alternative tools like ncloud_get_activity_logs or ncloud_list_scaling_policies. The description neither names alternatives nor provides exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_ddos_eventsA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already indicates a safe read operation. The description adds the subscription requirement, which is useful context. However, it does not disclose other behavioral traits such as pagination limits, time range constraints, or return format. With annotations covering the safety profile, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that efficiently conveys the tool's purpose and a key prerequisite. Every part is useful, with no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema is rich with parameter descriptions, and the annotation confirms read-only behavior. However, there is no output schema and the description does not mention the return structure or which parameters are most relevant for filtering. This is adequate but not complete for a tool with 9 parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for 100% of parameters, including units (Unix epoch milliseconds) and defaults. The description adds no additional parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate because the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'List Anti-DDoS security events from Security Monitoring.' This clearly distinguishes it from other security event list tools like ncloud_list_av_events or ncloud_list_waf_events by explicitly naming the event type and source service.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear prerequisite ('Only for users subscribed to the Security Monitoring service') but does not explicitly mention alternatives or when not to use this tool. The usage is implied through the tool name and event type rather than explicitly contrasting with sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_mysql_databasesA
  3.7/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation, and the description adds no further behavioral details such as pagination behavior, response structure, or instance-existence requirements. It only restates the action without going beyond the structured information.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of nine words, with no filler or redundancy. It is front-loaded and immediately communicates the tool's operation and scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only list operation, the description sufficiently states what is listed and for which resource. The absence of an output schema is acceptable because 'List databases' clearly implies a list of database entries, and no additional complexity warrants further elaboration.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the single parameter cloudMysqlInstanceNo as 'Cloud MySQL instance number', and the tool description does not add any additional semantic meaning. Since schema coverage is 100%, the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and identifies the resource as 'databases' scoped to 'a Cloud DB for MySQL instance', clearly distinguishing it from sibling tools like ncloud_list_mysql_users and ncloud_list_mysql_instances. This leaves no ambiguity about the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this tool enumerates the databases of a specific MySQL instance, but it does not explicitly state when to use it versus related list tools or mention any exclusions. Usage is implied rather than directly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_mysql_instancesA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe, read-only operation. The description 'List' is consistent with this and adds context that it covers all MySQL instances in the current region. However, it does not disclose additional behavioral traits such as pagination behavior (despite pageNo/pageSize parameters), what the response contains, or whether filters are optional. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that front-loads the action ('List all') and resource. Every word earns its place; there is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with optional filters and no output schema, the description covers the core purpose. However, it lacks guidance on return value structure, pagination behavior, or related tools (e.g., for instance details or other database types). Given the large sibling set, a bit more context would make it complete, but complexity is low, so a score of 3 is appropriate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all four parameters, so the baseline is 3. The description adds no extra parameter-level meaning; it simply states 'List all,' which could imply no filtering, though the optional filter parameters are documented in the schema. This is not contradictory but also not additive.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' with a clear resource ('Cloud DB for MySQL instances') and scope ('in the current region'). This clearly distinguishes it from sibling tools like ncloud_get_mysql_instance_detail (which retrieves a single instance) and ncloud_list_mysql_databases (which lists databases, not instances).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  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 the tool (listing all MySQL instances in the current region) but does not explicitly mention alternatives or exclusion criteria. For instance, it does not say 'for a single instance, use get_mysql_instance_detail' or note that this is only for instances, not databases or users. Usage is implied rather than explicitly contrasted with siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_nas_volumesA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds the 'current region' scoping constraint, which is useful. However, it does not disclose pagination behavior or return format, and the phrase 'all' is ambiguous given the pagination parameters in the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that delivers the essential purpose without fluff. It is front-loaded with the action and resource, making it quickly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with no output schema, the description gives the core purpose but omits details about pagination, default region behavior, or response structure. The pagination params suggest possible pagination, but the description says 'all,' leaving ambiguity. The presence of related sibling tools and no output schema make this minimally adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (pageNo, pageSize, zoneCode, regionCode, etc.) having a clear description. The tool description adds no additional parameter semantics, but the schema already provides adequate information, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('NAS volume instances') with a clear scope ('in the current region'). It unambiguously distinguishes this tool from siblings like ncloud_get_nas_volume_detail (singular detail) and ncloud_list_nas_snapshots (different resource type).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for listing NAS volumes but does not explicitly contrast it with alternatives or state when to prefer it over ncloud_get_nas_volume_detail or other listing tools. It provides clear context (current region) but no exclusions or alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_placement_groupsA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation, and the description adds the region-scoping behavior. It does not mention pagination, response contents, or filtering semantics beyond 'all,' but for a read-only listing this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that is easy to scan and free of fluff. It loses a point for not including any usage hints or caveats, but it remains appropriately concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, read-only list tool with fully documented optional filters and a readOnlyHint annotation, the description covers the core behavior sufficiently. No output schema exists, but the tool is low-complexity and the description is adequate for selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema with 100% coverage, so the description adds no extra semantic value beyond naming the filters. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('List'), a clear resource ('placement groups'), and scope ('current region'), making it easy to distinguish from sibling tools like get_placement_group_detail or create_placement_group.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for retrieving placement groups but provides no explicit guidance on when to choose this over get_placement_group_detail or how the optional filters should be applied. It relies on the tool name and schema to convey the listing role.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_postgresql_instancesA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description does not need to restate that. It adds the 'current region' scoping, which is useful. However, it does not disclose behavior such as pagination limits, default page size, or what fields are returned in the response (no output schema is provided).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence (11 words) that is front-loaded with the verb and resource. Every word contributes, with no fluff or repetition of schema information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 4 optional parameters and no output schema, but the description only covers purpose and region. It does not mention pagination parameters, filter options, or the shape of the returned list. For a list tool this is minimally adequate but leaves gaps for an agent to discover via schema and API knowledge.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 meaning beyond the schema; it says 'all' which may imply no filtering, but the optional filter parameters are not mentioned. It neither contradicts nor enriches the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List'), resource ('Cloud DB for PostgreSQL instances'), and scope ('in the current region'). This distinguishes it from sibling tools like ncloud_get_postgresql_instance_detail (single instance detail) and ncloud_create_postgresql_instance (creation).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when you need all PostgreSQL instances in the current region, but provides no explicit guidance on when to choose this over alternatives, nor does it mention pagination or filtering capabilities. The availability of get_postgresql_instance_detail suggests a distinction, but it is not stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_targetsA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the safety profile is already clear. The description adds the scoping phrase 'in a specific target group' but does not disclose additional behavioral details like return format, pagination, or whether the results include health status. It provides only minimal context 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence: 'List all targets in a specific target group'. It contains no filler, redundancy, or unnecessary detail, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with one parameter and a read-only annotation, the description is adequate but incomplete. It does not describe what the returned targets will contain (e.g., IDs, IPs, health status) or any pagination/limits. Since there is no output schema, the description should provide more detail about the return values, but it leaves this unspecified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage, the schema already documents targetGroupNo as 'Target group number'. The description does not add extra semantic details beyond referencing 'a specific target group', so it matches the schema without adding new meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all targets in a specific target group' clearly states the verb (list), resource (targets), and scope (specific target group). This distinguishes it from sibling tools like ncloud_list_target_groups (which lists the groups themselves) and ncloud_get_target_group_detail (which retrieves details of a single group).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when one needs to enumerate targets within a known target group, but it provides no explicit guidance on when to use this tool versus alternatives such as ncloud_list_target_groups or ncloud_get_target_group_detail. There are no exclusions or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ncr_list_imagesA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description aligns with the readOnlyHint annotation (list is a read operation) and adds the scope of 'specified registry.' However, it doesn't disclose pagination behavior or the response format, and the word 'all' could be misleading given page/pageSize parameters.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single 10-word sentence, front-loaded with the verb and resource. It is concise and contains no filler, while still conveying the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with full schema coverage and a read-only annotation, the description is mostly adequate. However, it omits details about pagination and return values, which is notable because there is no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with each parameter described (page, pageSize, registryName). The description adds no extra parameter meaning beyond naming the registry, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and identifies the resource as 'container images' with the scope 'in a specified registry,' clearly distinguishing it from siblings like ncloud_ncr_list_registries and ncloud_ncr_get_image.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternative guidance is provided. The usage is implied by the tool name and description, but it doesn't tell the agent when to prefer this over similar listing tools like ncloud_ncr_list_tags or ncloud_ncr_list_registries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_get_clusterA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation, and the description is consistent with that. However, the description adds no extra behavioral context such as what fields are returned, whether the response is paginated, or any caveats. It does not contradict the annotation but also provides minimal added value beyond it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, short sentence that directly states the tool's purpose without any redundant or irrelevant information. It is extremely concise and front-loaded, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-ID tool with one parameter and a readOnly annotation, the description is adequate but not rich. It does not specify what 'detailed information' includes (e.g., status, node pools, network config), which would be helpful since there is no output schema. Still, the tool's simplicity and annotations reduce the need for extensive elaboration.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% description coverage for the single parameter clusterUuid, which is clearly documented as 'UUID of the cluster to query'. The tool description does not add any additional parameter meaning or usage nuance, so the schema carries the full burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' and clearly identifies the resource as 'a specific NKS cluster', distinguishing it from list operations like ncloud_nks_list_clusters. The inclusion of 'specific' aligns with the required clusterUuid parameter, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is used when a specific cluster UUID is already known, but it does not explicitly state when to use this over alternatives like list_clusters, nor does it mention any prerequisites or exclusions. Guidance is only implied by the wording and the required parameter.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pca_get_end_certA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already indicates a safe read operation; the description adds the selection criterion (by serial number) which is consistent. However, no additional context is provided about error cases, response details, or the need to specify a CA tag.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One concise sentence that clearly communicates the tool's function with no unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only getter with two documented parameters and no output schema, the description is adequate but does not mention the required CA context or how to obtain the serial number, leaving some ambiguity for agents.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides full descriptions for both caTag and serialNo (100% coverage), so the description adds no extra parameter semantics beyond restating 'by serial number.' Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get detailed information'), the specific resource ('specific end-entity certificate'), and the lookup method ('by serial number'). It distinguishes this from the sibling 'ncloud_pca_list_end_certs' which lists certificates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a serial number is known, but it does not explicitly state when to use this tool versus listing certificates first or any alternatives. It lacks exclusions or hints such as 'use list_end_certs to find the serial number first.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pca_rotate_crlA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are empty, so the description carries the full burden for behavioral disclosure. It communicates the action (rotate) and the immediate effect (refresh with latest revocation info). However, it does not disclose potential side effects, permissions required, whether the operation is reversible, or what the response contains—though for a straightforward rotation action, this may be sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded with the action ('Manually rotate the CRL') and includes the purpose. There is no redundant or filler content; every word contributes.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter and no output schema. The description sufficiently explains the action but lacks context such as when this should be performed (e.g., after revoking certificates), any dependencies, or expected results. It is minimally complete but leaves room for additional guidance about usage scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% as the only parameter 'caTag' has a description ('CA tag value'). The tool description does not add additional meaning beyond the schema, and the schema description is somewhat vague ('CA tag value' does not clarify how to obtain or identify the tag). Baseline of 3 applies because coverage is high, even though the description adds little value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Manually rotate the CRL' and the purpose 'to refresh it with the latest revocation information.' This is a specific verb+resource combination that distinguishes it from sibling tools like ncloud_pca_get_ca_crl (retrieve) and ncloud_pca_update_crl_config (update configuration).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The word 'Manually' implies that rotation can also happen automatically, providing a subtle usage context. However, the description does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. Guidance is implied but not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pca_sign_end_csrA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint: true, so the safety profile is already known. The description adds one behavioral detail: 'The existing CA certificate is returned,' which is not present in annotations or schema. However, it does not clarify whether the signed certificate itself is also returned, nor any side effects (e.g., persistence). Given the annotation coverage, this is acceptable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, concise and front-loaded with the core action. Every word adds value: the verb, the target (CSR), the result (end-entity certificate), and the return value. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (2 params, no output schema) and the description covers the core purpose and one return value. However, it is incomplete regarding the full response: it says 'The existing CA certificate is returned' but does not explicitly state whether the newly signed end-entity certificate is also returned or in what format. Given no output schema, this leaves ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for both parameters: caTag ('CA tag value of the signing CA') and csrPem ('CSR in PEM format'). The description adds no additional parameter semantics, so it does not go beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Sign a provided CSR') and the purpose ('to issue a new end-entity certificate'). It also mentions the return value, which helps distinguish it from similar tools like ncloud_pca_sign_sub_csr (which signs a sub-CA CSR) and ncloud_pca_issue_end_cert. The verb+resource+result are specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: use this when you have a CSR to sign for an end-entity certificate. However, it does not explicitly mention when to use this tool versus alternatives such as ncloud_pca_sign_sub_csr or ncloud_pca_issue_end_cert, nor does it provide any exclusion criteria. The guidance is purely implied by the tool's purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_change_disk_sizeA
  3.7/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description does not provide any behavioral context beyond what the annotations already indicate (idempotentHint=true, destructiveHint=false). It does not mention potential downtime, prerequisites, or the fact that this is a mutating operation on a cluster. Since annotations only cover safety profile, the description adds little value here.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It directly states the verb and object, making it highly concise and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter tool with full schema documentation and safety annotations, the description is minimally sufficient. However, it lacks context about the operational impact (e.g., whether the cluster reboots or if there is any downtime), which would be valuable for an agent deciding to invoke it. There is no output schema to compensate, so the description alone does not fully cover the operational picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides complete coverage (100%) for both parameters, including type, range, and increment details for dataNodeStorageSize. The description does not add any extra semantic meaning beyond the schema, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Change') and the specific resource ('data node disk capacity') within a Search Engine Service cluster. It is sufficiently distinct from sibling tools like ncloud_ses_change_node_spec or ncloud_ses_add_node, which target different aspects of cluster configuration.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context of use is clear: this tool is for changing the disk capacity of data nodes in an SES cluster. However, it does not explicitly mention alternatives or exclusionary conditions, such as 'use this instead of change_node_spec when only disk size needs adjustment.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_create_cluster_g3A
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the dryRun preview behavior, which is beyond the minimal annotation (destructiveHint=false). However, it does not disclose other behavioral traits such as provisioning time, asynchronous execution, or response format. The sparse annotation means the description carries some but not full burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, with the primary action front-loaded and the dryRun tip in a separate sentence. Every word earns its place with no wasted content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex 20-parameter cluster creation tool with no output schema, this description is minimal. The schema is richly described, but the description lacks guidance on prerequisites, how to obtain codes, or what to expect after invocation. It is adequate but has clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 adds no parameter-specific details beyond the schema; the only mention of dryRun repeats the schema description, providing no additional value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Create' and names the resource 'Search Engine Service cluster' while adding the qualifier 'G3/KVM' to distinguish it from the generic ncloud_ses_create_cluster sibling. This clearly states what the tool does and differentiates it from alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description mentions 'Use dryRun=true to preview' as a usage hint, but it does not explicitly state when to use this tool over ncloud_ses_create_cluster or other cluster management tools. The G3/KVM qualifier implies a specific use case but does not name alternatives or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_get_serversA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds that it returns 'available servers' for stage configuration, but it does not disclose response format, pagination, or what determines availability. This is adequate for a simple list tool but lacks deeper behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It clearly states the action and target, making it highly concise and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no parameters and no output schema, the description is reasonably complete: it explains the tool's purpose and scope. However, it does not elaborate on what 'available servers' means or the structure of the returned list, which would be helpful for an agent planning to use the output.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is nothing for the description to explain. Per the baseline for 0 params, a score of 4 is appropriate since the description adds no parameter information but the schema is fully covered by the absence of parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Get the list of available servers for SourceDeploy stage configuration' with a specific verb and resource. It distinguishes itself from sibling tools by focusing on 'servers' rather than other resource types like autoscaling groups or K8s clusters, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The implied usage is for SourceDeploy stage configuration, but there is no explicit guidance on when to use this tool versus alternatives like ncloud_sourcedeploy_get_autoscaling_groups or ncloud_sourcedeploy_get_k8s_clusters. It lacks exclusion criteria or alternative tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_update_integrationA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint and destructiveHint, covering basic safety. The description adds no additional behavioral context, such as whether omitted optional fields (headers, type) are reset or if this is a full replacement. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that states the action and resource with no filler, redundancy, or wasted words. It is appropriately front-loaded and easily digestible.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a moderate-complexity tool with 6 parameters and no output schema, the description is adequate for basic tool selection but lacks important behavioral details like update semantics (full vs partial) and what the response contains. The schema and annotations fill some gaps, but the description alone is thin.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all six parameters are already documented in the schema. The description does not add any parameter semantics beyond what the schema provides, which is acceptable per the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Update') and resource ('existing Cloud Insight integration'), clearly distinguishing it from sibling tools like create/delete/list/get integration. It is concise and unambiguous about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied by the word 'existing' (suggesting the integration must already exist), but it does not explicitly state when to use this vs alternatives, nor provide prerequisites or exclusions. It relies on the agent to infer from the CRUD sibling set.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_update_metrics_groupA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare the tool as idempotent and non-destructive, and the description adds that it updates an existing resource, which is consistent. Yet it does not disclose update semantics such as whether metricList replaces existing metrics or merges, or any side effects of partial updates.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that immediately conveys the action and target resource, with no redundant or filler content. It is optimally concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a nested metricList parameter and no output schema, the description is somewhat sparse. It covers the basic operation but omits important context such as whether the update is partial or full, prerequisites like the resource existing, and what behavior to expect with the metric list.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 every parameter. The description adds no additional parameter context beyond what the schema provides, thus a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Update' with a clear resource, 'existing Cloud Insight rule template (metrics group)', which distinguishes it from create/delete/list tools in the sibling set. It also clarifies the terminology by equating 'rule template' with 'metrics group'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: use this tool to modify an existing metrics group as opposed to creating or deleting one. However, there is no explicit guidance on when to choose this tool over alternatives, and no exclusions or conditional contexts are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_update_pipelineA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool as idempotent and non-destructive. The description adds no further behavioral context such as whether the update replaces existing tasks/triggers entirely, what happens on partial input, or any permissions needed. It does not contradict the annotations, but adds no value beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that contains no filler or redundant phrasing. Every word contributes to understanding the tool's core function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complex nested schema and lack of output schema, the description could be more complete. It does not clarify whether the tasks and triggers fields fully replace existing configuration, and it omits any indication of success/return behavior. The detailed schema compensates somewhat, but the description alone leaves key semantic questions unanswered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the description does not need to explain individual parameters. The brief mention of 'tasks and triggers' maps to the two main fields but adds no additional 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb (Update), a specific resource (existing SourcePipeline pipeline), and the primary scope (tasks and triggers). This clearly distinguishes it from sibling tools like create_pipeline, delete_pipeline, run_pipeline, and get_pipeline.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is for updating an already-existing pipeline, which gives some context, but it does not explicitly state when to use this tool versus creating a new pipeline or listing pipelines, nor does it mention any prerequisites or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_upload_partA
  3.7/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden but only restates the operation ('Upload a part') and the workflow. It fails to disclose side effects, permission requirements, idempotency, or state changes. No contradictions with annotations since annotations are empty.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the core operation and including the essential workflow. 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the multipart lifecycle (initiate, upload, complete) and the schema documents all parameters. However, it omits details like part upload ordering, response behavior, or constraints beyond schema, leaving the agent with some ambiguity about invocation expectations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter has a description. The tool description adds no meaning beyond the schema; it only reinforces the workflow without clarifying parameter relationships or formats.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Upload a part in a multipart upload' with a specific verb and resource. It distinguishes itself from sibling tools like ncloud_put_object (single object upload) and ncloud_complete_multipart_upload (finalization) by explicitly mentioning the multipart context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly lays out the sequence: initiate multipart upload first, then upload parts, then complete. This gives clear usage context. However, it does not mention when to avoid this tool or compare against alternatives such as ncloud_put_object for small objects.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_vodstation_create_categoryA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only include destructiveHint=false, so the description carries some burden. It adds the dryRun preview behavior, which is a useful non-obvious trait. However, it does not disclose side effects like folder auto-creation (present only in the schema) or what happens on success. This is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, front-loaded with the primary action. Every word earns its place, and the dryRun tip is valuable context. No waste or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 9-parameter create tool with no output schema, the description is minimal. It covers the core purpose and dryRun but lacks context on prerequisites, return behavior, or how encoding options relate. The schema fills in parameter details, but the description leaves the agent with gaps about the overall workflow.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with detailed parameter descriptions (e.g., name mentions folder auto-creation). The description adds no extra parameter meaning beyond referencing dryRun, which is already documented in the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Create a new VOD Station encoding category' with a specific verb and resource. It distinguishes itself from sibling tools like ncloud_vodstation_list_categories and channel management tools. The addition of dryRun=false preview adds extra clarity about the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a helpful dryRun tip, indicating when to preview without creating. However, it does not explicitly state when to use this tool versus alternatives, nor does it list exclusions or prerequisites beyond what the schema provides. The usage is largely implied by the tool's unique purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_add_postgresql_databasesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint=false, which matches the additive operation. The description adds that it targets a Cloud DB for PostgreSQL instance and supports a list of databases, but does not disclose behavior such as duplicate handling, prerequisite instance states, or idempotency. This is adequate but minimal given annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no filler or redundant information. It is front-loaded and immediately understandable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter mutation with full schema coverage and a non-destructive annotation, the description plus schema provides sufficient information for correct invocation. It omits details about return values or constraints, but these are not critical for a straightforward add operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of the parameters ('Cloud PostgreSQL instance number' and 'List of databases to add'), so the description does not need to add parameter-level details. The phrase 'Add databases' aligns with the array parameter but provides no additional semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Add') and a specific resource ('databases to a Cloud DB for PostgreSQL instance'), clearly distinguishing it from siblings like ncloud_add_postgresql_users and ncloud_delete_postgresql_databases. It precisely states what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the usage context (when you need to add databases to a PostgreSQL instance) but does not provide explicit when-to-use/when-not-to-use guidance or mention alternatives. It is self-evident from the operation name but lacks explicit directional guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cancel_pipelineA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds the 'running' qualifier, which is useful context, but does not describe side effects, error conditions, or what happens if the execution already completed. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple cancellation tool with two well-documented parameters and supportive annotations, the description is nearly sufficient. It lacks details about response format or behavior on non-running executions, but the 'running' qualifier and idempotency hint cover the main edge cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters include descriptions (projectId as 'Pipeline ID' and historyId with source hints). The tool description adds no additional parameter meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Cancel') and the exact resource ('running SourcePipeline pipeline execution'). It is distinct from sibling tools like ncloud_sourcebuild_cancel_build or ncloud_sourcedeploy_cancel_deploy because it names SourcePipeline explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it (when canceling a running SourcePipeline execution) but does not explicitly mention alternatives or exclusion cases. No reference to sibling tools such as ncloud_sourcebuild_cancel_build, leaving some ambiguity for an agent choosing among cancel operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_get_certificateA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation, and the description's 'Get' aligns with that. However, the description adds no extra behavioral context such as return format, whether the certificate is sensitive, or any side effects, so its value beyond the annotation is minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, compact sentence provides the essential purpose with no unnecessary words. It is well-structured and immediately understandable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, no output schema, read-only), the description is essentially complete. A minor gap is that it does not describe the certificate data format or response structure, but this is not critical for a getter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with serviceGroupInstanceNo described as 'Cluster instance number'. The description does not elaborate on the parameter beyond what the schema already states, so it adds no extra meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 clear resource 'TLS certificate', further specifying 'used for cluster communication encryption'. This clearly distinguishes it from other sibling get tools by naming the exact certificate and its purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool—when you need the TLS certificate for cluster communication—but does not explicitly state when-not-to-use or mention alternatives. There are no exclusions or prerequisites provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_get_cluster_server_imagesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already establishes this as a safe read operation. The description adds the platform scope (G3/KVM), which is useful context beyond the annotation, but it does not reveal other behavioral aspects such as result format, pagination, or any caveats. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the key information (what it gets and for which service). There is no redundancy or filler, making it appropriate for a simple read-only tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only listing tool, the description is largely sufficient. It names the resource and scope. However, without an output schema, it does not indicate what the returned image list contains or how it might be used (e.g., for cluster creation). Slightly more context would improve it, but the simple nature of the tool keeps it from being incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters and the description correctly implies no parameters are needed. With no parameters, the baseline is 4; the description adds slight clarity by specifying the service scope (G3/KVM) but not much else. The schema already fully covers the lack of parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get available OS images for CDSS (G3/KVM)' clearly states the action (get), the resource (OS images), and the scope (CDSS, specifically G3/KVM). This distinguishes it from sibling tools like ncloud_ses_get_cluster_server_images and ncloud_nks_get_server_images by explicitly naming the CDSS service and platform generation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 such as ncloud_cdss_get_os_products or ncloud_cdss_get_server_spec_list. It does not mention prerequisites, context (e.g., cluster creation), or exclusions. The usage is only implied by the name and brief scope.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_get_cluster_statusA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description's main value is adding context about what statuses are included (broker, zookeeper, CMAK per node). However, it does not disclose response format, potential lack of availability, or other behavioral nuances beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that front-loads the action and specifies key components, with no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, so the description's mention of broker/zookeeper/CMAK status per node provides useful hints about the response. However, it could be more explicit about the response structure or whether a cluster-level status is also included.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with serviceGroupInstanceNo described as 'Cluster instance number'. The tool description adds no additional parameter semantics, but the schema sufficiently documents the single parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves health status for a CDSS cluster, specifying components (broker, zookeeper, CMAK) and per-node granularity. This uses a specific verb and resource, differentiating it from sibling tools like get_cluster_detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for checking health status, but it does not explicitly mention when to use it vs alternatives such as ncloud_cdss_get_cluster_detail or ncloud_cdss_get_monitoring. No exclusions or alternative recommendations are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_get_server_spec_listA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile, so the bar is lower. The description adds that only G3/KVM specs are returned, which is useful filtering context. However, it does not disclose additional behavioral details such as return format, pagination, or any required auth context beyond what the annotation provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence of 8 words. It is front-loaded with the action and resource, and every word adds value. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 adequate. It identifies the domain (CDSS) and the specific generation/hypervisor (G3/KVM). The absence of an output schema means return values are not described, but for a simple spec-list tool this is a minor gap. The readOnlyHint annotation covers the safety aspect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema coverage is 100% (empty schema), so there are no parameter semantics to document. The description appropriately does not invent any parameters, meeting the baseline for a zero-parameter tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource 'server specs', scoped to 'CDSS (G3/KVM)'. This distinguishes it from sibling tools like ncloud_cdss_get_server_generations (generations vs specs) and ncloud_cdss_get_node_products (products vs specs).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or alternative tools for different scenarios (e.g., when to use ncloud_cdss_get_node_products or ncloud_cdss_get_server_generations instead).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_list_config_groupsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered by structured data. The description adds semantic context ('Kafka configuration templates') but no additional behavioral details like pagination, authentication, or response structure. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence with clear subject-verb-object structure: 'List Config Groups for CDSS (Kafka configuration templates)'. No wasted words; the parenthetical adds valuable domain context without bloat.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Simple list tool with one optional parameter and a readOnly annotation. Description adequately states what is listed and clarifies the domain. No output schema is present, but for a standard list operation this is sufficient. Could optionally mention that all groups are returned when no filter is provided, but not essential given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single parameter kafkaVersionCode, which is documented as 'Filter by Kafka version code'. The description adds nothing about parameter usage, so the baseline of 3 applies per high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb 'List' with resource 'Config Groups for CDSS' and clarifies they are 'Kafka configuration templates'. This clearly distinguishes from sibling tools like ncloud_cdss_get_config_group_detail, which implies a single-item detail view.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternative guidance is provided. The 'List' verb implies use when an overview of config groups is needed, but there is no exclusion or comparison against ncloud_cdss_get_config_group_detail or ncloud_cdss_create_config_group.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_change_lb_configA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, so the description is not required to repeat safety. It adds the configurable fields but does not disclose behavioral nuances like the limitation that idleTimeout cannot be set for NETWORK type. That constraint exists in the schema, but the description itself adds no extra behavioral context beyond what annotations and schema provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states the action and key parameters with no fluff. It is appropriately concise for a straightforward configuration tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple tool shape, full schema coverage, and helpful annotations (idempotent, non-destructive), the description is largely complete. The only minor gap is that it doesn't mention the idleTimeout type restriction, but that is covered in the schema. Overall sufficient for an agent to use correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters already have meaningful descriptions. The tool description only names the parameters ('idle timeout, throughput type') without adding further semantic detail. This matches the baseline for full schema coverage; no additional value is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Change') and names the exact resource ('load balancer instance configuration') plus the configurable fields ('idle timeout, throughput type'). This clearly distinguishes it from sibling tools like ncloud_change_lb_listener_config, which targets listeners rather than the instance-level config.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it (changing LB instance-level settings) but does not explicitly state when NOT to use it or mention alternatives. For example, it doesn't say 'for listener settings, use change_lb_listener_config.' The context is understandable but lacks explicit differentiation and exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_change_nas_snapshot_configA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the specific config operations (enable/disable, schedule) but does not disclose additional behavioral details such as whether existing snapshots are affected or if there are prerequisites. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, tightly-written sentence that front-loads the action and resource. It includes parenthetical examples of what 'change config' entails, with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 4 parameters, 2 required, no output schema, and rich annotations, the description covers the essential purpose and operation adequately. It could optionally mention that snapshotTime and snapshotFrequencyTypeCode are required when enabling, but the schema already states this, so the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are already well-documented in the schema. The description briefly maps to the key params (enable/disable to isSnapshotConfiguration, schedule to snapshotTime and snapshotFrequencyTypeCode) but does not add syntax or format details beyond the schema. Baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Change') with a clear resource ('snapshot configuration for a NAS volume') and lists concrete actions (enable/disable auto snapshot, set schedule). This clearly distinguishes it from sibling tools like ncloud_create_nas_snapshot or ncloud_get_nas_snapshot_config_history.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (when modifying snapshot configuration) but does not explicitly mention alternatives or conditions like 'use this instead of creating a snapshot' or 'do not use when snapshots are disabled'. Usage context is clear but not explicitly differentiated from siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_cache_manual_backupA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation destructiveHint=false already discloses that this operation is not destructive, so the description doesn't need to repeat that. However, the description adds no extra behavioral context, such as whether the backup is asynchronous, if the instance must be in a certain state, or if there are storage implications.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is clearly front-loaded with the essential information. Every word earns its place, with no extraneous content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (2 required params, no output schema, low complexity) and the schema/annotations already cover parameters and destructive behavior. The description is sufficient for the tool's purpose, though it could mention whether the operation is synchronous or returns a job ID, but that is not mandatory given the simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with each parameter having a brief description. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Create') and the specific resource ('manual backup for a Cloud DB for Cache instance'), which distinguishes it from sibling tools like list_cache_manual_backups and delete_cache_manual_backup. It is concise and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (create a manual backup) but does not explicitly state when to use it versus alternatives, such as automatic backups or when a manual backup is appropriate. There are no exclusions or alternative tool mentions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_groupA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only include destructiveHint=false, which is not contradicted by the description. The description adds the dryRun behavior ('preview without creating'), which is useful. However, it does not disclose other behavioral aspects such as idempotency, required permissions, or what happens if the group already exists, so transparency is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise at two sentences, with the core purpose front-loaded and no extraneous content. The dryRun hint is a valuable addition that adds useful information without bloat. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (3 params, 1 required, no output schema, no nested objects), and the description plus schema jointly cover purpose, parameters, and the dryRun feature. However, there is no mention of what the response contains or any post-creation effects, which would be slightly more complete. For a basic create operation, this is nearly sufficient, hence a 4.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all three parameters (dryRun, groupName, groupDescription), providing full semantics in the schema. The description does not add extra parameter meaning beyond what the schema already defines, so it neither enhances nor detracts. Baseline 3 is appropriate given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action and resource: 'Create a new IAM group.' This is specific and distinguishes from sibling create tools like ncloud_create_role or ncloud_create_sub_account by naming the resource type 'IAM group.' The additional dryRun hint further clarifies scope without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  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 the tool (to create an IAM group) but does not mention alternatives or exclusions. The dryRun=true hint offers guidance on a parameter, not on tool selection, so it does not fully address usage versus alternatives. No explicit when-not-to-use scenarios are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_login_keyA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only provide destructiveHint: false. The description adds that the tool returns the private key, which is a critical behavioral detail beyond the annotations. However, it does not warn about the secrecy of the private key or that it may only be shown once, leaving some transparency gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that includes the action, resource, and the key return behavior. 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, the description covers the essential purpose and the notable return value. It lacks minor contextual details like security precautions or uniqueness requirements, but these are not critical for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: every parameter (keyName) has a clear description ('Name for the new login key'). The tool description does not add additional parameter-level detail, so it satisfies 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the action ('Create a new login key') and the resource, and notes that it returns the private key. This clearly distinguishes it from sibling tools like list, delete, and import login keys.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The verb 'Create' implies usage when a new login key is needed, but the description provides no explicit guidance on when to use this tool versus alternatives like import_login_key or list_login_keys. No exclusions or alternative scenarios are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_mysql_slaveA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only include destructiveHint=false, and the description adds the read-replica context. However, it does not disclose behavioral aspects like provisioning time, billing implications, or that this is a write operation (the annotation already covers non-destructiveness). 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence containing only the essential purpose. No filler or redundant information; every word contributes to the meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple create operation with three fully described parameters and no output schema, the description adequately conveys the tool's function. It clarifies the ambiguity of 'slave' with the parenthetical 'read replica'. Minor gaps remain about the operation's workflow or response, but these are not critical for this low-complexity tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the schema already provides clear descriptions for each parameter (e.g., subnetNo conditions). The tool description adds no additional parameter meaning beyond what the schema states, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action on a specific resource: 'Create a slave (read replica) for a Cloud DB for MySQL instance'. The verb 'Create' and resource 'slave for MySQL instance' distinguish this from sibling tools like ncloud_create_postgresql_read_replica and ncloud_create_mssql_slave.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a MySQL read replica is needed, but does not explicitly state when to use this over alternatives or mention prerequisites. There is no 'when not to use' guidance, leaving the agent to infer context from the resource type.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_nat_gatewayA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation only includes destructiveHint: false, which aligns with the description's 'Create' action (non-destructive). The description adds the Public/Private type support, but does not disclose further behavioral traits such as whether the operation is synchronous, whether dependent resources (e.g., subnets) are automatically provisioned, or what response is returned. Since the annotation is minimal, the description carries some burden, but it provides only basic information.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action and object, and then adds the type distinction. It contains zero waste and is appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is simple and the parameter schema is thorough, covering all required and optional inputs. However, there is no output schema, and the description does not mention what the tool returns (e.g., NAT Gateway instance ID or asynchronous job status), which is a gap for a create operation. It also lacks usage guidelines, but overall it provides sufficient context for basic selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, where each parameter has a detailed description. The tool's description adds no parameter-specific information beyond 'Public (PBLIP) and Private (PRVT) types,' which is already reflected in the schema's subnetNo, privateIp, and publicIpInstanceNo descriptions. Thus, the description adds little value over the schema, keeping the score at the baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('Create'), the resource ('NAT Gateway instance'), and the scope ('in a VPC'). It also distinguishes between Public (PBLIP) and Private (PRVT) types, which differentiates it from other NAT gateway sibling tools like list, get, set description, and delete.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for creating a NAT Gateway, but does not explicitly state when to prefer this over alternatives or mention prerequisites (e.g., VPC must exist, subnet type requirements). It does not reference when not to use it, leaving the agent to infer from the verb and resource type.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_vpcA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include destructiveHint=false, so safety is already covered. The description adds the dryRun=true option for preview, which is a useful behavioral detail. However, it does not disclose what happens on success (e.g., return value) or any other side effects beyond what dryRun implies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences: the first states the primary action, the second provides a valuable dryRun tip. No unnecessary words, and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple create operation with full parameter coverage and a non-destructive annotation, the description is complete enough. It could mention return values or async behavior, but these are not critical given the simplicity and high schema coverage. The dryRun tip adds useful context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all three parameters clearly documented. The description only repeats the dryRun behavior already present in the schema, adding no new semantic meaning for vpcName or ipv4CidrBlock. Baseline 3 is appropriate when the schema handles parameter explanation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Create a new VPC' uses a specific verb and resource, clearly distinguishing it from sibling tools like ncloud_delete_vpc, ncloud_list_vpcs, and other ncloud_create_* tools. The purpose is unambiguous and directly tied to the tool name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or when-not-to-use guidance is provided. The usage is implied by the name and description ('use when you need to create a VPC'), but there is no mention of alternatives or prerequisites, such as needing a VPC before subnets.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_block_storageA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly warns 'Destructive' and notes 'Permanently delete', adding meaningful context about irreversibility. It also explains the confirm=true requirement, which goes beyond the annotations' destructiveHint and idempotentHint by detailing the safety gating mechanism.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single focused sentence with a leading warning emoji, immediately conveying destructive impact, followed by the critical confirmation requirement. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter destructive operation with annotations covering idempotency and destructiveness, the description sufficiently covers purpose, the confirmation guard, and the scope (one or more instances). It omits prerequisites like detaching the volume first, but this is not critical given the simple schema and existing annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 fully described. The description's mention of 'Set confirm=true' adds no new semantic value beyond the schema's own wording ('Must be true to actually execute'), yielding a baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'Permanently delete one or more block storage instances.' This clearly distinguishes it from sibling delete operations (e.g., delete_snapshots, delete_nas_volumes) by naming the exact resource type and scope (block storage).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives, such as delete_snapshots or detach_block_storage. It implies usage only via the provided operation name and general delete semantics, with no exclusions or contextual hints.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_custom_resourceA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds a warning symbol and reiterates that confirm=true is required, which is also in the schema. It does not reveal additional behavioral traits beyond what annotations provide, but it does not contradict them either.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a clear warning symbol, actionable instruction, and resource context. No extraneous words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple deletion tool with full annotations and schema coverage, the description is adequate. It clearly communicates the destructive nature and the required confirmation. The lack of an output schema and the simplicity of the operation make the description complete enough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% description coverage for both parameters, and the description adds no further parameter-level meaning. The baseline of 3 applies because the schema carries the semantic load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Delete') and the target ('a user-defined custom resource from Cloud Insight'), distinguishing it from sibling create/update/get/list tools. The resource scope and cloud context are explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied by the verb 'Delete' and the resource name, but there is no explicit guidance on when to use this versus alternatives or when not to use it. No exclusions or conditions are mentioned beyond the confirm flag.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_launch_configA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond the destructiveHint annotation by specifying the deletion is 'permanently' and by disclosing the confirmation mechanism ('Set confirm=true to execute'). This informs the agent that the operation is irreversible and requires an explicit opt-in, which is not captured by the annotations alone. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two sentences, front-loaded with a clear destructive warning. '⚠️ Destructive: Permanently delete a launch configuration. Set confirm=true to execute.' Each sentence serves a distinct purpose and there is no redundant or verbose content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple delete operation, the destructive annotations, and fully documented parameters, the description covers the essential safety and execution context. It might have mentioned side effects (e.g., impact on related resources) or return values, but given the 100% schema coverage and clear annotations, it is sufficiently complete for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for both parameters: confirm ('Must be true to actually execute the destructive operation') and launchConfigurationNo ('Launch configuration number to delete'). The description's mention of 'Set confirm=true to execute' reiterates what the schema already explains. No additional parameter semantics are provided beyond the schema's 100% coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Permanently delete a launch configuration.' The verb 'delete' and the specific resource 'launch configuration' precisely identify the tool's function, distinguishing it from sibling tools like ncloud_list_launch_configs and ncloud_create_launch_config. The 'permanently' keyword adds an important qualifier.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide any context on when to use this tool versus alternatives. It does not mention related operations like listing or creating launch configurations, nor does it state prerequisites or exclusions. The only guidance is the confirm requirement, which is more about execution than usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_mysql_databasesA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, but the description reinforces this with a warning emoji and adds critical behavioral context: 'Set confirm=true to execute.' This tells the agent that the operation is destructive and requires explicit confirmation, which is beyond what the annotations alone communicate. No contradiction exists between the description and annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, each earning its place: the first states the destructive purpose, and the second specifies the safety mechanism. It is front-loaded with a warning and is highly concise with no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive delete operation with three parameters and no output schema, the description covers the core intent and the confirmation safeguard. It could mention potential prerequisites or side effects (e.g., data loss), but the annotations and schema fill the gap reasonably well, making the description sufficient for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all three parameters. The description's mention of 'Set confirm=true to execute' aligns with the confirm parameter's schema description but adds no new meaning. With high schema coverage, the baseline is 3, and the tool description does not elevate it further.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Delete databases from a Cloud DB for MySQL instance,' which uses a specific verb (delete) and resource (databases from a Cloud DB for MySQL instance). This distinguishes it from sibling tools like ncloud_delete_mysql_users and ncloud_delete_mysql_instance, which target different resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives, such as ncloud_add_mysql_databases or ncloud_delete_mysql_users. It only states the action and the confirmation requirement, leaving the agent to infer usage from the name and purpose. There are no prerequisites, exclusions, or alternative tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_mysql_instanceA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructive and idempotent, but the description adds that deletion is permanent and requires confirm=true, clarifying the actual execution gate and irreversibility beyond the annotation flags.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single concise sentence with a clear warning symbol, front-loading the destructive nature and execution requirement. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with comprehensive schema and annotations, the description covers the essential information: what is deleted, permanence, and the confirm gate. It does not need to explain return values due to lack of output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters, so baseline is 3. The description reinforces the confirm parameter's purpose but adds no new semantic information about cloudMysqlInstanceNo beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Permanently delete a Cloud DB for MySQL instance' with a specific verb and resource, clearly distinguishing it from sibling tools like ncloud_delete_mysql_server or ncloud_delete_mysql_databases.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool vs alternatives. It only warns about destructiveness and the confirm parameter; no mention of when to choose this over ncloud_delete_mysql_server or other delete operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_route_tableA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructive and idempotent, but the description adds the critical safety behavior that confirm=true is required to execute. It also emphasizes permanence, which goes beyond the structured metadata and helps the agent understand the risk before invoking.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with a warning emoji, front-loading the destructive nature and action. It is concise and free of redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with two parameters and annotations, the description covers the purpose, destructive nature, and confirmation requirement. It lacks notes on side effects or prerequisites, but given the simple scope and annotation support, it is mostly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with both parameters documented (routeTableNo and confirm). The description adds no additional parameter semantics, but the schema already provides sufficient detail, so baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Permanently delete a route table' with a specific verb and resource, distinguishing it from sibling route table management tools like create or add-route tools. The destructive warning prefix reinforces the action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no explicit guidance on when to use this tool versus alternatives, such as prerequisites like detaching subnets first or conditions preventing deletion. No alternatives or when-not-to-use scenarios are mentioned, leaving the agent to infer usage solely from the name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_scheduled_actionA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already disclose destructiveHint=true and idempotentHint=true. The description adds the critical requirement 'Set confirm=true to execute,' which is also present in the schema's confirm parameter description. While this behavioral detail is important and prominently placed, it is redundant with the schema, so the description adds limited new context beyond structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one sentence with a clear warning prefix. It is front-loaded with the destructive nature and states the action and safety requirement concisely. Every phrase is necessary and there is no verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with 3 parameters, 100% schema coverage, and annotations, the description provides sufficient context. It tells what is deleted, the target resource (Auto Scaling Group), and the confirmation requirement. The lack of output schema is acceptable for a delete tool, and no return value explanation is critical for this kind of operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all three parameters, including the confirm requirement. The description does not add any parameter details beyond what the schema already documents, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: 'Delete a scheduled action from an Auto Scaling Group.' The verb+resource is specific, and the word 'Delete' distinguishes it from sibling tools like ncloud_put_scheduled_action and ncloud_list_scheduled_actions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case (deleting a scheduled action) but does not explicitly state when to use this tool versus alternatives, nor does it mention related operations like creating or listing scheduled actions. The sibling list provides context, but the description itself contains no usage guidance or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_snapshotsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint and idempotentHint. The description adds that deletion is permanent and requires confirm=true to execute, providing a safety interlock beyond the boolean destructive hint. It also alerts with '⚠️ Destructive,' adding useful context about irreversibility.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that efficiently conveys the destructive warning, the resource being operated on, and the execution requirement. It is front-loaded with the warning and contains no unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 2-parameter destructive tool with good schema coverage and idempotent/destructive annotations, the description covers the core behavior and safety mechanism. It could mention what happens when confirm=false, but that is implied by the schema default and the explicit 'Set confirm=true to execute.' Overall it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema (confirm and blockStorageSnapshotInstanceNoList) with meaningful descriptions. The tool description adds no extra parameter semantics beyond what the schema already 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool permanently deletes one or more block storage snapshot instances. The verb 'delete' and specific resource 'block storage snapshot instances' distinguish it from sibling deletion tools like ncloud_delete_block_storage or ncloud_delete_nas_snapshot.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as listing snapshots first to obtain instance numbers. The only usage-related instruction is 'Set confirm=true to execute,' which concerns parameter behavior rather than tool selection context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_vpc_peeringA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  While annotations already include destructiveHint=true, the description adds value by explicitly stating 'Permanently delete' and by disclosing the confirm=true safety guard, which is a behavioral trait not fully captured by the annotation. The idempotentHint=true annotation is not contradicted, and the description adds context about irreversibility.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that includes a warning symbol, the destructive action, and the key confirmation requirement. Every word earns its place, with no unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with clear annotations and schema, the description covers the critical aspects: the destructive, permanent nature and the safety switch. It does not explain what happens after deletion or any dependencies, but those are not essential for a tool with this simplicity and annotation coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameters with clear descriptions, including the confirm flag's purpose. The description's 'Set confirm=true to execute' restates the schema's confirm description but does not add new details about parameter formats or relationships. Baseline 3 is appropriate given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('delete') and the resource ('VPC Peering connection'), and adds the adverb 'Permanently' to convey irreversibility. It is specific enough, though it does not explicitly differentiate from sibling tools like ncloud_accept_reject_vpc_peering or ncloud_set_vpc_peering_description, which operate on the same resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for deleting a VPC peering connection and requires confirm=true to execute, giving a clear precondition. However, it does not mention when not to use it or provide alternatives, so usage guidance is minimal but not misleading.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_detach_network_interfaceA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate idempotentHint=true and destructiveHint=false, covering the operation's safety profile. The description adds the 'from a server instance' scoping but does not disclose additional behavioral traits such as whether the server must be stopped, whether the operation is reversible, or any post-condition effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence of eight words: 'Detach a network interface from a server instance.' Every word 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with full schema coverage, annotations, and no output schema, the description is complete enough to understand the operation. It clearly identifies the action and objects involved, though it does not mention any prerequisites or return behavior, which are not necessary for this level of complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters (networkInterfaceNo and serverInstanceNo) having descriptions. The tool description adds the relationship 'from a server instance' but does not provide additional parameter-level meaning beyond what the schema already states, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Detach' with a clear resource ('network interface') and target ('server instance'), unambiguously distinguishing it from siblings like ncloud_attach_network_interface, ncloud_create_network_interface, and ncloud_delete_network_interface.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (use when you need to detach a network interface from a server) but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The sibling list provides context, but the description itself lacks explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_dns_list_domainsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond the readOnlyHint annotation by specifying the return structure as a Spring Page object with content, pageable, and totalElements. This gives the agent insight into the response format, which is useful for handling output. It does not contradict the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, with two short sentences that front-load the main purpose and then provide return structure details. Every word adds value, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list operation with readOnlyHint annotation and fully described schema parameters, the description provides the essential details: network scope, pagination, and return format. It could optionally mention the domainName filter, but the schema already covers this, so the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions, including page (0-based), size, and domainName filter. The description's mention of pagination aligns with the page/size parameters but adds no additional meaning beyond the schema, 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.

  Purpose5/5

  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 'Global DNS domains', which is specific and distinguishes it from sibling tools like ncloud_dns_get_domain_detail and ncloud_dns_create_domain. The mention of pagination further clarifies the operation's scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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, nor does it mention any exclusions or prerequisites. It only states what the tool does, leaving the agent to infer usage context from the name and schema alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_dns_list_recordsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations provide readOnlyHint=true and the description confirms a read-only list operation with pagination. It adds minimal context about pagination behavior, but does not disclose edge cases like invalid domainId handling or result ordering. This is a modest addition beyond annotations, not a contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence conveying the action, resource, scope, and pagination feature. Every word earns its place and there is no redundant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with a well-documented schema, the description plus schema provide sufficient information to invoke correctly. However, the optional recordType and searchContent filters are not mentioned in the description, and there is no indication of response format, leaving a small gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all five parameters, including domainId, page, size, recordType, and searchContent. The description adds no extra parameter semantics beyond what the schema already documents; it only mentions pagination, which is already evident from the required page and size params. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' with the resource 'DNS records' and scopes it 'for a specific Global DNS domain' plus mentions pagination. This clearly distinguishes it from sibling tools like ncloud_dns_list_domains (lists domains) and ncloud_dns_create_records (creates records).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is used to list DNS records for a Global DNS domain, but it does not explicitly state when to use it versus alternatives such as ncloud_dns_list_lb_records. There is no mention of prerequisites or exclusions, so usage guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_drm_list_policiesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already establishes this as a safe read operation, lowering the bar for behavioral disclosure. The description adds that pagination is supported, a useful behavioral detail, but does not go further to describe response format, defaults, or other nuances, so it makes a modest contribution.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The entire description is a single, front-loaded sentence that conveys action, resource, and pagination without a single wasted word. It is appropriately sized for a simple list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward operation with two optional, fully documented parameters and a read-only annotation, the description is adequate. It clearly states the purpose and implies the return is a list, though it does not describe response details since no output schema is present. Slightly more detail about pagination behavior could improve it, but it is not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with pageNo and pageSize already well-described in the input schema. The description's mention of 'pagination' aligns with these parameters but adds no additional semantic meaning beyond what the schema provides, earning the baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a clear action verb ('List') and specific resource ('DRM policies'), with a pagination qualifier that defines scope. This distinguishes it from sibling tools like get_policy (single fetch), create/update/delete_policy, and non-DRM policy listing tools via the 'DRM' prefix.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'List DRM policies' implies the primary use case (enumerating policies), and pagination suggests handling large result sets. However, it does not explicitly state alternatives (e.g., 'use get_policy for a single policy') or exclusions, so 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.

• ncloud_drm_list_sitesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already indicates a safe read operation. The description adds 'with pagination,' which is useful context but largely duplicates what the schema parameters express. It does not disclose other behavioral traits like response ordering, rate limits, or whether all sites are returned regardless of tenant scope. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that directly conveys the purpose and key feature (pagination). No wasted words, and the structure is optimal for a simple list tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with two well-documented parameters and no output schema, the description is mostly sufficient. It covers the core purpose and pagination capability. However, it lacks any detail about the response format or what fields are returned for each site, which would help an agent anticipate output. Given the tool's simplicity, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%; both pageNo and pageSize have descriptions in the schema. The description's mention of 'pagination' adds minimal meaning beyond the schema. It doesn't clarify e.g. whether pageNo starts at 0 or 1, but the schema says 'default 1', so the description does not significantly compensate for any ambiguity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('List') and a specific resource ('One-Click Multi DRM sites'), with the added detail of pagination. This distinguishes it from sibling tools like ncloud_drm_get_site (get a single site), ncloud_drm_create_site (create), and ncloud_drm_update_site (update).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool: when you need to list DRM sites, especially with pagination. However, it does not explicitly state alternatives or exclusions (e.g., 'use get_site for a single site' or 'use list_policies for policies'). The name itself signals list vs. get, but explicit guidance is absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_enable_flow_logA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the operation as idempotent and non-destructive. The description adds context by explaining the effect (captures and stores logs) but does not disclose prerequisites (e.g., bucket must exist) or behavior for repeated calls beyond what the idempotentHint implies. It is not misleading but adds limited behavioral detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two sentences, no redundancy. It front-loads the primary action and directly states the purpose and outcome, with zero filler words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple configuration tool with full schema coverage and good annotations, the description provides sufficient context: it explains what the tool does, what it affects, and where logs are stored. It does not mention prerequisites or optional parameter behavior, but these are covered by the schema and the simplicity of the operation makes the description reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all three parameters are documented with clear descriptions. The description merely restates 'specified bucket' and 'network interface' without adding new meaning or clarifying the optional flowLogStatusTypeCode parameter or its default behavior. This aligns with the baseline of 3 for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Enable FlowLog') and the target resource ('network interface'), and it explains the effect (captures network traffic logs and stores them in a bucket). This distinguishes it from sibling tools like ncloud_disable_flow_log and ncloud_get_flow_log_config.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (to enable FlowLog) but does not explicitly explain when not to use it or mention alternatives such as disable_flow_log or get_flow_log_config. No clear exclusions or alternative guidance are provided, so the agent must infer usage from the name and description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_functions_delete_triggerA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as destructive and idempotent, but the description adds valuable context: the operation is 'permanent' (irreversible) and requires confirm=true to execute, which is a critical behavioral gate not fully conveyed by the destructiveHint alone. This goes beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a warning emoji, a clear action, and the critical confirmation instruction. Every word serves a purpose; no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive operation with complete schema coverage and no output schema, the description provides the essential information: what it deletes and the safety confirm gate. It doesn't mention error behavior when confirm is false or prerequisites, but these are reasonable omissions for this tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the schema already documents all three parameters (confirm, platform, triggerName) with clear descriptions. The tool description only reiterates the confirm=true requirement already present in the schema, adding no new meaning to any parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Permanently delete') and the specific resource ('a Cloud Functions trigger'), making it unambiguous and distinct from sibling tools like ncloud_functions_create_trigger or ncloud_functions_list_triggers. The verb+object structure precisely conveys what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided about when to use this tool versus alternatives, or any prerequisites such as unlinking trigger actions first. The description only states what the tool does, not the circumstances for use or exclusions. The confirm flag instruction is operational guidance but not about tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_functions_get_trigger_activationsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds no further behavioral context, such as pagination or time-filter behavior (though these are in the schema). It does not contradict annotations, but also does not enrich the behavioral profile beyond what structured data already provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, short sentence ('Get activation history for a specific trigger') that is front-loaded and contains zero filler. It delivers the core purpose efficiently and scores high on conciseness without sacrificing clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a read-only list operation with a well-documented schema and an explicit readOnlyHint. While the description is minimal, the presence of full parameter descriptions and safe-read annotations makes it adequately complete for an agent to invoke correctly. It could mention return format or pagination, but those are not critical given the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all six parameters, so the baseline is 3. The description's phrase 'for a specific trigger' aligns with the required triggerName parameter but adds no extra semantics beyond what the schema already documents. With full schema coverage, no compensation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Get') and resource ('activation history') scoped to 'a specific trigger', which distinguishes it from sibling tools like get_trigger_activation_detail or get_activations. It is specific and actionable, leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case: retrieving activation history for a trigger. However, it does not explicitly mention when not to use this tool or point to alternatives (e.g., get_trigger_activation_detail for details of a single activation). The context is clear but lacks exclusions, so it falls short of explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_functions_unlink_trigger_actionA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description reinforces this with '⚠️ Destructive.' Beyond that, it adds critical behavioral context: 'Set confirm=true to execute,' indicating the operation will not proceed without explicit confirmation. This exceeds what annotations alone provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with a clear warning and instruction. It is front-loaded with the destructive warning and immediately states the action and the confirmation requirement. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple mutation tool with full schema coverage, the description plus schema covers the essential information: the operation, the confirmation gate, and the platform default. It does not describe error conditions or post-conditions, but these are not critical for such a straightforward operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 adds no additional parameter meaning; the confirm requirement is already fully documented in the schema. The actionName and triggerName formats are also already described in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Unlink an action from a trigger.' This specific verb+resource phrasing distinguishes it from sibling tools like ncloud_functions_link_trigger_action (the opposite operation) and ncloud_functions_delete_trigger (deletes the entire trigger).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to choose this tool over alternatives. It does instruct 'Set confirm=true to execute,' but this is a parameter-related condition rather than tool-selection guidance. There is no mention of when to use unlinking vs linking or deleting.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_acg_rulesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already signals a safe read operation, and the description adds the scope of returning all inbound and outbound rules. It does not disclose additional behavioral details such as pagination, ordering, or any default filtering beyond what the schema already states. The description is consistent with the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the main action and resource. Every word is useful and there is no redundancy or extraneous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a simple read-only list operation with a well-specified schema and clear annotation. The description, combined with the schema, is sufficient for an agent to invoke the tool, though it does not explain return formatting or potential edge cases. Given the simplicity, this is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all parameter meanings with descriptions (accessControlGroupNo and accessControlGroupRuleTypeCode with its default). The description adds no additional parameter semantics beyond what the schema already 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.

  Purpose5/5

  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 inbound and outbound rules for a specific ACG', which distinctly identifies the tool's purpose. It differentiates from sibling tools like ncloud_list_acgs (listing ACGs) and ncloud_get_acg_detail (getting ACG details) by focusing on rules.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied: it is used to retrieve firewall rules for a particular ACG, requiring the ACG identifier. However, there is no explicit guidance on when to use this tool versus alternatives like ncloud_list_acgs or ncloud_get_acg_detail, and no mention of exclusions or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_activity_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  readOnlyHint=true already establishes the safety profile, and the description adds useful context about the internal mechanism (narrow time-range query, filter by ID), which explains why eventTime is required. However, it does not disclose failure behavior (e.g., what happens if the event falls outside the narrow window) or what specific fields the 'detailed information' contains.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with zero filler. The first sentence states the primary purpose upfront, and the second explains the underlying mechanism. This is highly efficient and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read-only lookup tool with full schema coverage and a readOnlyHint annotation, the description adequately covers purpose and mechanism. The absence of an output schema means it could optionally describe what 'detailed information' includes, but the name and the simplicity of the tool mitigate this gap, making the description sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents both parameters with formats and purposes. The description adds value by explaining the relationship between eventTime and activityId (search narrow window, then filter), but it provides no additional syntax or format details beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource ('Get detailed information about a specific cloud activity event') and explains the unique lookup mechanism (querying with a narrow time range and filtering by activityId). This clearly distinguishes it from broad list tools like ncloud_get_activity_logs by emphasizing the targeted, detail-oriented nature of the operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied rather than explicit: the mention of a narrow time range and activityId filtering tells the agent this is for targeted detail lookups requiring an approximate event time, but no alternatives, exclusions, or when-not-to-use scenarios are stated. No sibling tools are referenced for comparison, so the agent must infer the appropriate context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_bucket_aclA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds the context that this targets Object Storage buckets, but discloses no additional behavioral traits such as response format, permissions required, or error conditions. It is consistent with the annotation, with no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded with the action and resource. It contains no filler or redundant information, making it efficiently sized for its simple purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (one parameter, no output schema, read-only annotation), the description covers the essential purpose and resource. It lacks detail on the return value structure or potential errors, but for such a straightforward read operation, the minimal context is largely sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage for the single parameter (bucketName) with a clear description 'Name of the bucket'. The tool description adds no extra parameter semantics beyond what the schema already offers, so the high schema coverage warrants a baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get the access control list (ACL) of an Object Storage bucket' clearly states a specific verb (Get) and resource (ACL of an Object Storage bucket). It explicitly distinguishes the bucket-level ACL tool from sibling tools like get_object_acl and put_bucket_acl.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives is provided. However, the phrase 'Get the access control list of an Object Storage bucket' implies its use case: whenever you need to retrieve a bucket's ACL. This is an implied usage but lacks direct comparisons or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_cache_productsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description matches the readOnlyHint annotation (a read operation), but adds no additional behavioral context such as pagination, return format, or required permissions. With annotations already declaring the read-only aspect, the description provides minimal extra value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no redundant or filler content. It is appropriately concise for a simple 1-parameter read tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read tool with a readOnlyHint annotation, the description is largely sufficient. It states the purpose and the output (product codes), and the schema covers the input. However, the lack of an explicit note about the output structure or possible empty results is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes the single parameter with 100% coverage. The description only restates the same concept ('for a given image') without adding formats, constraints, or how to obtain a valid product code.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'List', the resource 'Cloud Cache server spec product codes', and the constraint 'for a given image'. This distinguishes it from sibling tools like ncloud_get_cache_image_products, which lists image products rather than spec product codes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied: call this when you need spec product codes for a specific Cloud Cache image. However, it does not explicitly mention when not to use it or suggest alternative tools, leaving some ambiguity given the many similar product-listing siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_deny_allow_group_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint: true, so the read-only nature is known. The description adds only 'Get detailed information', which reiterates the action without enriching behavioral context like response structure, error handling, or required permissions. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, front-loaded verb, zero filler. Perfectly concise for a simple get-by-id operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 no output schema, the description is adequate. It tells the user the action and resource. Some additional context about return contents could be useful, but given simplicity and annotation, completeness is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with parameter 'networkAclDenyAllowGroupNo' described as 'Deny-Allow Group number to query'. The description itself adds no extra meaning beyond the schema, which already documents the purpose of the single parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Get' with resource 'specific Deny-Allow Group', clearly distinguishing it from sibling tools like list_deny_allow_groups. The 'specific' qualifier signals this fetches one entity by identifier, differentiating it from list operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need details for an individual Deny-Allow Group, but provides no explicit when/or not to use alternatives such as the list tool. No exclusions or alternative guidance is given, so the context is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_file_pluginA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a read-only operation, and the description's verb 'Get' aligns with that. The description adds minimal extra behavioral context, such as the scoping to a specific server instance, but doesn't disclose what happens if the instance is invalid or the structure of the returned configuration. The annotation covers the safety profile, so a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that states the action, resource, and scope without any redundant words or filler. It is front-loaded with the verb and fully informative in one line.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one required parameter, read-only annotation, no output schema), the description covers the essential purpose and scope. It doesn't detail the response format, but for a simple configuration retrieval, this is not a significant gap. It is complete enough for an agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for the single parameter 'instanceNo' with a clear description ('Server instance number'). The description's word 'specific' reinforces that this parameter identifies a unique instance but adds no new semantic information beyond the schema. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and clearly identifies the resource ('file monitoring plugin configuration') and the scope ('for a specific server instance'). It distinguishes itself from sibling tools like ncloud_list_file_plugins, which implies listing all configurations, and ncloud_add_file_plugin/remove_file_plugin, which are mutations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for a specific server instance' implies this tool is for retrieving a single instance's configuration rather than listing all, but it does not explicitly state when to use this versus alternatives like list_file_plugins, nor does it mention exclusions. Usage context is implied rather than explicitly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_integrationA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description ('Get') is consistent with that. No contradiction exists, but the description adds minimal behavioral context beyond the annotation—no mention of response details, pagination, or other traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no wasted words. It states the action and resource immediately, making it optimally concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 1-parameter read operation with a readOnly annotation, the description is mostly sufficient. However, since there is no output schema, the phrase 'detailed information' is somewhat vague—it does not specify what details are returned, which is a minor completeness gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with the integrationId parameter already described as 'Integration ID to retrieve details for'. The description's phrase 'specific' adds no new semantic meaning beyond what the schema provides, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' with the resource 'Cloud Insight integration' and the qualifier 'specific', clearly distinguishing it from list/create/update/delete siblings. It unambiguously indicates a get-by-ID operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus alternatives. It is implicitly clear that this complements ncloud_list_integrations, but the description does not name the alternative or mention prerequisites like obtaining an integration ID.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_launch_config_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, and the description ('Get detailed information') is consistent with a read operation. It adds context that the tool is for Auto Scaling but does not disclose return value details or any potential error/fulfillment behavior, though the read-only nature reduces the need for extensive disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise sentence that front-loads the action and resource. No filler or redundant phrasing; every word contributes to understanding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 parameter and no output schema, the description is mostly complete. However, 'detailed information' is vague and could specify what attributes are returned (e.g., image, instance type, user data), but this does not severely hinder use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the only parameter (launchConfigurationNo as 'Launch configuration number to query'), giving 100% schema description coverage. The description does not add additional meaning beyond the schema, meeting the baseline for full coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('detailed information about a specific launch configuration'), clearly scoped to Auto Scaling. This distinguishes it from sibling tools like list_launch_configs (listing) and create/delete_launch_config.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies usage when a specific launchConfigurationNo is known, but it does not explicitly mention alternatives or when not to use this tool. No reference to sibling list/delete/create tools is provided, leaving usage guidance mostly implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_load_balancer_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, so the agent knows this is a safe read operation. The description adds only 'detailed information,' which is generic and does not disclose response format, pagination, or any additional behavioral traits. No contradiction with annotations exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It immediately states the purpose and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool, the description is adequate. However, since there is no output schema, it would be slightly more complete if it indicated what kind of 'detailed information' is returned (e.g., configuration, health, IPs). Still, the tool is understandable as-is.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the loadBalancerInstanceNo parameter is described as 'Load balancer instance number to query.' The tool description adds no further parameter context, so it relies on the schema. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('get'), identifies the resource ('load balancer instance'), and scopes it to 'a specific' instance. This clearly distinguishes it from sibling tools like ncloud_list_load_balancers, which lists instances.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The word 'specific' implies this tool is for querying a single instance by number, contrasting with list operations, but there is no explicit guidance on when to use this versus alternatives like ncloud_list_load_balancers or ncloud_get_target_group_detail. Usage context is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_log_usageA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a read-only operation. The description adds that it retrieves capacity and usage but does not disclose additional behavioral details such as response format, pagination, or whether the usage is current or aggregated. With annotations covering safety, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of nine words, front-loaded with the action and resource. Every word is informative, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple getter with one optional parameter and no output schema, the description is mostly complete. It clearly states what is retrieved (storage capacity and usage). A minor gap is that it does not specify units or return structure, but this is acceptable for a simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The sole parameter regionCode is fully described in the schema with 'Region code (default kr)'. The description does not mention parameters, but schema coverage is 100%, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' with a specific resource 'Cloud Log Analytics storage capacity and usage'. It clearly distinguishes from sibling log tools like search_logs or get_log_count_total, which focus on log data rather than storage usage.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no explicit guidance on when to use this tool versus alternatives. The usage is implied by the name and description: checking storage usage. No exclusions or alternative tool references are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_member_server_image_listA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation, and the description's 'List' verb aligns with that. Beyond that, no additional behavioral traits (e.g., pagination, default scope, or return format) are disclosed, but the description does usefully define 'member server images'.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that includes the core action, resource, and a clarifying definition. No extraneous words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with one optional filter parameter, the description sufficiently explains the tool's purpose and resource type. Given the readOnlyHint and schema's param description, the lack of output details is acceptable, though it could have mentioned that omitting the parameter returns all member server images.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description covers the only parameter ('Filter by member server image instance numbers') with 100% coverage, so the description does not need to explain it further. The tool description itself adds no parameter-related information, which is fine given the schema's clarity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and identifies the exact resource 'member server images', with a clarifying parenthetical explaining they are 'custom images created from running servers'. This clearly distinguishes it from sibling tools like ncloud_get_member_server_image_detail or ncloud_create_member_server_image.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives contextual info about what member server images are, which implies when this tool is relevant (listing custom images), but does not explicitly state when to use this over alternatives like ncloud_get_member_server_image_detail or how filtering via the parameter works. No exclusions or alternatives are named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_mongodb_productsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds minimal behavioral context beyond the schema parameter descriptions, with no mention of return format, pagination, or other operational characteristics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, front-loaded with the verb and resource, with the filtering capability appended. There is no wasted wording or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with two parameters and no output schema. The description sufficiently states the output (product codes), and the schema covers parameter details. It lacks explicit mention of return structure or edge cases, but given the low complexity, the description is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters, each with meaningful descriptions. The description's 'filterable by role type' aligns with the schema's infraResourceDetailTypeCode but adds no new semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List'), a clear resource ('MongoDB server spec product codes'), and notes the filtering capability by role type. It distinguishes this tool from siblings like ncloud_get_mongodb_image_products by focusing on spec product codes rather than images.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its use when MongoDB server spec product codes are needed, but it does not explicitly state when to use this tool versus alternatives or any exclusions. There is no mention of prerequisites or complementary tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_mongodb_target_vpcsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the operation as safe and read-only. The description 'List' is consistent and adds that the scope is MongoDB VPCs, but provides no additional behavioral details like pagination or response contents. With annotations covering the safety profile, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is clear, direct, and free of redundant information. It is highly efficient for an agent to parse and understand.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with one optional parameter and full schema coverage, the description is nearly complete. It lacks an explicit statement about the response format or that it returns VPC IDs, but the name and verb make this inferable. Minor gap, so a 4 is appropriate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the single optional parameter regionCode with a clear description of allowed values (KR, KRS). Since schema coverage is 100%, the description does not need to add parameter details, and the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and clearly names the resource 'VPCs available for Cloud DB for MongoDB', making the tool's purpose unambiguous. It distinguishes itself from sibling tools like ncloud_get_mysql_target_vpcs and ncloud_get_cache_target_vpcs by specifying the MongoDB service.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when listing VPCs for MongoDB, but it does not explicitly state when to use it over alternatives or provide any prerequisites or exclusions. The resource-specific wording gives some context, but there's no explicit guidance on when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_mssql_image_productsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description's 'List' action is consistent with that. The description adds context that results are engine versions, but doesn't disclose other behavioral traits like pagination or output format. With annotations covering safety, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the essential purpose without any filler. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, read-only list tool with one optional parameter and good schema/annotation coverage, the description is nearly complete. It could additionally state what the returned codes are used for (e.g., when creating an MSSQL instance), but the current text sufficiently covers the core function.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single optional parameter (regionCode) with a clear description and default behavior. The tool description adds no additional parameter semantics, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and identifies the exact resource ('available Cloud DB for MSSQL image product codes') with a clarifying parenthetical ('engine versions'). This clearly distinguishes it from sibling tools like ncloud_get_mssql_products or ncloud_get_mysql_image_products.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: use this tool when you need MSSQL image product codes (engine versions). However, it doesn't explicitly state when NOT to use it or mention alternatives like ncloud_get_mssql_products for compute products, so it lacks explicit guidelines.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_mssql_productsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safe read-only nature of the operation. The description adds that it lists product codes but does not disclose additional behavioral traits such as pagination, filtering, or permissions. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, succinct sentence that conveys the tool's purpose without unnecessary words. It is front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one well-documented parameter and readOnlyHint, the description is sufficiently complete. It does not need to explain return values in detail, though mentioning the product code output is implicit in 'product codes.' The prerequisite relationship with image product codes is covered in the parameter description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one required parameter with a clear description indicating it comes from ncloud_get_mssql_image_products. Schema coverage is 100%, so the description does not need to add further parameter detail. The baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and clearly identifies the resource as 'available Cloud DB for MSSQL server spec product codes.' This distinguishes it from sibling tools like ncloud_get_mysql_products or ncloud_get_mssql_image_products.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: if you need MSSQL server spec product codes, use this tool. However, it does not explicitly state when to use it over alternatives or mention when not to use it. The context is clear but lacks direct guidance or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_mssql_target_vpcsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this is a safe read operation, and the description does not add additional behavioral context such as response format, pagination, or default region behavior (the latter is already in the schema). No contradiction exists; the description is consistent 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that directly states the tool's purpose with no unnecessary words or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing tool with one optional parameter and no output schema, the description sufficiently conveys the purpose. The 'List' verb implies a return value, although it does not specify the exact structure of the VPC object returned. This is acceptable given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of the single parameter (regionCode) with a description including default behavior. The tool description adds no parameter-specific information beyond what is already in 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('VPCs') with a clear service qualifier ('for Cloud DB for MSSQL'), making it easy to distinguish from sibling target VPC tools for other database services (e.g., MySQL, PostgreSQL, MongoDB).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when the agent needs VPCs available for a MSSQL database, but it does not explicitly mention alternatives or provide when-to-use vs. when-not-to-use guidance. For a simple list tool this is adequate, but explicit sibling differentiation would improve clarity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_mysql_instance_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint: true already indicates a read-only operation, and the description's verb 'Get' is consistent. No additional behavioral context is provided, such as the return structure, any pagination, or permission requirements, so the description adds little beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a clear verb and resource. It contains zero waste or redundant phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple: one required parameter, no output schema, and read-only annotation. The description adequately conveys the purpose, though it does not enumerate what 'detailed information' includes. For a get-by-id tool, this is mostly sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema includes the required parameter cloudMysqlInstanceNo with a clear description 'Cloud MySQL instance number to query', giving 100% schema coverage. The description itself does not add further meaning to the parameter, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' and clearly identifies the resource as 'detailed information about a specific Cloud DB for MySQL instance'. This distinguishes it from the sibling list tool ncloud_list_mysql_instances and from detail tools for other database types like ncloud_get_postgresql_instance_detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternative tool is referenced, but the word 'specific' versus the sibling list tool implies this is for retrieving details of a single instance. The description does not name ncloud_list_mysql_instances as the alternative for enumerating instances, so guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_mysql_productsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description is consistent with the readOnlyHint=true annotation but adds no extra behavioral context beyond what annotations already provide. It does not mention pagination, output format, or any side effects. With annotations covering the read-only nature, the description adds some value by specifying the input dependency but lacks richer behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence that front-loads the action and resource. There is no wasted information, and it conveys the essential purpose efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with thorough parameter descriptions and a readOnlyHint annotation, the description is adequate. It could optionally clarify the return value format, but 'List' strongly implies a list of codes, and the schema already specifies the input dependency. Overall, it is complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters described in detail. The description directly references the required parameter ('image product code'), aligning with the schema's cloudMysqlImageProductCode. However, it does not add meaningful syntax or semantic details beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('List') and a specific resource ('Cloud DB for MySQL server spec product codes') with a clear scope ('for a given image product code'). It distinguishes this tool from sibling tools like ncloud_get_mysql_image_products and ncloud_get_postgresql_products by explicitly naming the MySQL server spec product code context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage in a workflow where an image product code is already known, but it does not explicitly state when to use this tool versus alternatives. No alternative tools are named, and no when-not-to-use guidance is provided. The prerequisite relationship is only hinted at by the phrase 'for a given image product code'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_nas_volume_rating_listA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description does not need to restate safety. The description adds the time-period scoping constraint but does not disclose other behavioral traits like response format or units. With annotation coverage, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is entirely front-loaded and contains no wasted words. It conveys the essential purpose without filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with fully documented parameters, the description is adequate. The absence of an output schema is not a major issue since the tool returns a list of measurements, though return value details (e.g., units) are not described. Overall, it is sufficiently complete given the annotations and schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already documents all four parameters with descriptions. The description's reference to 'specific time period' loosely maps to startTime/endTime but adds no new meaning beyond the schema. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool gets a NAS volume size measurement list for a specific time period, which is a specific verb+resource+scope. It clearly distinguishes from sibling tools like list_nas_volumes (lists volumes) and get_nas_volume_detail (volume details).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you need NAS volume size measurements over a time period. However, it does not explicitly mention alternatives or exclusions, leaving the agent to infer from the tool name and context signals.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_notification_recipientsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds Cloud Insight event alerts scoping but does not disclose output structure, pagination, or auth requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single front-loaded sentence with no filler. Every word contributes meaning and the core verb+resource pattern is immediately clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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, the description is adequate: it names the domain, the resource, and the expected outcome. It lacks return format detail, but 'list' provides a sufficient expectation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Tool has zero parameters and an empty input schema, so there is no parameter burden to document. The description correctly implies no inputs are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clear verb 'Get' with specific resource 'list of notification recipients' and scoping 'configured for Cloud Insight event alerts'. This distinguishes the tool from monitoring-related sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only states the function, leaving the agent to infer usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_pipelineA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already indicates safety, and the description adds that the output includes tasks and triggers, which is useful context. However, it does not disclose other behavioral aspects like return format, potential errors, or permissions, though the read-only nature is covered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the action and resource, followed by relevant detail about what information is included. There is no redundant wording or unnecessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only get-by-ID tool with one parameter and no output schema, the description is adequate. It conveys the purpose, the needed input, and the expected content (tasks and triggers). Given the low complexity, no additional context is essential, though a note about return format could make it slightly richer.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single parameter 'projectId' is well-described in the schema ('Pipeline ID (from ncloud_list_pipelines)'). The tool description does not add further parameter details beyond what the schema provides, but the schema itself is sufficient, so a baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get detailed information') and the resource ('a specific SourcePipeline pipeline'), with added specificity about what is included ('tasks and triggers'). This distinguishes it from sibling tools like ncloud_list_pipelines (which lists pipelines) and ncloud_get_pipeline_history_detail (which gets history details).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving details of a single pipeline, and the parameter description ('Pipeline ID from ncloud_list_pipelines') provides a workflow hint. However, it does not explicitly explain when to use this tool versus alternatives such as ncloud_list_pipelines for overviews or ncloud_get_pipeline_history_detail for historical run information.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_pipeline_history_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds minimal behavior beyond that—it does not disclose response format or any constraints, but for a simple get-detail tool this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no filler, front-loading the action and object clearly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only detail endpoint with two well-documented parameters, the description is adequately complete. It could specify the content of the returned history (e.g., stages, logs), but the absence of an output schema makes this less critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of the parameters with meaningful descriptions ('Execution history ID' and 'Pipeline ID'). The tool description does not add extra parameter context, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('detailed execution history for a specific pipeline run'), which clearly identifies the tool's function. It distinguishes itself from list-style tools like ncloud_list_pipeline_history by emphasizing 'specific pipeline run'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for retrieving details of a particular pipeline run, but it does not explicitly state when to use it versus listing histories or getting pipeline definitions, nor does it mention alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_placement_group_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation. The description adds minimal behavioral context beyond what the annotation and name convey, such as what 'detailed information' includes or any error/precondition behavior. There is 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence with no filler or redundant information. It front-loads the action ('Get') and resource ('specific placement group') efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only get-by-ID tool with one parameter and no output schema, the description provides sufficient context to understand its purpose. However, it does not enumerate what details are returned or mention any prerequisites beyond the parameter, leaving some ambiguity for an agent expecting richer output.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the sole parameter placementGroupNo is described as 'Placement group number to query'. The tool description does not add extra semantics about the parameter's origin or format, so it is adequate but not enhanced.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource 'specific placement group', distinguishing it from sibling tools like ncloud_list_placement_groups. It precisely indicates this is a detail lookup for one placement group, not a list or mutation operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The word 'specific' implies the caller needs a placementGroupNo and that this is for a single entity, but there is no explicit guidance on when to use this versus list_placement_groups or other placement group tools. No alternatives or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_product_price_listA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true already declared, the description adds useful behavioral context: pagination defaults (50/page, sorted by productCode), response fields (totalRows/returnedRows/hasMore/nextPageNo), and the truncated=true flag behavior. This goes beyond the annotation without contradicting it, though it doesn't mention rate limits or other potential constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise, containing just two sentences. It front-loads the purpose and then packs pagination details and response field explanations into the second sentence, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description covers the key return fields and pagination mechanics, making it complete for a read-only listing tool. It could have mentioned the required regionCode, but that is already in the schema. Overall, it provides enough context for an agent to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with each parameter already described in detail. The description adds minor context (e.g., sorting by productCode) but does not need to explain parameters. It contributes marginal value beyond the schema, consistent with the baseline for full coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets a 'product and price list' with specific content (monthly/hourly rates, conditions, discounts). It uses a clear verb+resource structure. However, it does not explicitly differentiate from sibling tools like ncloud_get_product_list or ncloud_get_price_list, though the combined scope is implied by the name and content.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides strong usage guidance on pagination, telling users to 'follow nextPageNo to page through all results' and explaining the default page size and sorting. However, it does not explicitly state when to use this tool vs alternatives (e.g., ncloud_get_price_list), leaving the context 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.

• ncloud_get_product_schemaA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds that the schema includes 'metrics and dimensions,' which is useful context, but it does not disclose return format, pagination, required permissions, or any other behavioral traits. Since annotations cover the safety profile, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no unnecessary words. It front-loads the action ('Get') and includes the essential context without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple getter with two parameters and no output schema, the description is mostly complete. It clearly identifies the target (product schema) and the domain (Cloud Insight). However, it could optionally mention that the response contains the schema details, but this is already implied by 'schema definition.' No major gaps exist for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both cw_key and prodName have descriptions in the input schema. The tool description itself does not add any parameter-level detail beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get the schema definition for a specific product in Cloud Insight (metrics and dimensions).' It uses a specific verb ('get'), names the resource ('product schema'), and specifies the context ('Cloud Insight'). This distinguishes it from sibling tools like ncloud_get_schema_keys, which focuses on keys rather than full schema definitions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need a product's schema (e.g., 'for a specific product'), but it does not explicitly state when to use this tool versus alternatives, nor provide any exclusions or prerequisites. No additional guidance about selecting this over related tools like ncloud_get_schema_keys or ncloud_get_product_list is offered.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_public_ip_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description is consistent with the readOnlyHint annotation (no contradiction). However, it adds no extra context such as authentication requirements, error conditions, or what 'detailed information' includes, so it adds minimal value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-ID tool with one parameter and a read-only annotation, the description is adequate. However, since there is no output schema, it could mention what details are returned, but the tool's simplicity makes this a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (the single parameter publicIpInstanceNo is described as 'Public IP instance number'). The tool description adds no additional semantic meaning beyond what the schema already provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('detailed information about a specific public IP instance'). It clearly differentiates from sibling tools like list_public_ips (which lists all) and get_public_ip_target_servers (which targets servers).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving details of a single public IP instance, but does not explicitly state when to use it over alternatives or provide exclusions. No explicit when-to-use/when-not-to-use guidance is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_route_table_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description is consistent with the readOnlyHint annotation, confirming this is a safe read operation. However, it adds minimal behavioral context beyond the annotation, such as the specific target of the query, and does not disclose what 'detailed information' includes or any limitations. The annotation reduces the burden, but the description still lacks richer behavioral detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that immediately states the verb and resource. It contains no redundant information or filler, making it highly scannable and appropriate for a simple read operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward read operation with one parameter and a readOnlyHint annotation, the description is largely sufficient. However, since there is no output schema, the description does not hint at the response structure or clarify what 'detailed information' encompasses (e.g., routes, subnets), which would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full coverage for the single routeTableNo parameter with a clear description ('Route table number to query'). The tool description adds no additional meaning or guidance for this parameter, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb/resource combination ('Get detailed information about a specific route table') that clearly identifies the action and scope. It distinguishes well from sibling tools like ncloud_list_route_tables and ncloud_get_routes by emphasizing the singular, detailed nature of the query.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving details of a single route table based on its wording, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. No alternative tools are mentioned, leaving the agent to infer the appropriate context from the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_route_table_subnetsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already establishes this is a safe read operation, and the description's 'List subnets' is consistent. The description adds the scoping detail of a 'specific route table' but does not disclose additional behavioral traits like response format, pagination, or error conditions, which is acceptable given the simple read-only nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, front-loaded with the action and object. It contains no redundant or filler content and is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with one parameter and readOnlyHint annotation, the description adequately covers purpose and scope. 'List subnets' implies the return value is a list, and without an output schema, no further return details are required. The description is complete enough for this low-complexity tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — the parameter routeTableNo is already described as 'Route table number' in the input schema. The tool description adds no extra semantic detail beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' with resource 'subnets' scoped by 'associated with a specific route table', clearly indicating the operation. It distinguishes from sibling mutation tools like ncloud_add_route_table_subnet and ncloud_remove_route_table_subnet, as well as ncloud_get_routes which returns routes rather than subnets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context: use this tool when you need to see which subnets are attached to a route table. However, it does not explicitly mention alternatives or when not to use it, such as referencing sibling tools for adding/removing subnets or noting that route table detail might contain similar info.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_rule_groupA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the operation as read-only. The description adds domain context ('Cloud Insight event rule group') but no additional behavioral traits such as error behavior, response format, or data included. With annotations present, the bar is lower, and it does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence with no redundant information. It is front-loaded with the verb and resource, earning its place fully.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (1 parameter, no output schema, readOnly annotation), the description and schema together provide adequate context for correct invocation. It could specify what 'detailed information' includes, but this is not essential for a simple get-by-id operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the parameter ruleGroupId is already clearly described as 'Rule group ID to retrieve details for'. The tool description adds no additional meaning beyond what the schema provides, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' and explicitly identifies the resource as a 'specific Cloud Insight event rule group', clearly distinguishing it from list-type operations. The modifier 'specific' signals a singular retrieval, which differentiates it from ncloud_list_rule_groups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a particular rule group ID is known, but it does not explicitly state when not to use it or mention alternatives like ncloud_list_rule_groups. The context is present but only implied, not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_rules_by_metrics_groupA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description need not repeat safety. It adds the context that these are event rules tied to rule template (metrics group) IDs, but doesn't disclose any further behavioral details like pagination or response structure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence of 14 words, front-loaded with the action and object. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read operation with one documented parameter and a readOnly annotation, the description plus schema cover the essentials. It doesn't describe the return format, but with no output schema and a 'Get' verb, that's not a critical gap for a competent agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter metricsGroupIds is fully documented in the schema (100% coverage), so the description doesn't need to explain it further. The tool description repeats the parameter concept but adds no additional semantics about how to obtain or format the IDs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and names the resource ('Cloud Insight event rules') with a clear filter ('by metrics group IDs'). It distinguishes from the sibling 'ncloud_get_rules_by_monitor_group' by specifying the grouping dimension.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied: use this tool when you need rules filtered by metrics group IDs. However, it doesn't explicitly state when not to use this tool or mention the alternative 'ncloud_get_rules_by_monitor_group' for monitor group-based queries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_server_image_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation, so the description's addition of 'detailed information' and 'specific' provides minimal extra behavioral context. It does not disclose response format, error behavior, or field details, but given the annotation and the simplicity of the operation, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded with the action and resource. Every word contributes to the meaning, with no redundant phrasing or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple one-parameter input, the presence of readOnlyHint, and the clear subject matter, the description is mostly complete. The absence of an output schema means the description could have specified what 'detailed information' includes, but the phrase 'detailed information about a specific server image' is sufficient for an agent to understand the tool's purpose and select it appropriately.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the sole parameter 'serverImageNo' described as 'Server image number to query' in the schema itself. The tool description adds no additional meaning 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get detailed information about a specific server image' uses a specific verb ('get'), a clear resource ('server image'), and scope ('specific'), which accurately distinguishes it from sibling list tools like ncloud_get_server_images. Although it doesn't explicitly mention alternative detail tools, the name and description unambiguously identify the operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need details for an individual image, but it provides no explicit guidance on when to use this tool versus alternatives such as ncloud_get_server_images for listing or ncloud_get_member_server_image_detail for member images. No exclusions or alternative suggestions are given, making the usage context clear but not explicitly articulated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_snapshot_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation. The description adds 'detailed information,' which implies a response with snapshot details, but it does not disclose additional behavioral traits such as response format, required permissions, or error conditions. Given the annotation coverage, this is adequate but minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action and resource. No extraneous words or repetitions; every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple one-parameter, read-only detail retrieval tool. The description adequately conveys the core purpose. While there is no output schema, the phrase 'detailed information' hints at the return type. For such a straightforward tool, the description is sufficiently complete, though it could specify what details are returned.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with a clear description for the single parameter ('Block storage snapshot instance number to query'). The tool description adds no additional meaning beyond the schema, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and clearly identifies the resource ('detailed information about a specific block storage snapshot instance'). It distinguishes this tool from sibling tools like ncloud_list_snapshots (listing) and ncloud_create_snapshot (creation).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied: use this when you need details of a specific snapshot instance. However, there is no explicit mention of when to use this over alternatives (e.g., when you already have the snapshot instance number vs. needing to list snapshots first). No exclusions or alternative tool references are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_sub_account_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already communicates that this is a safe read operation. The description adds minimal behavioral context—it indicates the query targets one sub account—but does not describe response format, potential errors, or data returned, so the description contributes little beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that conveys the essential purpose without any redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, one-parameter read-only detail query, the description is mostly sufficient alongside the schema and readOnlyHint. However, since there is no output schema, some indication of what 'detailed information' includes would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully covers the single parameter with a clear description ('Sub account ID to query'), so the description adds no meaningful extra semantics. This meets the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the resource ('detailed information about a specific sub account'). It is distinguished from sibling tools like ncloud_list_sub_accounts by emphasizing 'specific', making its purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is only implied by the word 'specific', which suggests this is for a particular sub account rather than listing all. No explicit guidance on when to use this over alternatives like ncloud_list_sub_accounts, or any exclusions, is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_subnet_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already signals this is a safe read operation. The description 'Get detailed information' is consistent with that and adds no additional behavioral context such as return format, pagination, required permissions, or rate limits. With the annotation covering safety, the description adds only slight value by clarifying it targets a specific resource rather than a broad query.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence that conveys the essential purpose without any extraneous words. Every word earns its place, and it's front-loaded with the verb and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, single-parameter, read-only tool with no output schema, the description is nearly complete. It clearly states what the tool does. However, it doesn't hint at what kind of 'detailed information' is included (e.g., VPC, network ACL, status), though such details are often implied by domain knowledge. A minor gap, but acceptable for this simplicity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the only parameter subnetNo is described as 'Subnet number to query' in the schema itself. The tool description repeats no further parameter details, so it adds no meaning beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get detailed information about a specific subnet' uses a specific verb ('Get') and a clear resource ('subnet'), and it distinguishes itself from the sibling tool ncloud_list_subnets by targeting a single subnet rather than listing all. The scope is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when you need details about one specific subnet), but it does not explicitly mention alternatives or exclusions. For example, it doesn't state 'Use ncloud_list_subnets to find subnet numbers' or contrast with list operations. Guidance is minimal beyond the name and purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_target_group_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation, so the description doesn't contradict it. However, the description adds minimal behavioral context beyond the annotation—it doesn't mention what 'detailed information' includes, whether the response is paginated, or any error conditions. Since the safety profile is handled by annotations, the lack of extra behavioral detail is acceptable but not exemplary.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single succinct sentence, front-loaded with the action and resource. No filler or redundant explanation. It earns every word and is instantly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read tool with readOnlyHint and no output schema, the description is nearly complete. It clearly identifies the resource and action, but doesn't specify what 'detailed information' comprises (e.g., health checks, load balancer associations, protocol). This small gap prevents a 5, but it's adequate for a straightforward get-by-id operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the single parameter targetGroupNo with description 'Target group number to query', giving 100% schema coverage. The tool description adds little beyond the schema's 'specific target group' phrasing, merely reinforcing the need for an identifier without providing extra format, source, or prerequisite details. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get detailed information about a specific target group' uses a clear verb ('Get') and resource ('detailed information about a specific target group'), distinguishing it from sibling tools like ncloud_list_target_groups (which lists all groups) and modification tools (change/create/delete). The scope is precise: a single identified target group.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'specific target group' implies the caller must already know the targetGroupNo, but no explicit alternatives or exclusions are given. It doesn't state that ncloud_list_target_groups should be used first to find the number, nor does it contrast with related detail tools like ncloud_get_load_balancer_detail. The usage context is only implied, not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_vpc_peering_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds little behavioral context beyond 'detailed information' and does not mention response structure, pagination, or error behavior. With annotations covering the primary safety trait, a neutral score is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded with the verb and resource. No filler words, and every word contributes to clarity. It is appropriately sized for a simple get-detail tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (1 parameter, no output schema, readOnly annotation), the description is mostly sufficient. It clearly states the tool's function and required identifier. However, it does not explicitly mention the relationship to list_vpc_peerings or what the returned 'detailed information' includes, which is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single parameter 'vpcPeeringInstanceNo', which is already described as 'VPC Peering instance number to query'. The tool description does not add extra meaning beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('detailed information about a specific VPC Peering instance'), clearly indicating this is a detail-fetch operation for a single peering. It distinguishes from sibling 'list_vpc_peerings' by emphasizing 'specific', making the tool's scope unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied: to retrieve details for a known VPC Peering instance number. However, there is no explicit when-to-use advice, mention of prerequisites (e.g., obtaining the instance number from list_vpc_peerings), or exclusion of alternatives. This earns a 'implied usage' score rather than higher.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_globalcdn_get_usageA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already conveys the read-only nature. The description adds context about the data type (transfer/traffic volume) and the parameter scope (multiple instances, time range), which is useful but minimal. It does not disclose return format, pagination, or any potential side effects beyond what the annotation covers, so it does not significantly exceed the annotation-provided transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  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, then adds the key qualifiers (instances and time range). Every word earns its place, with no redundant or unrelated information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 well-documented parameters and a readOnlyHint annotation, the description sufficiently communicates the tool's purpose and scope. While there is no output schema and the description does not describe the return format, the data type is implied by the description, making it complete enough for an agent to invoke correctly. A minor gap is the lack of detail on response structure, but the simplicity of the operation mitigates this.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% parameter description coverage, with clear descriptions for startDate, endDate, and cdnInstanceNoList. The description adds no additional parameter detail beyond the schema, so the baseline of 3 applies, indicating the schema handles parameter semantics adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get'), the resource ('Global CDN usage data'), and the scope ('for one or more instances over a time range'). The parenthetical '(transfer/traffic volume)' distinguishes it from sibling tools like monitoring or list instances, making it unambiguous which tool to select.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on what the tool does, allowing an agent to infer when to use it (when usage data over a time range is needed). However, it does not explicitly mention alternatives or exclusion cases, such as 'use get_monitoring instead for performance metrics', so it falls short of providing explicit when-to-use vs. 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.

• ncloud_gtm_get_map_typesA
  3.8/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description is limited to the tool's purpose and adds no behavioral details beyond the readOnlyHint annotation, such as return format, pagination, or any constraints. It does not contradict the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no filler or redundant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description adequately covers the tool's simple zero-parameter read-only purpose, but lacks any detail about the structure of the returned map types. Given the absence of an output schema, slightly more context could be helpful, but it remains functionally sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool accepts zero parameters and the schema has 100% coverage, so the description need not elaborate on parameters. Baseline of 4 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and identifies the exact resource ('available Geo and CIDR map types') within the Global Traffic Manager scope, clearly distinguishing it from sibling tools like ncloud_gtm_get_resource_types and ncloud_gtm_get_lb_types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage to retrieve map types but provides no explicit guidance on when to use this tool versus alternatives, such as listing actual Geo CIDR maps or getting resource types. No exclusions or conditions are stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_gtm_get_profile_detailA
  3.8/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already communicates that this is a safe read operation, and the description's 'Get detailed information' is consistent with that. However, the description adds no additional behavioral context such as required permissions, pagination, error conditions, or what details are returned. It provides no value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's function without repetition or fluff. Every word contributes to understanding the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with only one parameter, a read-only annotation, and no output schema, the description provides enough information to know what the tool does and which resource it targets. It does not describe the return format, which is a minor gap, but overall it is reasonably complete for its simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter domainId is fully described in the schema with 100% coverage, so the schema carries the meaning. The description does not add any additional elaboration about the parameter, such as how to obtain it or any constraints. Baseline of 3 applies due to high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get detailed information' and identifies the resource as 'specific Global Traffic Manager profile (domain)', clearly distinguishing it from list operations and policy tools. The word 'specific' indicates this is for a single entity, and the parenthetical '(domain)' disambiguates the resource type from other GTM elements.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it clear that this tool is for retrieving details of a specific profile, which gives an implied use case. However, it does not explicitly state alternatives, exclusions, or prerequisites like obtaining the domainId from a list call. The context is clear enough for a simple tool, but lacks explicit 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.

• ncloud_gtm_list_geo_cidr_mapsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already covers the operation's safety, and the description adds the pagination behavior. It does not disclose return format or ordering, but for a simple list operation with read-only annotations, this is adequate. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single front-loaded sentence that directly states the action and resource. No filler words; every term (List, Global Traffic Manager, Geo and CIDR maps, optional pagination) is informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with two optional parameters, the description plus schema provides a complete operational picture. However, the lack of an output schema and any mention of response details means the agent must infer what fields are returned, though this is typical for list operations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully documented in the schema with defaults (page=0, size=20), so the description's mention of 'optional pagination' adds little. The description does not provide additional context beyond the schema's property descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and identifies the resource as 'Global Traffic Manager Geo and CIDR maps', clearly stating the operation. It distinguishes from sibling tools like ncloud_gtm_get_geo_cidr_map_detail, which retrieves a single map, and create/update/delete tools, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for enumerating Geo and CIDR maps but does not explicitly contrast with alternatives or state when to use pagination. No exclusions or prerequisites are mentioned, leaving the agent to infer from the tool name and sibling context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_gtm_list_policiesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description's 'List' is consistent. The description adds that pagination and filters are optional, which is slight extra context, but this mostly restates what the schema already documents. No additional behavioral traits (e.g., default page size, return format, rate limits) are disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single front-loaded sentence with no wasted words. It conveys the action, resource, and key capability (pagination/filters) efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple read-only list tool with 5 optional, fully documented parameters and a readOnlyHint annotation. While there is no output schema, the description's 'List policies' adequately implies a list of policy objects is returned. It could mention default pagination values or return shape, but for a straightforward list operation, the coverage is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% - each of the 5 parameters has a clear description. The tool description only summarizes them as 'optional pagination and filters', adding no new meaning beyond what the schema provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 'Global Traffic Manager policies' and scoping qualifiers 'with optional pagination and filters'. This distinguishes it from sibling tools like ncloud_gtm_get_policy_detail (single policy) and ncloud_gtm_list_profiles (different resource).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use as a listing operation is implied by the verb 'List', but there is no explicit guidance on when to use this tool versus alternatives such as ncloud_gtm_get_policy_detail or ncloud_gtm_list_profiles. No exclusions or comparison to other tools are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_gtm_list_profilesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes that this is a safe read operation, lowering the bar. The description adds a useful clarification that profiles are domains and mentions pagination/filtering, but it does not disclose return format, ordering, or potential edge cases beyond what the schema and annotation already convey. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the operation and resource. It is concise, clear, and contains no redundant or filler wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with three optional parameters and no output schema, the description adequately captures the resource type and available filters. It could be slightly more complete by explicitly pointing to the detail tool for full profile information, but it is sufficient for a straightforward listing use case.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents the three parameters. The description merely restates the name filter and pagination without adding new meaning, constraints, or examples beyond what is already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and a specific resource ('Global Traffic Manager profiles (domains)'), and it clarifies scope with optional pagination and name filter. This clearly distinguishes it from sibling tools like ncloud_gtm_list_policies and ncloud_gtm_get_profile_detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The verb 'List' implies the primary use case of enumerating profiles, and sibling detail/create/update tools are natural alternatives by naming convention, but the description gives no explicit guidance on when to choose this tool over those alternatives or when to apply the optional filters. It provides context but no exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_hadoop_list_image_productsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, which the description aligns with by using 'List'. The description adds the detail that results are engine versions, which is some extra context. However, it does not disclose any additional behavioral traits like return format, pagination, or region filtering behavior, relying mostly on the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, succinct sentence (7 words) that is front-loaded with the verb and object. It contains no filler or redundant information, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one optional parameter and no output schema, the description provides adequate context to understand its purpose and differentiate it from siblings. It is not overly detailed, but it is sufficient for an agent to select and invoke the tool correctly, especially with the read-only annotation and schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has only one parameter (regionCode) with 100% description coverage; the description does not need to elaborate on parameters. The baseline of 3 applies since the schema fully documents the parameter, and the description adds no redundancy or additional meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'List available Cloud Hadoop image products' with a parenthetical clarification 'engine versions', which distinguishes this tool from sibling tools like ncloud_hadoop_list_products (likely hardware products) and ncloud_hadoop_list_cluster_types. The verb 'List' and specific resource make the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is used when you need to list Hadoop image products/engine versions, but it does not explicitly state when to use it over alternatives or mention any prerequisites. It provides enough context for basic selection but lacks explicit guidance on when to prefer this tool over similar list tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_hadoop_list_mysql_usersA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, which is consistent with the description. The description does not disclose any additional behavioral traits such as filtering behavior, pagination, or the specific set of users returned. It adds no behavioral context beyond what annotations already guarantee, but it does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no superfluous words. It front-loads the verb and resource, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with well-documented parameters and annotations, the description is mostly sufficient. However, it lacks any detail about the response format or how the listed users relate to the Hive metastore configuration workflow, which would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both parameters ('regionCode' and 'cloudMysqlInstanceNo') have clear descriptions. The tool description adds no additional meaning to the parameters, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb (List) and resource (MySQL users) with a clear qualifier 'for Hive metastore integration', which distinguishes it from the general 'ncloud_list_mysql_users' tool and sibling Hadoop tools like 'ncloud_hadoop_list_mysql_instances'. The purpose is immediately clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context ('for Hive metastore integration') but does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or mention of sibling tools like test_hive_metastore or save_hive_metastore. The context is helpful but not actionable as guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_hadoop_list_notebook_bucketsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description's 'List' verb aligns with that. The description adds the scope constraint ('available for Cloud Hadoop notebooks'), but provides no additional behavioral details such as pagination, required permissions, or default region behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the essential purpose with no wasted words. Every word contributes to understanding the tool's scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity, read-only annotation, and fully described schema parameters, the description is sufficient for an agent to understand the tool's core behavior. It does not explain return values, but no output schema exists and this is a simple list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters ('Region code', 'Cloud Hadoop instance number'). The description does not add meaning beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('Object Storage buckets') with a clear scope ('available for Cloud Hadoop notebooks'). This distinguishes it from siblings like ncloud_hadoop_list_buckets by limiting to notebook-available buckets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'available for Cloud Hadoop notebooks' implies when to use this tool, but it does not explicitly state alternatives, prerequisites, or when not to use it. There is no mention of how this differs from related bucket-listing tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_delete_acl_ruleA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description reinforces this with a prominent ⚠️ Destructive warning. It adds the critical behavioral requirement that confirm=true must be set to execute, which is beyond what annotations alone provide; no contradiction 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single front-loaded sentence that includes a warning symbol and a direct execution instruction. Every element earns its place with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive delete tool, the annotations and schema cover safety and parameters, while the description covers the operation and confirmation requirement. It does not explain how to obtain ruleId or post-deletion behavior, but these are not essential given the rich schema and sibling tool context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% parameter coverage with descriptions for keyTag, ruleId, and confirm, so the description need not repeat those details. It adds only the confirm=true execution hint, which is already stated in the schema, yielding no extra semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool removes an IP address from the ACL rules for a KMS key, with a specific verb and resource. It implies the delete operation in contrast to sibling add/get ACL tools, though it does not explicitly mention alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (to remove an IP from a KMS key's ACL) and provides the key instruction to set confirm=true to execute. However, it does not mention alternatives like ncloud_kms_add_acl_rule or list-first prerequisites, so usage guidance is 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.

• ncloud_kms_disable_key_versionA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the behavioral consequence that disabled versions cannot decrypt data encrypted with that version, which is valuable context beyond annotations. However, it does not mention whether encryption operations are also affected or whether re-enabling is possible.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences front-load the action and follow with the key consequence. 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with full schema coverage and informative annotations, the description covers the purpose and the material effect on decryption. It doesn't address return behavior or edge cases, but no output schema exists and the annotation covers idempotency. Slight gap about whole-key vs version disabling is more relevant to usage guidelines.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description covers both parameters 100% (keyTag as unique identifier, version as version number). The description adds no additional detail about parameter semantics beyond what schema already provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states verb+resource+scope: 'Disable a specific version of a KMS key'. The consequence sentence adds useful context that distinguishes it from disabling the entire key or enabling versions, though it doesn't name siblings explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case: targeting a specific version of a KMS key. It does not explicitly state alternatives like `ncloud_kms_disable_key` for whole-key disablement, nor does it state when not to use this tool. The context is clear but lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_enable_ip_aclA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations (idempotentHint=true, destructiveHint=false) already communicate safety, and the description aligns with them by describing an enable action. The description adds the behavioral context that the IP ACL controls which IP addresses can request tokens, but it does not disclose side effects such as whether existing ACL rules are preserved or whether it affects active requests. Given the annotations cover safety, this adds some but not rich behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states the action ('Enable IP ACL') and its purpose without any wasted words. It is appropriately concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple: one required parameter fully described in the schema, annotations provide the safety profile, and no output schema is needed for an enable action. The description sufficiently explains what the tool does and why it would be used. However, it does not describe return values or any prerequisites beyond keyTag, but given the low complexity, this is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% because the single parameter keyTag is fully described in the input schema ('Key tag - unique identifier derived from key name'). The tool description does not mention the parameter, but since the schema already carries the meaning, the baseline of 3 applies. No additional parameter semantics are provided beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Enable' and identifies the resource 'IP ACL' with a clear purpose: 'to control which IP addresses can request tokens for a KMS key.' This distinguishes it from the sibling tool ncloud_kms_disable_ip_acl, which performs the opposite action. The verb+resource combination makes the purpose immediately clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool's usage: enable IP ACL when you need to restrict token requests to certain IP addresses. However, it provides no explicit guidance on when to use this tool versus alternatives like ncloud_kms_add_acl_rule or ncloud_kms_disable_ip_acl, nor does it mention any exclusions or prerequisites. It offers clear context but no direct alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_get_key_infoA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, signaling a safe read operation. The description adds that the tool returns 'detailed information' for one key, but does not elaborate on the exact data returned, permission requirements, or error behaviors. It is consistent with annotations and adds minimal context beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant wording. Every word contributes to identifying the operation and its target resource, making it highly concise and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only lookup, the description is functionally sufficient to guide selection and invocation. A minor gap is that 'detailed information' is vague and there is no output schema, so the agent cannot anticipate the returned fields or structure.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers the keyTag parameter fully with a clear description ('unique identifier derived from key name'). The tool description merely restates 'by its keyTag' without adding further format, provenance, or usage nuance, so it adds no value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb ('Get detailed information') plus resource ('KMS key') and identifier ('keyTag'), making the tool's purpose unambiguous. It clearly distinguishes from sibling tools like ncloud_kms_get_key_list or ncloud_kms_get_key_version_list, which serve different retrieval scopes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for retrieving details of a single key when keyTag is known, but it does not explicitly state when to use this instead of alternatives such as ncloud_kms_get_key_list or ncloud_kms_get_key_version_list. No exclusions or alternative naming are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_update_token_generatorA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, lowering the bar. The description adds behavioral context by stating it 'Generates a new secret for token creation,' which clarifies the core effect. However, it does not discuss potential side effects (e.g., invalidation of existing tokens) or other operational details, so it only partially expands on 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences (19 words) with the action verb first and the effect immediately after. Absolutely no filler; every word contributes to understanding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple tool with one parameter, full schema coverage, and annotations for safety. The description explains the operation and its outcome, which is sufficient for an agent to invoke it correctly. It lacks explicit sibling differentiation, but that is already addressed in purpose clarity, and the simplicity of the tool limits the need for further context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: keyTag is described as 'Key tag - unique identifier derived from key name.' The tool description redundantly mentions 'KMS key,' but the schema already conveys the meaning. No additional syntax or format details are provided, so the description adds minimal value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Update (rotate)') and resource ('token generator for a KMS key'), clearly distinguishing this from sibling tools like create/get/delete token generator. It also explains the effect: 'Generates a new secret for token creation.' This is unambiguous and specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied through 'Update (rotate)' – it is for rotating an existing token generator, not creating or deleting one. However, it does not explicitly state when to use this tool versus alternatives or mention exclusions, so guidance is only implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_acgsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already establishes that this is a safe read operation, so the description does not need to repeat that. The description adds the 'current region' scope, which is a useful behavioral constraint. However, it does not disclose additional behavioral traits such as pagination defaults, performance implications, or what happens when no region is configured. Since annotations cover the safety profile, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that front-loads the action and resource: 'List all Access Control Groups (ACGs) in the current region'. It contains no filler, redundancy, or irrelevant details. Every word contributes to defining the tool's purpose and scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool (a list operation with optional filters) and the high schema coverage, the description is nearly complete. The lack of an output schema means the description does not need to explain return values. The only gap is that it does not mention pagination behavior, but the schema covers pageNo/pageSize semantics. Overall, the context provided by description + schema + annotations is sufficient for invoking the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All six parameters are fully described in the schema (100% coverage), including types and specific descriptions like 'Filter by VPC number' and 'Page number for pagination (0 or 1 for first page)'. The description itself adds no parameter-specific meaning beyond the schema. Per the guideline, when schema coverage is high, a baseline of 3 is appropriate even without additional parameter details in the description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('List'), the resource ('Access Control Groups (ACGs)'), and the scope ('in the current region'). It distinguishes the tool from sibling tools like ncloud_get_acg_detail and ncloud_create_acg by conveying a list-all operation. The phrase 'all' also indicates that the default behavior is to return all ACGs, with optional filters available via parameters.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied: one uses this tool when they need to list ACGs in the current region. However, the description does not explicitly mention alternatives, such as using ncloud_get_acg_detail for a single ACG or ncloud_get_acg_rules for rules. It also doesn't state any prerequisites or when filtering would be appropriate, though the parameter schema offers filter options. This is a clear but not fully guided context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_asgsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the 'current region' scoping context, which is useful. However, it does not disclose pagination behavior, default page sizes, or what fields are returned, and the readOnlyHint annotation already covers the safety profile. No contradictions exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence with a clear verb and object, no filler words. It is front-loaded and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with four optional parameters and a readOnly annotation, the description is mostly adequate. It could mention that it returns a list of ASGs and that pagination is supported, but the schema already exposes the parameters and the operation type is obvious. Slightly incomplete regarding return value specifics, hence 4.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with descriptions for pageNo, pageSize, autoScalingGroupName, and autoScalingGroupNoList. The tool description adds no parameter-specific details beyond what the schema already provides, so it lands at the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and resource 'Auto Scaling Groups' with a scope of 'current region', clearly distinguishing it from sibling tools like ncloud_get_asg_detail (for a single ASG) and ncloud_create_asg (for creation).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives, such as ncloud_get_asg_detail for detailed information or ncloud_list_asg_activity_logs for activity logs. Usage is implied by the name and phrase 'List all Auto Scaling Groups', but no when-not or alternative instructions are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_av_eventsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  readOnlyHint is already provided, indicating a safe read operation. The description adds the subscription prerequisite but does not disclose rate limits, pagination, or response behavior. Since the annotation covers the safety profile, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single succinct sentence with no filler. Clearly front-loaded with the verb and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with comprehensive schema descriptions and a readOnlyHint annotation, the description sufficiently identifies the data source, event type, and subscription requirement. It doesn't detail output structure, but no output schema is provided and the tool type is well-understood.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has 100% description coverage across all 10 parameters, so parameter meaning is already well-documented. The description itself does not add parameter semantics, so baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists Anti-Virus malware detection events from Security Monitoring, using the specific verb 'List' and a specific resource type. It distinguishes itself from sibling event-listing tools (e.g., ncloud_list_ids_events, ncloud_list_waf_events) by focusing on AV events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context (AV malware detection events) and adds an eligibility constraint (Security Monitoring subscription). However, it does not explicitly contrast with alternative event-listing tools or provide when/when-not guidance beyond the subscription requirement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_cache_instancesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already covers the safety profile. The description adds the useful 'current region' scope constraint, but does not disclose pagination behavior, response format, or whether instances are returned regardless of status. With annotations reducing the burden, the description provides some but limited behavioral context, warranting a 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action and resource. It includes the clarifying parenthetical '(Redis/Valkey)' for precision, and contains no wasteful words. This is exemplary for a list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation, the description covers the core purpose (list cache instances), the scope (current region), and the service (Cloud DB for Cache). The schema documents all parameters and the annotation indicates read-only safety. The main gap is the absence of an output schema or a note about pagination/default response, but this is not a significant deficiency given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and every parameter (pageNo, pageSize, cloudCacheServiceName, cloudCacheInstanceNoList) has a description. The tool description itself does not add any parameter-specific semantics, but the schema fully documents them. The baseline for high schema coverage is 3, and the description does not go beyond that.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses an explicit verb and resource: 'List all Cloud DB for Cache (Redis/Valkey) instances' and adds a scope qualifier 'in the current region.' This clearly identifies the operation and distinguishes it from sibling tools like ncloud_get_cache_instance_detail (which fetches a single instance) and listing tools for other services.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context through 'List all' but provides no explicit guidance on when to use this tool versus alternatives. It does not mention that ncloud_get_cache_instance_detail should be used for a single instance, nor does it specify when not to use this tool. The context is clear but not explicit, so a score of 3 is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_export_bucketsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation is consistent with the 'List' operation, and the description does not contradict it. However, it adds little behavioral context beyond the annotation, such as return format or pagination. For a simple list operation, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that immediately states the action and resource. It contains no unnecessary information or redundancy, making it highly concise and effectively front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one optional parameter, read-only, no output schema), the description provides sufficient context for an agent to understand its purpose. It could mention expected return values, but for a basic list operation used in a specific context, it is mostly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with the regionCode parameter explicitly described as 'Region code (default kr)'. The description does not need to add parameter details, and the schema fully documents the only parameter, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action (List), the resource (Object Storage buckets), and the specific context (available as log export targets in Cloud Log Analytics). This distinguishes it from general bucket listing tools like ncloud_list_buckets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for finding buckets that can be used as log export targets, but it does not explicitly state when to use it versus alternatives or provide exclusions. The context is clear enough to infer usage, but no direct guidance on alternatives is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_fabric_clustersA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the agent knows this is safe read-only. The description adds the 'current region' scoping and 'all' behavior, but doesn't disclose filtering capabilities, pagination, or return format. It adds some value beyond annotations but not rich behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise, front-loaded sentence with zero wasted words. It states the operation, target, and scope efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple read-only list operation with no required parameters, no output schema, and strong annotation coverage. The description plus annotations adequately cover the tool's purpose and constraints for an agent to use it effectively. It could mention optional filters, but the schema fills that gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both optional filter parameters (fabricClusterName, fabricClusterNoList) thoroughly described in the schema. The description adds no extra meaning beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' with resource 'fabric clusters' and scope 'current region', clearly distinguishing it from sibling tools like get_fabric_cluster_detail or pool management tools. It is immediately obvious what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (when you need to list clusters in the current region) but provides no explicit when-to-use guidance, exclusions, or alternatives. Without mentioning when to prefer this over get_fabric_cluster_detail or other cluster tools, usage context is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_integrationsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this is a safe read operation. The description adds the paging behavior (though that is also reflected in the pageNum/pageSize parameters) and clarifies it returns a list. It does not contradict annotations and provides minimal additional context beyond what annotations and schema already convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that immediately states the action and resource. It avoids redundant phrasing and every word contributes meaning. It is optimally concise for a simple list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with no required parameters and no output schema, the description adequately conveys what the tool returns (a list of integrations) and that it is paged. It does not explain the return structure in detail, but for this low-complexity tool, the description plus schema 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema documents all three parameters (query, pageNum, pageSize) with descriptions and defaults, giving 100% coverage. The description adds no extra parameter semantics, so the baseline of 3 is appropriate since the schema carries the full burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get the list' and the specific resource 'Cloud Insight integrations', and notes it is paged. This distinguishes it from sibling tools like ncloud_get_integration (singular) and the create/update/delete operations. 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is the tool for listing integrations, but it does not explicitly state when to use it versus alternatives like ncloud_get_integration for a single integration. There is no explicit when-not-to-use or mention of alternative tools, so the guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_lb_listenersA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description is consistent ('List'). However, it adds no additional behavioral context such as pagination, response format, or prerequisites beyond the required parameter. With annotations covering the read-only nature, this is adequate but minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no filler, front-loading the action ('List') and resource ('listeners'). Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool, the description, schema, and annotation together provide sufficient context for invocation. No output schema is present, but the return (list of listeners) is implied. Could mention more about returned fields, but not essential for basic use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with a clear description for the single parameter 'loadBalancerInstanceNo' ('Load balancer instance number'). The description does not add further parameter semantics, but the schema already carries the meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses the specific verb 'List' and resource 'listeners', scoped to 'a specific load balancer', clearly distinguishing it from sibling tools like list_load_balancers or get_load_balancer_detail. 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrasing 'for a specific load balancer' implies when to use the tool, but there is no explicit guidance on alternatives or exclusions. It lacks comparison to sibling tools, so usage context is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_login_keysA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safe read-only nature. The description adds that it is region-scoped ('current region'), which is useful context. However, it does not disclose pagination behavior, response format, or any quota/limit considerations, so transparency is adequate but not enriched beyond the basics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with zero wasted words. It effectively communicates the core purpose and scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with optional pagination and a readOnly hint, the description is reasonably complete. It specifies the resource, scope, and region. The absence of an output schema is acceptable for a standard list endpoint, though a note about default pagination or response structure could make it more thorough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both pageNo and pageSize having clear descriptions for pagination. The tool description adds no additional meaning beyond what the schema already provides, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and a clear resource 'login keys' with an explicit scope ('all' and 'current region'). This distinguishes it from sibling operations like create, import, delete login keys, and from service-specific list tools such as ncloud_hadoop_list_login_keys.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied (use when you need to list login keys), but there is no explicit guidance on when to prefer this over alternatives like ncloud_ses_get_login_keys or ncloud_hadoop_list_login_keys. The description does not provide exclusions or alternate tool mentions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_mongodb_bucketsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description does not contradict that. The description adds the specific scope (buckets for MongoDB backup export) but does not disclose additional behavioral traits such as pagination, authentication, or the exact structure of results. Since annotations cover the safety profile, the description adds modest value.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single clear sentence with no redundant words. The purpose is front-loaded with the verb 'List' and the resource is specified immediately. Highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one optional parameter and no output schema, the description is sufficient to convey purpose and scope. It lacks any mention of return format, but that is not critical given the tool name and nature. The description is complete enough for an agent to select and call it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (regionCode has a description), so the schema fully documents the parameter. The description adds no additional parameter semantics, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and identifies the exact resource ('Object Storage buckets available for Cloud DB for MongoDB backup export'). It clearly distinguishes from sibling tools like ncloud_list_mongodb_backups (which lists backups) and ncloud_list_buckets (which lists all buckets).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context (for MongoDB backup export) but does not explicitly state when to use this tool versus alternatives, nor provide exclusions. It gives some contextual guidance but lacks direct 'use when' or 'alternatives' statements.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_monitor_groupsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description is consistent. It adds the product-scoping context but does not disclose response format or pagination, which could be relevant for a list tool. The safety profile is covered by the annotation, placing this at baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, front-loaded with action verb, no redundant words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Simple list tool with one well-documented parameter and read-only annotation. The description adequately states the return type and scope. No output schema exists, but for a simple list, this is sufficient. Could be improved by mentioning response structure, but not necessary.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the prodKey parameter is fully described with context (cw_key, required, use ncloud_get_schema_keys). The description's 'for a specific product' adds minimal value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get the list') and resource ('Cloud Insight monitoring target groups') with a scope ('for a specific product'), clearly distinguishing it from tools like ncloud_get_monitor_group (singular) or ncloud_list_metrics_groups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a listing operation but does not explicitly state when to use this over alternatives like get_monitor_group or create_monitor_group. It does provide a prerequisite by referencing ncloud_get_schema_keys in the parameter description, but that is in the schema, not the description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_mssql_character_setsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already communicates the safe read-only nature; the description adds the scope ('for Cloud DB for MSSQL') but does not disclose additional behavior such as pagination, regional defaults, or response format. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single clear sentence that begins with the action and states the resource, with no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with one optional parameter and no output schema, the description is sufficient to select and invoke it. It could be slightly enhanced by noting the optional regionCode default, 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the only parameter, regionCode, including allowed values and default behavior (schema coverage 100%). The description adds no extra parameter context, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('available character sets for Cloud DB for MSSQL'), clearly differentiating from sibling MSSQL list tools such as ncloud_list_mssql_buckets or ncloud_list_mssql_config_groups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when character set information for MSSQL is needed) but provides no explicit context, prerequisites, or alternatives. There are no sibling tools with overlapping purpose, so exclusion guidance is less critical.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_mssql_config_groupsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already communicates the read-only, non-destructive nature. The description simply says 'List', which aligns with the annotation, but adds no further behavioral context such as pagination, filtering, or response details beyond the name.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that precisely states the action and target resource. Every word is necessary, and there is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with one optional parameter and no output schema, the description is adequate. It could benefit from a brief note on what a Config Group represents or the return structure, but the minimal complexity means the current description is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has one optional parameter (regionCode) with a full description, providing 100% schema coverage. The tool description does not add additional parameter context, so the baseline 3 applies as the schema carries the meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and identifies the resource ('Config Groups for Cloud DB for MSSQL'), clearly distinguishing it from sibling tools like ncloud_cdss_list_config_groups (for Kafka) and ncloud_list_cache_config_groups (for Cache). The product-specific name removes ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its use: when you need to list Config Groups for Cloud DB for MSSQL. However, it does not explicitly state when to prefer this over alternatives or mention exclusions, leaving the guidance implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_mssql_foldersA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation, and the description does not contradict it. The description adds context about the bucket scope but does not disclose additional behavioral traits such as pagination, permission requirements, or whether folders are listed recursively.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is concise, front-loaded, and free of unnecessary words. It directly communicates the action and target.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 parameter, the description is mostly complete. However, with no output schema, it does not mention the return format or clarify what 'folders' means in the object storage context, which would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents bucketName with a clear description, giving 100% schema coverage. The tool description adds no further parameter semantics, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action (list), a specific resource (folders within an Object Storage bucket), and a context (Cloud DB for MSSQL). This distinguishes it from sibling tools like ncloud_list_mssql_buckets, which list buckets rather than folders within a bucket.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: you use this tool when you need to see folders inside a specific MSSQL-related Object Storage bucket. However, it provides no explicit guidance about when not to use it or how it compares to alternatives like ncloud_list_objects or ncloud_list_mssql_buckets.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_mssql_instancesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already communicates the safe read-only nature of the operation. The description adds the region-scoping context but does not disclose further behavioral traits such as pagination behavior, response format, or filter semantics beyond what the schema already shows. With the annotation covering safety, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states exactly what the tool does with no filler. Every word contributes to the meaning, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with a readOnlyHint annotation, the description is sufficient: it identifies the resource type (MSSQL instances) and the scope (current region). However, there is no output schema, so the agent is not told what fields are returned, and pagination behavior is only implied by the schema parameters. The description could be more helpful but is not inadequate for this low-complexity tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions for pagination and filters, so the schema does the heavy lifting. The description itself adds no additional parameter semantics; the word 'all' could imply unfiltered listing, which is slightly at odds with the optional filters but not misleading. A baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists all MSSQL instances in the current region, using a specific verb and resource. The 'all' scope and region qualifier distinguish it from detail-lookup tools like ncloud_get_mssql_instance_detail and other MSSQL-specific list tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear context (listing all MSSQL instances in the current region) but does not explicitly mention when to use this tool over alternatives. It does not reference sibling tools like get_mssql_instance_detail for single-instance lookups or list_mssql_backups for backups, so usage guidance remains 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.

• ncloud_list_mysql_backup_detailsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already covers the safety profile. The description adds that file names are included in the response, which is useful context, but does not disclose other behavioral traits such as pagination, ordering, or any potential limitations. With annotations present, this is acceptable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that conveys the core purpose and a key feature (file names) without any redundant wording. It is front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (2 flat parameters, no output schema), the description is fairly complete. It explains what the tool returns (detailed backup information including file names) and identifies the target resource. The absence of an output schema is partly mitigated by this description, though more specific return-field details could improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema (100% coverage), so the baseline is 3. The description itself adds no parameter-level detail beyond signaling that the operation is tied to a specific MySQL instance, which is already evident from the schema's cloudMysqlInstanceNo parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and clearly identifies the resource ('detailed backup information ... for a Cloud DB for MySQL instance'), including a distinguishing detail ('including file names'). It effectively separates this from sibling tools like ncloud_list_mysql_backups or ncloud_get_mysql_instance_detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'detailed backup information' implies that this is for more granular data than a simple backup list, but there is no explicit guidance on when to choose this over ncloud_list_mysql_backups or other related tools. Usage context is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_mysql_eventsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the safe read-only nature. The description adds the context that it returns 'event history' but does not disclose additional behavioral traits such as pagination limits, event types covered, or whether events are returned chronologically. It does not contradict the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, tightly worded sentence that states the action and scope immediately. No filler or redundancy. It is front-loaded with the verb and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with only two parameters and no output schema, the description is nearly sufficient: it says what is listed and for which resource. It could improve by describing the nature of events (e.g., lifecycle events, monitoring events) or indicating the response format, but the core invocation context is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both cloudMysqlInstanceNo and regionCode have clear descriptions in the schema. The tool description adds no parameter-specific meaning beyond naming the instance. Baseline 3 applies because the schema already documents both parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and clearly identifies the resource ('event history') scoped to a 'Cloud DB for MySQL instance'. This distinguishes it from sibling MySQL tools like ncloud_list_mysql_databases, ncloud_list_mysql_users, and ncloud_list_mysql_logs, and from unrelated event tools such as ncloud_list_av_events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it: whenever you need event history for a specific MySQL instance. However, it does not explicitly contrast it with alternatives like ncloud_list_mysql_logs or mention conditions, prerequisites, or exclusions. The usage context is clear but not elaborated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_mysql_logsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the safe read-only nature. The description adds the detail that it lists 'log files' (not log content), which is a mild behavioral note. However, it does not explain pagination, ordering, or what fields are returned. With annotations covering safety, the description adds some but not extensive behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the core action and resource. It contains no redundant words or filler, efficiently stating the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple list operation with 2 parameters and no output schema. The description covers the essential scope (listing DB server log files for a specific MySQL instance). It would benefit from mentioning the return format or the types of log files available, but given the simplicity and existing schema/annotations, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters (regionCode and cloudMysqlServerInstanceNo), with descriptions in the schema. The tool description does not add any parameter-specific meaning or clarify usage beyond the schema. Baseline 3 is appropriate since the schema already documents parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description specifies the exact action ('List'), the resource type ('DB server log files'), and the target service ('Cloud DB for MySQL server instance'). This is a specific verb+resource combination that clearly distinguishes it from siblings like ncloud_export_mysql_log (which exports logs rather than listing) and ncloud_list_mysql_backups (which lists backups, not logs).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys that the tool is for listing log files on a specific MySQL instance but does not provide explicit when-to-use guidance or mention alternatives. It does not state when to prefer this over ncloud_export_mysql_log or clarify that it lists files without downloading contents. The context is enough for basic usage but lacks explicit exclusions or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_nas_snapshotsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already communicates the safe read-only nature. The description adds a scoping context (NAS volume instance) but does not disclose other behavioral traits such as pagination behavior, sorting, or response structure. It is consistent with the annotation, with no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that contains no redundant information. Every word contributes to the stated purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool, the fully described parameters, and the readOnlyHint annotation, the description is sufficient for initial selection and invocation. However, it does not mention pagination behavior or return value structure, which would be helpful in the absence of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter, including pageNo, pageSize, and nasVolumeInstanceNo, already has a descriptive schema entry. The description does not add additional parameter-level meaning beyond what is provided in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and clearly identifies the resource as 'snapshots for a NAS volume instance'. This distinguishes it from generic snapshot listers and NAS snapshot create/delete tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (to list snapshots of a NAS volume), but it does not explicitly mention alternatives, prerequisites, or when not to use it. No additional guidance beyond the basic purpose is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_network_aclsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotated readOnlyHint=true already signals a safe read operation. The description adds the 'current region' scoping, which is useful context, but does not disclose other behavioral traits such as pagination, return format, or permission requirements. It does not contradict the annotations, and the additions are minimal beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that conveys the core purpose without waste. It is front-loaded with the action and resource, and every word adds value. No redundant or vague phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with 3 optional filters and no output schema, the description is mostly sufficient. It clearly specifies the default behavior (list all in current region), but does not mention that filters are available or describe the response structure. Given the low complexity and good schema coverage, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (vpcNo, networkAclName, networkAclNoList) having clear descriptions. The tool description itself does not add semantic meaning beyond the schema; it merely says 'List all' without mentioning that filters are available. Since the schema fully documents the parameters, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all Network ACLs in the current region' clearly states the action (list), the resource (Network ACLs), and the scope (current region). It effectively distinguishes from sibling tools like ncloud_get_network_acl_detail (fetch a single ACL) and ncloud_get_network_acl_rules (list rules for an ACL).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (listing ACLs) but provides no explicit guidance on when to choose this tool over alternatives such as ncloud_get_network_acl_detail or ncloud_get_network_acl_rules. No when-to-use or when-not-to-use scenarios are given. The purpose is clear enough that a user could infer, but no explicit alternatives or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_postgresql_backup_detailsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description consistently describes a read operation ('List'). The description adds a small amount of context by mentioning 'including file names' but does not disclose pagination, response structure, or any other behavioral nuances. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded with the verb and resource, and the parenthetical adds meaningful detail. There is no redundancy or filler, so it earns a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with two well-documented parameters, the description adequately conveys the purpose. However, in the absence of an output schema, it only vaguely promises 'detailed backup information' and gives just one example (file names), leaving some ambiguity about the full return payload. A bit more specificity would improve completeness, so a 4 is appropriate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters have schema descriptions with 100% coverage, so the schema already provides the parameter semantics. The description does not add additional parameter-level detail beyond noting the operation is 'for a Cloud DB for PostgreSQL instance', which maps to the required cloudPostgresqlInstanceNo. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and clearly identifies the resource (detailed backup information for a Cloud DB for PostgreSQL instance). The qualifier 'detailed' and the note about 'file names' distinguish it from sibling ncloud_list_postgresql_backups, which likely provides a higher-level overview.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no explicit statement of when to use this tool vs alternatives. However, the 'detailed' qualifier implies it should be used when file-level backup details are needed, while a sibling like ncloud_list_postgresql_backups likely provides summary data. This is implied usage, not explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_postgresql_bucketsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, which already communicates that this is a safe, read-only operation. The description adds the behavioral nuance that buckets are scoped to those available for Cloud DB for PostgreSQL, but does not disclose return format, pagination, or permissions. This is acceptable but minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single succinct sentence with a parenthetical clarification. Every word contributes to the meaning, and the description is front-loaded with the primary verb and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple list operation with one optional parameter, no output schema, and a clear read-only annotation. The description covers the core purpose and scope effectively. It could mention response contents more explicitly, but given the tool's simplicity, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has one optional parameter, regionCode, with a complete description ("Region code (KR, KRS). Defaults to current region."), providing 100% schema coverage. The tool description adds no extra parameter context, so it offers no value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List), the resource (Object Storage buckets available for Cloud DB for PostgreSQL), and the context (for backup export). This distinguishes it from sibling bucket-listing tools like ncloud_list_buckets and ncloud_list_mongodb_buckets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for PostgreSQL backup export but provides no explicit when-to-use guidance or alternatives. It neither excludes other uses nor contrasts with sibling tools, leaving the agent to infer appropriate invocation contexts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_postgresql_databasesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already signals a safe read operation, and the description's 'List databases' is consistent with that. No additional behavioral details like pagination, error conditions, or return format are provided, but given the annotation coverage the description meets the minimum viable standard.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the verb, and contains no unnecessary words or repetition. It is maximally concise while conveying the essential purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one required parameter and a clear annotation, the description adequately communicates the tool's purpose. It doesn't describe the response format, but that is not critical given the simplicity and the presence of the readOnlyHint annotation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the single parameter with a description ('Cloud PostgreSQL instance number'), and the tool description ties the parameter to the action ('in a Cloud DB for PostgreSQL instance') but does not add new semantic detail beyond what the schema already provides. Baseline applies due to 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and clearly specifies the resource: 'databases in a Cloud DB for PostgreSQL instance'. This clearly differentiates it from sibling tools like ncloud_list_postgresql_instances and ncloud_list_postgresql_users.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for listing databases within a specific PostgreSQL instance, but it does not explicitly state when to use this over alternative list tools or provide any exclusions. The usage context is inferred from the resource type rather than being explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_postgresql_usersA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation, and the description is consistent. No additional behavioral context is provided beyond listing users, such as pagination, filtering, or any side effects. The description does not contradict the annotation, but it also does not enrich the agent's understanding beyond what the annotation and basic verb convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, complete sentence that directly conveys the tool's purpose. There is no filler, repetition, or unnecessary detail. Every word contributes to clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with one well-documented parameter and a readOnly annotation, the description is largely complete. The only gap is the absence of any detail about the output (though no output schema exists, a brief note about the return format could have been helpful). Overall, it provides enough for an agent 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers the single parameter 'cloudPostgresqlInstanceNo' with a clear description 'Cloud PostgreSQL instance number'. The tool description adds no further explanation about the parameter format or constraints. Since schema coverage is 100%, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: 'List users in a Cloud DB for PostgreSQL instance'. It specifies the resource (users), the database type (PostgreSQL), and the action (list). This distinguishes it from sibling tools like ncloud_list_postgresql_databases and ncloud_list_mysql_users, as it is unambiguous about what is being listed and for which service.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool: whenever users of a specific PostgreSQL instance need to be listed. However, it provides no explicit guidance on when not to use it or alternative tools, such as ncloud_list_postgresql_databases for database listing. The usage context is clear but not formally differentiated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_sub_accountsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already declares this as a safe read operation. The description adds the organizational scope and clarifies that 'sub accounts' are IAM users, which is useful context. However, it does not disclose pagination behavior, return format, or other behavioral traits beyond what the annotation provides. No contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. Every part contributes meaning: the verb, the resource, and the scope. It is appropriately sized for the simplicity of the tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only listing tool with comprehensive schema descriptions and a read-only annotation, the description is adequate. It does not mention pagination or search capabilities, but these are already documented in the schema. The lack of an output schema is not an issue for a list operation returning a list of sub accounts.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides complete descriptions for all four parameters (page, size, searchWord, searchColumn) with 100% coverage. The tool description itself adds no parameter-specific details, but the schema already documents them clearly, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all sub accounts (IAM users) in the organization' uses a specific verb ('List'), a clear resource ('sub accounts' / 'IAM users'), and a scope ('in the organization'). It clearly distinguishes from sibling tools like ncloud_get_sub_account_detail (specific account), ncloud_create_sub_account, and ncloud_delete_sub_account by its listing intent.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies that this tool is for listing all sub accounts, but it does not explicitly state when to use it over alternatives such as ncloud_get_sub_account_detail for retrieving a specific account, nor does it mention any exclusions. The context is clear for a straightforward listing operation, but explicit guidance is missing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_target_groupsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description's 'List' aligns. It adds the 'current region' scope, which is a behavioral constraint not in annotations. However, it does not mention pagination behavior, default page size, or result ordering. Minimal added value 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single 8-word sentence, front-loaded with the verb and resource. There is zero filler or redundancy, earning a top score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with readOnly annotation and all parameters documented in the schema, the description adequately covers the operation. The absence of an output schema is offset by the implied return of a list. Missing an explicit note about pagination controls but not critical given schema visibility.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all five parameters with descriptions (100% coverage), so the description bears no burden for parameter semantics. It does not duplicate or add new parameter details, meeting the baseline expectation for a schema-complete tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 'target groups' and a scope constraint ('in the current region'), which precisely identifies the operation. It distinguishes from siblings like ncloud_get_target_group_detail (single target group) and ncloud_list_targets (targets within groups).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use vs alternatives. The implied usage is clear from the name, but there is no mention of exclusions or better-suited tools (e.g., ncloud_get_target_group_detail for a specific group). The description could note that all groups are returned unless filters are applied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_vpc_peeringsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation. The description adds the 'current region' scope, which is useful context, but does not disclose other behavioral details such as pagination, ordering, or whether all peerings are returned by default. With the annotation covering the safety profile, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded with the verb and resource. Every word earns its place, and there is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with good schema coverage and a readOnly annotation, this description is mostly complete. It clearly states the resource and scope. It does not explicitly mention that filters are optional or describe the return format, but for a list operation without an output schema, this is an acceptable gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with all five filter parameters described individually. The description adds no additional meaning beyond saying 'List all', implying the filters are optional. Since the schema already provides semantics for each parameter, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List), the resource (VPC Peering instances), and the scope (current region). This distinguishes it from sibling tools like ncloud_get_vpc_peering_detail (which retrieves a single peering) and ncloud_create_vpc_peering (which creates one).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for listing VPC Peerings in the current region, which is clear enough for a straightforward list operation. However, it does not explicitly state when to use this versus alternatives like ncloud_get_vpc_peering_detail for a specific peering, nor does it mention that filters are optional for narrowing results.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_vpcsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint: true already indicates this is a safe read operation. The description adds the constraint 'in the current region', which is a useful scoping detail. No contradictions. It does not go into pagination or return format, but for a simple list operation with an annotation, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence: 'List all VPCs in the current region'. It is front-loaded with the action and resource, contains no fluff, and every word earns its place. Perfectly sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with three optional self-documenting filters and no output schema, the description is nearly complete. It states the core behavior and scope. It could optionally mention that filters are supported, but the schema covers that. The presence of readOnlyHint and full schema coverage reduce the need for more detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all three parameters (vpcName, vpcNoList, vpcStatusCode) having clear descriptions. The tool description adds no additional parameter detail, but the schema already provides sufficient information. Baseline 3 is appropriate when the schema handles the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 'VPCs' and a scope qualifier 'in the current region'. This clearly distinguishes it from sibling tools like get_vpc_detail which fetches a single VPC, and create_vpc/delete_vpc which are mutations. 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool's use case: when you need to list all VPCs in the current region. It does not explicitly mention alternatives or exclusions, such as using get_vpc_detail for a specific VPC. However, the verb 'list' and the resource name provide reasonable contextual guidance, so it's not completely absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ncr_delete_registryA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, but the description adds critical context: 'Permanently delete', 'All images and tags will be destroyed', and 'Set confirm=true to execute'. This goes beyond the structured annotations by explaining the blast radius and the confirmation safeguard.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short, front-loaded sentences: a destructive warning, the core action, and the prerequisite confirm flag. Every sentence earns its place with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with two parameters and no output schema, the description covers the essential context: destruction, permanence, impact on images/tags, and the confirm requirement. It lacks nuances like idempotency or post-delete behavior, but those are either annotated or minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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. The description mentions confirm=true but only restates what the schema says ('Must be true to actually execute the destructive operation'), adding no new semantic information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Permanently delete a container registry' with the specific resource and action. It also clarifies the scope by saying 'All images and tags will be destroyed', which distinguishes it from sibling tools like ncloud_ncr_delete_image and ncloud_ncr_delete_tag.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not mention when to use this tool versus alternatives, such as deleting individual images or tags. It only instructs setting confirm=true to execute, which is a parameter usage detail rather than tool selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ncr_get_imageA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true and the description aligns with a read operation, so no contradiction. However, the description adds minimal behavioral context beyond the annotation, lacking details about return structure, pagination, or any access requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It communicates the core purpose instantly and efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple get-by-identifier tool with two self-explanatory parameters and a read-only annotation. The description is likely sufficient for invocation, though it does not specify what 'detailed information' contains; this is acceptable for the low complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive names and an example for imageName. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get detailed information') and the resource ('specific container image'). It distinguishes from sibling tools like ncloud_ncr_list_images (list all) and ncloud_ncr_delete_image (delete) by emphasizing a single image lookup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Use for a single image is implied by the word 'specific', but there is no explicit guidance on when to use this tool versus alternatives, such as ncloud_ncr_list_images for enumeration. No exclusions or prerequisites are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ncr_list_tagsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the safety profile, so the bar is lower. The description adds no behavioral details beyond the annotation, such as pagination behavior, response format, or potential performance implications. It does clarify the scope of the listing (all tags for a specific image), which is minor useful context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no filler. Every word contributes to the purpose. It is appropriately front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool, the readOnlyHint annotation, and the rich input schema covering all parameters, the description is sufficient. It does not explain return values or pagination, but no output schema exists and the schema documents page/pageSize. It could mention that results may be paginated, but this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% parameter description coverage, so the schema carries the full burden of parameter semantics. The description adds little beyond what the schema already provides; mentioning 'specific container image' and 'registry' maps to imageName and registryName, but this does not add meaningful new information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and clearly identifies the resource ('tags for a specific container image in a registry'). It distinguishes itself from sibling tools like ncloud_ncr_list_registries and ncloud_ncr_list_images by specifying the object is tags for a particular image in a registry.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating it lists tags for a specific image, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. It lacks explicit 'when to use' guidance, but the scope is clear enough for a simple read-only listing operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_get_server_imagesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation, and the description's 'List' aligns with that. The description adds the context that images are for NKS cluster/node pool creation but does not disclose additional behaviors such as response format or default hypervisorCode (which is in the schema). 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the action verb 'List', and contains no unnecessary filler. It earns its place by clearly stating the resource and purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple tool with one optional parameter and a readOnly annotation. The description clearly states what it lists and for what purpose. Since there is no output schema, the description could be more explicit about the response structure, but 'server image types' is sufficiently clear for this low-complexity operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the sole parameter hypervisorCode. The tool description adds no extra parameter semantics beyond what the schema already 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List'), a specific resource ('available server image types'), and a clear context ('for NKS cluster/node pool creation'). This distinguishes it from sibling tools like ncloud_get_server_images (general server images) and ncloud_nks_get_server_specs (server specs, not images).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for NKS cluster/node pool creation, which gives clear context. However, it does not explicitly state when not to use this tool or name alternative tools (e.g., ncloud_get_server_images for non-NKS scenarios), so guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_get_versionsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation. The description adds the specific context that it targets cluster creation versions, which is helpful, but it does not disclose any additional behavioral traits such as return format, pagination, or defaults. With the annotation present, the description provides minimal extra value beyond the structured data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the tool's purpose. Every word earns its place, and there is no redundant or tangential information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with optional parameters and read-only annotations, the description is adequate and complete. It clearly identifies the tool's role in the NKS workflow, and the schema handles parameter details. However, it does not describe the shape of the response, which could be useful but is not critical for a list endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes both parameters (hypervisorCode and isRegionalSupport) with clear descriptions, so the schema coverage is 100%. The description adds no additional parameter-level meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'List' and specific resource 'available Kubernetes versions for NKS cluster creation'. It is unambiguous and distinguishes this tool from similar listing tools like ncloud_ses_get_versions or ncloud_cdss_get_kafka_versions by explicitly mentioning NKS.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for NKS cluster creation' implies when to use this tool, but there is no explicit guidance on when not to use it or which alternatives exist. Sibling tools like ncloud_nks_upgrade_cluster are not mentioned, leaving usage context somewhat implicit rather than clearly delineated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_set_return_protectionA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is known. The description merely restates 'configure return (deletion) protection' without adding behavioral specifics such as whether enabling protection blocks deletion until disabled or the effect of re-applying the same value. No contradiction, but little additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that front-loads the action and resource. Every word contributes; no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter mutation with full schema coverage and annotations indicating idempotent/non-destructive behavior, the description is adequate. It lacks details about return values or side effects, but no output schema exists and the operation is straightforward, so completeness is reasonable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of the two parameters with clear descriptions for clusterUuid and returnProtection. The description does not provide additional semantic depth beyond what the schema already states, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Configure' and names the exact resource 'return (deletion) protection for an NKS cluster'. It clearly distinguishes from sibling tools like ncloud_nks_delete_cluster, which performs actual deletion, and the parenthetical '(deletion)' disambiguates the term 'return protection'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used to set deletion protection on an NKS cluster, but it does not provide explicit when-to-use guidance or contrast with alternatives. There is no mention of prerequisites such as cluster state or permissions, and no exclusion of scenarios like already-enabled protection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_update_auth_typeA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate non-destructive and idempotent behavior. The description adds no additional behavioral context (e.g., whether the update takes effect immediately, requires cluster availability, or impacts existing sessions). 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, concise and to the point. No filler words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple update operation with two well-documented parameters and safe annotations, the description suffices. It does not mention possible side effects or state changes, but given the simplicity and existing schema/annotations, it is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers both parameters with descriptions (authType: 'API or CONFIG_MAP', clusterUuid: 'UUID of the cluster'). The tool description adds no further parameter semantics beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action (update) and the target resource (authentication mode for an NKS cluster), distinguishing it from sibling tools like ncloud_nks_set_oidc or ncloud_nks_set_ip_acl.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives. It only states what it does, leaving usage to inference. No exclusions or alternative tool suggestions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_update_node_pool_subnetA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already indicate idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond stating 'update subnet'; it does not explain potential side effects like rolling node replacements, network interruptions, or how the update is applied. This is acceptable given the annotations but lacks richer context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no redundant words. It is front-loaded with the action and resource, earning top marks for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity, the full parameter schema coverage, and the annotations, the description is sufficient for an agent to understand the core operation. It does not explain return values (no output schema) or provide additional operational context, but the combination of structured data and the concise description is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with all three parameters (clusterUuid, instanceNo, subnetNoList) documented in the schema. The description adds no further parameter-level information, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Update subnet for a node pool in an NKS cluster'. It uses a specific verb ('Update') and identifies the resource ('node pool subnet' in an NKS cluster). It distinguishes itself from sibling tools like ncloud_nks_update_lb_subnet (load balancer subnet) and ncloud_nks_add_subnet (adding subnets) by focusing on the node pool subnet update.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the usage context (updating a node pool's subnet) but provides no explicit guidance on when to use this tool versus alternatives such as ncloud_nks_add_subnet or ncloud_nks_update_node_pool. There are no exclusions or mention of prerequisites like node pool status or subnet compatibility.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pca_list_casA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, and the description is consistent with that. It adds return-content context (status, type, alias, certificate details) but does not mention pagination behavior, default page size, or other operational caveats. The description adds some value beyond the annotation but could disclose more.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action and resource, and contains no filler. It efficiently communicates purpose and return contents.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one optional parameter and a readOnly annotation, the description covers the action, scope, and returned fields. The main gap is the lack of pagination semantics despite the pageNo parameter, which could matter when the result set is large. Overall, it is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, pageNo, is fully described in the schema as 'Page number for pagination'. The description adds no additional meaning about pagination mechanics, defaults, or how 'all' relates to paging. Baseline 3 applies because schema coverage is 100%.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 'Private CA instances', explains the acronym, and notes returned fields (status, type, alias, certificate details). It differentiates from sibling ncloud_pca_get_ca by saying 'all' rather than implying a single CA lookup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear scope ('List all Private CA instances') but does not explicitly state when to use this tool versus alternatives like ncloud_pca_get_ca or ncloud_list_certificates. Usage is implied by the tool name and wording, but no exclusions or explicit alternative guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pca_list_end_certsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile, and the description adds that it 'Returns serial numbers', which is useful. However, it does not disclose whether the list includes revoked/expired certificates, pagination behavior, or ordering. This is acceptable but not rich enough for a 4.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences that are front-loaded with the primary action ('List all end-entity certificates') and conclude with the return value. No wasted words, highly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with one parameter and no output schema, the description provides the essential information: what it lists, the scope (specific CA), and the key return value (serial numbers). It lacks details on pagination or status filtering, but these are not critical for basic invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the only parameter (caTag) with a description ('CA tag value'), so the baseline is 3. The tool description does not add further semantic detail about the parameter beyond restating that it specifies 'a specific CA', which does not materially improve understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb ('List') and identifies the exact resource ('all end-entity certificates issued by a specific CA'). It distinguishes this from sibling tools like ncloud_pca_list_cas (lists CAs) and ncloud_pca_get_end_cert (gets a single certificate), making the purpose clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used to enumerate end-entity certificates for a CA, but it does not explicitly state when to choose this over alternatives such as ncloud_pca_get_end_cert or ncloud_pca_revoke_end_cert. No exclusionary or alternative guidance is provided, so usage context is only implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pipeline_list_sourcebuild_projectsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, which agrees with 'List'. The description adds the availability scoping ('available') and purpose context, but does not mention pagination behavior, defaults, or return shape. Given annotation coverage, this is acceptable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, front-loaded with verb and resource, contains no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity read-only list tool with fully documented schema, the one-line description is sufficient to select and invoke it. However, the absence of any output-schema or return-format guidance is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers all 3 parameters with descriptions (100% coverage), so baseline applies. The description adds no additional parameter-specific semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'List', names resource 'SourceBuild projects', and adds context 'for pipeline task configuration' which distinguishes it from sibling tools like ncloud_sourcebuild_list_projects and ncloud_sourcedeploy_get_sourcebuild_projects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for pipeline task configuration' gives a clear context, but there is no explicit guidance on when to use this over alternatives such as ncloud_pipeline_list_sourcedeploy_projects or ncloud_sourcebuild_list_projects, nor any exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pipeline_list_sourcedeploy_scenariosA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation, and the description's 'List' verb aligns with that. However, it adds no additional behavioral insight such as pagination behavior, filtering, or how scenarios are scoped to a stage beyond what the schema already shows.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence that wastes no words. It is front-loaded with the action and resource, making it easily scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with fully documented parameters and a read-only annotation, the description is largely sufficient. It does not detail the return structure, but no output schema exists and the context of a listing tool makes the expectation obvious. A brief note about filtering or pagination could improve completeness, but it is not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% parameter description coverage, so the baseline is 3. The description adds minimal value beyond the schema; it restates the stage context, but does not clarify relationships between parameters or the semantic meaning of searchWord beyond the schema's 'Filter by scenario name (partial match)'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 ('SourceDeploy scenarios') and scope ('for a project stage'). It distinguishes from sibling tools like ncloud_pipeline_list_sourcedeploy_stages and ncloud_sourcedeploy_list_scenarios by implying the pipeline project-stage context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when needing to list scenarios for a given project stage, but it does not explicitly state when to prefer this tool over alternatives like ncloud_sourcedeploy_list_scenarios or provide exclusion criteria. Context is implied rather than articulated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_resource_attach_tagA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations declare idempotentHint=true and destructiveHint=false, and the description adds valuable context: the upsert behavior (update if tag key exists). This goes beyond the annotations by clarifying the tool's write semantics. However, it omits other behavioral details like partial failures or permission requirements, which are less critical given the non-destructive and idempotent nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action, and contains zero redundant words. Every element—the action, the batch capability, and the upsert behavior—earns its place in a compact, clear statement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with three required parameters and no output schema, the description is quite complete. It explains the core behavior and the crucial upsert rule. It lacks details about NRN format or examples, but these are implied by the schema and domain context. Given the tool's simplicity, the description covers most necessary context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage with descriptive parameter names and descriptions ('List of Ncloud Resource Names to tag', 'Tag key to attach', 'Tag value to attach'). The description's phrase 'one or more resources' reinforces the nrnList plurality but adds no additional semantic meaning beyond what the schema states. Baseline of 3 is appropriate when schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Attach a tag to one or more resources,' with a specific verb and resource type. It also adds the upsert behavior ('If the tag key already exists, the value is updated'), which distinguishes it from simple creation. The name itself contrasts with detach siblings, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. The description does not mention the sibling ncloud_resource_detach_tag or other resource tagging operations, nor does it state prerequisites or context for use. The tool name implies the action, but the description offers no explicit usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_search_event_by_idA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation, so the description does not need to repeat that. However, the description adds little beyond the schema: it mentions 'detailed information' but does not specify response structure, potential errors, or any special behavior. It is not contradictory but provides minimal additional context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  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 parameter context. It contains no unnecessary words and efficiently communicates the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (two required parameters, no output schema, read-only), the description covers the essential context: what it does and what inputs are needed. It does not explain the return format, but for a detail lookup, the phrase 'detailed information' provides adequate expectation. Minor gap: no mention of how to handle missing events or related follow-up tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Parameter schema coverage is 100%, with clear descriptions for both eventId and ruleId. The description's mention of 'event ID and rule ID' adds no extra meaning beyond what the schema already provides. Therefore, the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: retrieving detailed information about a specific monitoring event using event ID and rule ID. It uses a specific verb ('Get') and resource ('specific monitoring event'), and distinguishes itself from sibling tools like ncloud_search_events by focusing on a single event identified by two IDs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for when you already have an event ID and rule ID and need detailed information, but it does not explicitly state when to use it compared to alternatives like ncloud_search_events or ncloud_get_ids_event_detail. No exclusions or alternative tool references are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_search_metric_listA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true, and the description's 'Search' aligns with that. The description adds context that this is a discovery operation for a specific product, which is helpful. However, it doesn't disclose additional behavioral traits such as whether the metric list is static, whether pagination is used, or how results are formatted.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that communicates the core function without any filler. It is front-loaded with the verb and resource, making it easy to scan and quickly understand the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing tool with one parameter and a read-only annotation, the description is largely sufficient. It could be improved by noting that the returned metric identifiers are likely used with query_monitoring_data, but given the low complexity and structured schema, it is complete enough for most selection scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides a clear description for the only parameter, prodKey, with 100% coverage. The description adds no extra parameter information, so the agent relies solely on the schema. Baseline 3 is appropriate since the schema carries the semantic load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the verb 'search' and the resource 'available monitoring metrics' with a specific scope ('for a specific product in Cloud Insight'). It distinguishes itself from sibling tools that manage clusters, source code, or query monitoring data, making the tool's purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when you need to discover metrics for a product, but it does not provide explicit alternatives or exclusionary guidance. It doesn't mention how this relates to other monitoring tools like query_monitoring_data, so the agent is left without clear 'when-to-use-this-vs-that' information.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_get_cluster_server_imagesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation. The description adds the G3/KVM scope constraint, but it does not disclose return format, pagination, or any other behavioral details. Given the annotation coverage, the added context is minimal but not misleading.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the essential purpose and constraint with no wasted words. It is appropriately sized for a zero-parameter read-only tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, no output schema, read-only annotation), the description sufficiently covers its purpose and scope. It could optionally mention the return value shape, but for a straightforward list operation the current description is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema description coverage is 100% trivially. The baseline for no parameters is 4, and the description's scope mention ('G3/KVM only') adds no parameter-specific meaning but is unnecessary since there are no parameters to document.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Get'), the resource ('available OS types'), and the service ('Search Engine Service'), with a specific constraint ('G3/KVM only'). This distinguishes it from related sibling tools like ncloud_ses_get_os_products, which likely covers other generations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided on when to use this tool versus alternatives. The 'G3/KVM only' qualifier implies a use case, but there is no mention of alternative tools for other generations or any contextual prerequisites, leaving the agent without clear direction among the many SES and CDSS sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_get_import_bucketsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation, and the description adds the context of 'data import' availability. However, it does not disclose any additional behavioral traits such as auth requirements, response format, or limitations of the bucket list.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with clear front-loading of the verb and resource, containing no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one well-schematized parameter and a readOnlyHint annotation, the description is nearly complete. It could be enhanced by mentioning what constitutes 'available for data import', but the low complexity keeps it adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully covers the parameter with a meaningful description ('Cluster instance number'). The tool description adds no additional parameter semantics beyond what the schema already provides, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Get'), the resource ('Object Storage bucket list'), and the scope ('available for data import'), which distinguishes it from sibling tools like ncloud_ses_get_snapshot_buckets or generic bucket listers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when needing to list Object Storage buckets for data import, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or preconditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_get_os_monitoringA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals this is a safe read operation. The description adds context by specifying the OS-level and node scope, but it does not disclose other behavioral aspects such as required permissions, pagination, rate limits, or the exact structure of the returned monitoring data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded with the action and resource. Every word contributes to understanding the tool's purpose with no redundancy or irrelevant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple monitoring data retrieval with a read-only annotation and fully described parameters, the description is mostly complete. It could optionally mention that monitoring data is returned for a time range or that the required IDs come from cluster/node lists, but the schema already covers start and end time parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all four parameters are already documented with descriptions. The tool description does not add meaning beyond the schema, but it does align the term 'node' with the computeInstanceNo parameter implicitly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') with a clear resource ('OS-level monitoring data for a Search Engine Service node'). It distinguishes itself from siblings like ncloud_ses_get_monitoring by specifying the OS-level scope and node target.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context (OS-level monitoring for a specific SES node) but does not explicitly state when to use this tool versus alternatives such as ncloud_ses_get_monitoring or ncloud_ses_get_dashboard. There are no exclusions or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_stop_importA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations declare idempotentHint=true and destructiveHint=false, so the safety profile is already disclosed. The description adds only the 'running' condition, with no additional details about effects, reversibility, or response.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One short sentence that communicates the entire purpose with no filler. Front-loaded with the action verb.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple stop operation, the description, schema, and annotations together provide sufficient context. No output schema exists, so return values aren't specified, but the tool's low complexity makes this acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters clearly described ('Import task ID to stop' and 'Cluster instance number'). The description adds no additional parameter semantics beyond what the schema provides, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is 'Stop a running data import operation' – a specific verb ('Stop') with a clear resource ('data import operation') and a condition ('running'). This distinguishes it from sibling tools like ncloud_ses_run_import (which starts) and ncloud_ses_get_import_history (which reads).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for active imports but does not explicitly state when to use vs alternatives or mention prerequisites like needing a running import. It also doesn't mention that stopping an already-stopped import may be allowed (idempotent hint).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_set_deny_allow_group_descA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false. The description adds the 'Set or update' semantics which aligns with idempotency, but does not disclose additional behavioral details such as whether the description is overwritten or if the group must exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no unnecessary words, front-loading the action and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter update operation with annotations covering idempotency and non-destructiveness, the description is largely sufficient. However, it does not mention any effects on existing data or error conditions, leaving some nuance implicit.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully documented in the input schema with descriptions ('Deny-Allow Group number' and 'New description for the Deny-Allow Group'). The tool description adds no further parameter-level meaning beyond the schema's 100% coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Set or update' and names the exact resource 'description of a Network ACL Deny-Allow Group', clearly distinguishing it from sibling tools like ncloud_set_network_acl_description and ncloud_create_deny_allow_group.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear statement of the tool's action but does not explicitly state when to use this tool versus alternatives, nor any exclusions or prerequisites. Context must be inferred 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.

• ncloud_set_lb_descriptionA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context (e.g., prerequisites, state requirements, rate limits), but it does not contradict 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single 10-word sentence that is front-loaded with the verb and quickly conveys the action and resource, with zero wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter mutation with idempotent and non-destructive annotations, the description adequately covers the tool's purpose. No output schema exists, but that is acceptable given the simplicity. It doesn't mention potential side effects, but its minimal nature makes it sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, meaning the input schema already fully documents both parameters. The description adds no extra parameter semantics beyond what the schema provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Set or update') and the resource ('description of a load balancer instance'), making it unambiguous and distinguishing it from sibling set_description tools for other resources. The verb+resource structure is specific and informative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its usage by naming the target resource, but it provides no explicit guidance about when to use this tool over alternatives or any exclusions. Among many sibling set_description tools, there is no mention of when to choose this one or what limitations exist.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_set_nat_gateway_descriptionA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate idempotentHint=true and destructiveHint=false, and the description aligns with these by saying 'Set or update.' However, the description does not add extra behavioral context, such as what happens if the instance does not exist, validation rules, or whether the update is immediately effective. With annotations, this is adequate but not enhanced.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the action, and contains no extraneous information. Every word earns its place, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, non-destructive update operation with idempotency hints and fully documented parameters, the description is largely complete. It does not describe return values, but no output schema exists, and the operation's outcome is self-evident. Missing details like error scenarios or prerequisites are not critical for this straightforward tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% parameter description coverage ('NAT Gateway instance number' and 'New description for the NAT Gateway'). The tool description does not add any additional semantic detail beyond what is in the schema, so it meets the baseline for good schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Set or update') and the resource ('description of a NAT Gateway instance'). It is specific and unambiguous, distinguishing it from read-only or deletion tools for the same resource. The verb+resource structure is precise.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when you need to set or update a NAT Gateway description), but it does not explicitly mention alternatives or exclusions. Sibling tools like ncloud_get_nat_gateway_detail or ncloud_list_nat_gateways are not referenced, so the guidance is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_set_vpc_peering_descriptionA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (idempotentHint=true, destructiveHint=false) already communicate the safety profile. The description aligns with these, but adds little extra context—it does not explain that the operation overwrites the existing description or note any state requirements for the peering instance. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence with no fluff. Every word contributes to conveying the tool's function, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter update operation with idempotent and non-destructive annotations, the description is adequately complete. It does not need to explain return values (no output schema). A slightly more detailed note about overwriting behavior or prerequisites would push it to 5, but the current level is sufficient for straightforward use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters ('vpcPeeringInstanceNo' and 'vpcPeeringDescription') already documented in the schema. The description adds no new parameter-level information, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Set or update') and identifies the resource ('description of a VPC Peering instance'), making the tool's purpose unambiguous. It clearly distinguishes from sibling tools like create_vpc_peering, delete_vpc_peering, and accept_reject_vpc_peering.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The use case is implied by the tool name and description, but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites (e.g., the peering instance must exist). The description lacks explicit exclusions or alternative suggestions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcebuild_list_computeA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description aligns with the readOnlyHint: true annotation by using 'List', which implies a safe, non-mutating operation. However, it adds no additional behavioral context such as return format, pagination, or any caveats. With the annotation already declaring read-only safety, a baseline score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that immediately states the verb and target resource. It contains no unnecessary words and is well-structured for quick comprehension.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list operation, the description sufficiently conveys the purpose. It does not describe the return values, but given the simplicity of the tool and the absence of an output schema, this is a minor gap. The description is otherwise complete enough for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters and 100% schema description coverage, so there are no parameter semantics for the description to clarify. The baseline score for a no-parameter tool is 4, as no further explanation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and the specific resource ('available compute types for SourceBuild build environment'). This is specific enough to distinguish it from sibling SourceBuild list tools such as ncloud_sourcebuild_list_docker_engines or ncloud_sourcebuild_list_runtimes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 is a simple, zero-parameter list operation, but the description does not explicitly state that it should be used to discover compute types before creating or updating a build project.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcebuild_list_osA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already communicates that this is a safe read operation. The description adds minimal behavioral context, such as the fact that the OS list is 'available' (implying a dynamic query), but does not disclose response format, pagination, or other traits. With annotations covering the safety profile, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It immediately states the verb 'List' followed by the resource, making it highly scannable for an agent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 list tool, the description is sufficiently complete. It names the exact resource returned without needing extensive detail. While there is no output schema to describe response fields, the simplicity of the operation makes this level of detail acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema is effectively empty. The description does not need to explain parameters, and the baseline for a zero-parameter tool is 4. The description's mention of 'available operating systems' provides enough context for the tool's purpose.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('List') and the specific resource ('available operating systems for SourceBuild build environment'). This distinguishes it from sibling tools that list other entities like docker engines or runtimes, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or alternative tools, so the agent receives no contextual direction beyond the basic description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcebuild_list_projectsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation, and the description does not contradict it. The description adds minimal behavioral context beyond listing, such as the ability to filter by name and paginate, but these are also captured in the schema. No additional side effects or limitations are disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of eight words, front-loading the core action and resource. It avoids unnecessary detail while summarizing the key optional features.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with all parameters documented and a read-only annotation, the description is adequate. It doesn't describe the return format, but the action 'list' implies a collection, and no output schema exists. However, it could be slightly more specific about what project information is returned, so a 4 rather than 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all three parameters (pageNo, pageSize, projectName). The description reinforces these with the phrases 'name filter' and 'pagination' but does not add new semantic details beyond what the schema provides, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('List') and resource ('SourceBuild projects'), and distinguishes it from sibling tools like ncloud_sourcebuild_get_project which retrieves a single project. The mention of optional filters and pagination adds scope clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for listing SourceBuild projects, but does not name alternative tools or exclusion criteria, such as using ncloud_sourcebuild_get_project for single-project details.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcecommit_get_repo_by_idA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the agent knows this is a safe read. The description adds the context of 'detailed information' but does not disclose return format, potential errors, or other behavioral nuances. It provides minimal additional value 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, well-structured sentence that is front-loaded with the action and resource. No filler or redundancy, making it highly concise and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 well-documented parameter and no output schema, the description is largely sufficient. However, it could be slightly more complete by mentioning what 'detailed information' includes or how this tool differs from ncloud_sourcecommit_get_repo, given the ambiguity in the sibling set.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: repositoryId is described as 'Repository ID (from repository list)'. The description adds nothing about parameters beyond what the schema already 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get'), the resource ('SourceCommit repository'), and the scope ('by ID'). The 'by ID' qualifier distinguishes it from the sibling ncloud_sourcecommit_get_repo, which presumably fetches by a different identifier.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool should be used when the agent has a repository ID (since it says 'by ID'), but it does not explicitly state when to use this tool versus alternatives like ncloud_sourcecommit_get_repo. No exclusions or alternative guidance is given, so usage is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcecommit_list_reposA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation already declares readOnlyHint=true, so the safe read-only nature is known. The description adds scope ('all') and mentions filtering/pagination capabilities, providing some behavioral context. It does not contradict annotations, but it also doesn't disclose details like response size limits or pagination defaults beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core action, and contains zero redundancy. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool, the description is mostly complete: it states what it lists and mentions the key capabilities. With no output schema, it could explain what the response contains (e.g., a list of repository summaries), but that gap is minor given the straightforward nature of the operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed descriptions for pageNo, pageSize, and repositoryName. The description only restates 'filtering by name and pagination', which adds no new meaning beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('all SourceCommit repositories'), clearly stating what the tool does. It distinguishes itself from sibling get_repo tools by indicating it retrieves all repositories, not a single one.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'List all SourceCommit repositories' implies usage for retrieving a repository listing, and filtering/pagination hints suggest when to use parameters. However, there is no explicit mention of when to choose this over alternatives like ncloud_sourcecommit_get_repo, nor any exclusions or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_cancel_deployA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds the 'ongoing' scoping, clarifying that only active deployments can be canceled, but does not disclose other behavioral aspects like side effects on deployment history or whether cancellation is reversible.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant information. Every word contributes to the meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, two clearly documented parameters, and rich annotations, the description is largely sufficient. It would benefit from stating what happens upon cancellation (e.g., whether the deployment history marks it as canceled), but the core context is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with clear descriptions. The description adds no additional parameter-level detail, so the baseline of 3 applies since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Cancel') and the specific resource ('ongoing SourceDeploy deployment'), distinguishing it from related deployment tools like start/approve/reject. It is a specific verb+resource pairing with no ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The word 'ongoing' implies the tool is for canceling in-progress deployments, but there is no explicit when-to-use guidance or mention of alternatives (e.g., other cancel operations). Usage context is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_delete_scenarioA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructiveHint=true, and the description reinforces this with '⚠️ Destructive'. It adds the critical behavioral detail that confirm=true is required for the operation to actually execute, which goes beyond the annotation and provides important safety context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence, front-loaded with a warning icon and the destructive nature. Every word earns its place, with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a simple parameter set and fully documented schema, the description covers the essential information: the destructive action, the confirmation requirement, and the resource type. It does not explain broader implications, but those are not necessary for correct invocation given the annotations and schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All four parameters have schema descriptions, giving 100% coverage. The description adds meaningful context for the confirm parameter, explaining it must be true to execute, which complements the schema's default value. Other parameters are already well-documented in the schema, so no additional description is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Delete' and the resource 'deployment scenario', making the purpose explicit. It distinguishes itself from sibling delete tools (e.g., delete_stage, delete_project) by specifying the scenario resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides the prerequisite that confirm=true must be set to execute, but gives no guidance on when to use this tool versus alternatives or when not to use it. It lacks contextual direction beyond the safety condition.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_get_autoscaling_groupsA
  3.8/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation. The description adds no behavioral details beyond the name, such as response format, pagination, or filtering, so it provides minimal additional value for behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise sentence that is front-loaded with the action and resource. No redundant or extraneous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool with a clear name and annotations, the description is adequate. The absence of an output schema is a minor gap—it does not specify what fields are returned—but the simplicity of the operation makes this acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters; the input schema has an empty properties object. Per the rubric, zero parameters gives a baseline of 4, and since there is nothing to document, this score is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get the list') and clearly identifies the resource ('Auto Scaling groups for SourceDeploy stage configuration'). It distinguishes this tool from general ASG tools like ncloud_list_asgs and other SourceDeploy getters (e.g., get_servers, get_k8s_clusters) by specifying the context of use.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when configuring SourceDeploy stages, but it does not explicitly state when to use this tool over alternatives (e.g., ncloud_list_asgs for general ASG listing) or mention any exclusions. Usage context is implied but not directly addressed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_get_canary_analysis_stepsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already indicates a safe read operation. The description adds no extra behavioral context, such as ordering, pagination, or dependencies. It is consistent with the annotation but offers minimal additional transparency beyond the resource identification.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that conveys the essential operation without unnecessary words. It is front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only getter with self-explanatory parameters and a readOnlyHint, the description sufficiently identifies the resource and distinguishes from the report tool. It lacks detailed context about the step list's structure or prerequisites, but given the simplicity, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides full descriptions for all three parameters (IDs of stage, project, scenario), covering 100% of parameters. The description does not add further semantic meaning beyond the generic 'for a deployment', 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the specific resource ('canary analysis step list for a deployment'), which distinguishes it from sibling tools like ncloud_sourcedeploy_get_canary_analysis_report. It is direct and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when retrieving the step list for a canary analysis, but it does not explicitly compare with alternatives such as the canary analysis report tool. No exclusions or when-not-to-use guidance is provided, so it remains at an implied level.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_get_stageA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds 'detailed information' but does not disclose specifics about the response structure or any additional behavioral context. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that immediately conveys the action and target. There is no redundant or unnecessary text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-ID operation with a readOnlyHint and fully described parameters, the description is adequate. It clearly states the intent, though it does not enumerate the specific details returned, which is acceptable given the tool's simplicity and lack of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage for both parameters (projectId and stageId). The description adds no extra meaning 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the resource ('detailed information about a specific deployment stage'). The word 'specific' distinguishes it from sibling list_stages, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied: use this when you need details for a single stage, likely after calling list_stages. However, no explicit alternatives or when-not-to-use guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_list_scenariosA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the safety profile is already conveyed. The description adds no extra behavioral context such as pagination, ordering, or response format. It is consistent with annotations, but lacks additional transparency beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler or redundancy. It states the action, resource, and scope efficiently, making it extremely concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with two well-documented required parameters and no output schema, the description sufficiently conveys purpose. It lacks explicit response details, but given the low complexity and strong schema coverage, the description is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters (projectId and stageId) have clear descriptions in the schema, achieving 100% coverage. The description does not add additional semantic detail about parameter relationships or formats, so it does not exceed the schema's value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' with resource 'deployment scenarios' and scope 'in a SourceDeploy project stage', clearly distinguishing it from sibling tools like get_scenario (single scenario) and create/delete scenario operations. It unambiguously communicates the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for listing scenarios in a stage, but provides no explicit guidance on when to choose this tool over alternatives such as get_scenario or create_scenario. There are no exclusionary statements or contextual cues beyond the basic read-only purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_list_stagesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, so the safety profile is covered. The description adds no additional behavioral context beyond the read-only list operation, but for a simple list tool with a strong annotation, this is acceptable and does not contradict the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It earns its place by precisely stating the action and scope, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with one parameter, good schema coverage, and a clear sibling group, the description is mostly complete. However, it lacks any hint about return type, ordering, or pagination, which could be useful since there is no output schema. Still, the tool's simplicity and the presence of the read-only annotation make this a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (projectId has a description). The description adds no new meaning beyond what the schema already states, which meets the baseline for adequately documented parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all deployment stages in a SourceDeploy project' uses a specific verb ('List') and resource ('deployment stages in a SourceDeploy project'), clearly distinguishing it from sibling tools like get_stage (single stage) and create/edit/delete_stage (mutations).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied: to retrieve all stages for a given project. However, there is no explicit guidance on when to use this tool over alternatives (e.g., get_stage for a single stage) or when not to use it, leaving the agent to infer the appropriate context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_update_asgA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false. The description adds only a list of example settings and does not disclose whether unspecified settings remain unchanged or how the update is applied (e.g., rolling, immediate). It doesn't contradict annotations but adds minimal behavioral context beyond the example fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, front-loaded with the action and resource, with examples in parentheses. Every word earns its place; there is no repetition of schema details or extraneous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 7-parameter update tool with annotations but no output schema, the description communicates the core purpose and common settings effectively. However, it does not explain that only provided parameters are updated (unchanged settings persist) or what the response indicates, leaving some ambiguity for the agent to infer operational semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all 7 parameters with 100% coverage, so the description's examples (min/max size, desired capacity, cooldown) merely reinforce schema fields without adding new semantics. Baseline 3 applies because the schema carries the full parameter documentation burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Update' with a clear resource ('existing Auto Scaling Group configuration') and provides concrete examples of the config fields (min/max size, desired capacity, cooldown), distinguishing it from create/delete ASG tools and ncloud_set_desired_capacity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for modifying an existing ASG configuration, but it does not mention any alternatives such as ncloud_set_desired_capacity for single-parameter updates or specify when not to use it. No prerequisites or exclusions are given, making the usage context only 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.

• ncloud_update_extended_disableA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare idempotentHint=true and destructiveHint=false, establishing the safety profile. The description adds little beyond the core action; it does not explain consequences of disabling extended metrics or what happens to collected data. However, the annotation coverage reduces the burden, and the action is clearly non-destructive per 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that states the action and target without redundancy. Every word contributes to clarity, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with only two fully described parameters, a clear purpose, and supportive annotations, the description is adequately complete. It does not mention return values or side effects, but the simplicity and schema coverage make it sufficient for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters (cw_key and instanceIds) are fully described in the schema with 100% coverage. The description adds no additional meaning beyond the schema's field descriptions, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Disable' and specifies the resource 'Extended Metric collection for instances in Cloud Insight', clearly identifying the action and scope. It distinguishes itself from the sibling tool ncloud_update_extended_enable by describing the opposite operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case—disabling extended metrics for given instances—but does not explicitly state when to use this tool versus alternatives or mention any exclusions or prerequisites. There is no reference to the complementary enable tool, though the context makes the purpose fairly evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_update_monitor_groupA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, and the description is consistent with them. It adds only the precondition that the group must already exist, without disclosing whether parameters are merged or fully replaced or how the update affects associated rules.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that states exactly what the tool does with no filler or repetition. Every word adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a three-parameter update tool with good schema coverage and safety annotations, the description is sufficient for selection. It could optionally mention how to retrieve the monitorGroupId or clarify that groupName/resourceList are optional, but the schema already covers those details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter has a description (e.g., 'New name for the monitor group'). The tool description adds no additional parameter semantics beyond the schema, which sets the baseline at 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Update') with a specific resource ('existing Cloud Insight monitoring target group'), clearly distinguishing it from sibling create/get/delete monitor group tools. It accurately represents the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'existing' qualifier implies this tool is for modifying an already-created monitor group, not for creation or deletion. However, it does not explicitly name alternatives or state when not to use it, so usage guidance is mostly inferred from the operation name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_wms_get_result_detailA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds useful context about what the detailed results include (load time, transactions/steps, error logs). It doesn't disclose additional behavioral traits like pagination, data format, or error conditions, but the read-only nature is covered by annotations. This adds some value beyond annotations but is not extensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that immediately conveys the tool's purpose and content. There is no unnecessary information, making it highly efficient and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 three fully documented parameters and no output schema, the description covers the return content adequately (load time, transactions/steps, error logs). It doesn't mention edge cases or output format, but the tool is straightforward enough that this is sufficient. Slight deduction for not hinting at how 'type' affects the data or any usage restrictions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, providing clear descriptions for all three parameters. The description does not add any additional parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get detailed results (load time, transactions/steps, error logs) for a specific WMS monitoring result.' This uses a specific verb and resource, and distinguishes from sibling tools like get_results by emphasizing 'detailed' and 'specific monitoring result'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: you need a specific scenarioId and resultId, so this is for when you already have a monitoring result and want detailed information. However, it doesn't explicitly contrast with alternatives like get_results or list_monitors, nor provide exclusions. Usage is implied but not fully articulated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_wms_list_monitorsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses this is a listing operation and mentions 'all' scenarios, implying no filtering. The readOnlyHint annotation already covers the safety profile, so minimal additional behavioral context is added beyond what the annotation provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no redundant information. Every word contributes to understanding the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list operation, the description conveys the primary purpose adequately. It lacks notes on pagination, return format, or permission requirements, but given the tool's simplicity, the description is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema is trivially complete. The description adds the nuance that it lists 'all' scenarios, which is the only semantic detail beyond the empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists all Web Service Monitoring (WMS) scenarios, using a specific verb-resource pair. It distinguishes from sibling get/update tools like ncloud_wms_get_monitor and ncloud_wms_set_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like ncloud_wms_get_results or ncloud_list_monitor_groups. It simply states the action without context, exclusions, or alternative references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_add_port_pluginA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation destructiveHint=false already covers non-destructiveness. The description adds little beyond stating the add action; it does not disclose idempotency, whether existing plugins are preserved, or any server state requirements. No contradiction with annotations, but no extra behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with no filler words. It is appropriately front-loaded and concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a simple 3-parameter schema and a non-destructive annotation, but no output schema. The description does not mention response format, error conditions, or how this differs from ncloud_set_port_plugins, leaving some gaps for an agent. However, the schema and annotation provide adequate baseline context for a basic add operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all three properties described (type with default and enum, portList as port numbers, instanceNo as server instance number). The tool description adds no parameter-level meaning beyond the schema, matching the baseline for high coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Add') and resource ('port monitoring plugin(s)') and targets 'a server instance', clearly distinguishing it from sibling tools like ncloud_list_port_plugins or ncloud_remove_port_plugin. It immediately conveys the action and scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context that this tool is for adding port monitoring plugins to a server, which distinguishes it from list/remove/get/set siblings. However, it does not explicitly mention when not to use it or name alternatives, so it lacks full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_assign_secondary_ipsA
  3.9/5.0
  Behavior2/5

  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 only states the action and parameter choice, but does not mention any side effects, prerequisites (e.g., network interface must exist), limitations, or whether the assignment is immediate or asynchronous. This is a significant gap for a mutation operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose, and every piece of information is useful. There is no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with complete schema coverage, the description is adequate but lacks contextual details such as expected output, whether the operation is reversible, or any constraints on the number of secondary IPs. The lack of annotations and output schema makes the description the only source for such behavior, but it remains minimal.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameter descriptions, but the description adds crucial semantic context by indicating that secondaryIpList and secondaryIpCount are mutually exclusive alternatives. This is not present in the schema, which merely lists the parameters without this relationship.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Assign') and resource ('secondary IPs to a network interface'), clearly stating the tool's function. It also distinguishes from the sibling tool ncloud_unassign_secondary_ips by the action of assigning versus unassigning.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by explaining the two modes: provide either secondaryIpList or secondaryIpCount. This helps the agent choose the right parameters. However, it does not explicitly mention alternatives or when not to use this tool, but the name and clear action make the use case evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_get_vpc_listA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers safety. The description adds the qualifier 'available', implying a filtered list, but doesn't define what 'available' means (e.g., region, subnet availability). It provides some context but lacks depth.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that is concise and free of filler. Every word contributes meaning, with 'available' and 'for CDSS cluster creation' adding value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter read-only lookup, the description is complete enough. It explains what it returns (a list) and why (CDSS cluster creation). Without an output schema, it could specify return fields, but the simplicity of the tool makes this acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters and 100% schema coverage, there is nothing to explain. The baseline for 0 params is 4, and the description correctly focuses on purpose rather than parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Get') and resource ('VPC list') with a clear context ('for CDSS cluster creation'). It distinguishes itself from generic VPC tools by targeting CDSS, though it doesn't explicitly differentiate from siblings like ncloud_list_vpcs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for CDSS cluster creation' provides clear usage context: use this tool when preparing to create a CDSS cluster. However, it does not mention alternatives or when not to use it, though the CDSS-specific name helps.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_asgA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare destructiveHint=false, and the description does not contradict this. The description adds useful dryRun behavior (preview without creating), which is beyond the annotation. However, it does not disclose other behavioral aspects such as possible cost implications, prerequisites like an existing launch configuration, or that creation may be asynchronous. The dryRun insight is helpful but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: two short sentences that front-load the core purpose and immediately mention the dryRun option. Every word earns its place, with no redundant content or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create tool with 13 parameters and no output schema, the description is somewhat sparse. It omits what the response will contain (e.g., created ASG details) and does not mention prerequisites like needing a launch configuration or subnet list (though these are in required schema). The dryRun preview is a nice touch, but the description could be more complete regarding return behavior and setup expectations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with every parameter already described in the input schema. The tool description adds no extra parameter semantics beyond highlighting dryRun (which is already in the schema). Baseline 3 is appropriate since the schema handles parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Create a new Auto Scaling Group', which is a specific verb+resource combination. It distinguishes from sibling tools like ncloud_delete_asg, ncloud_list_asgs, and ncloud_update_asg by focusing on the creation action. The dryRun hint adds further functional clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it evident this tool is for creating a new ASG, and the dryRun=true guidance provides a preview alternative before actual creation. However, it does not explicitly mention when not to use it or compare with alternatives like update_asg or set_desired_capacity, though the creation context is clearly implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_nas_volumeA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only state destructiveHint=false. The description adds the behavioral nuance that dryRun=true returns a preview without actually creating, which is useful context beyond the schema and annotations. However, it does not disclose other behavioral traits such as asynchronous execution, cost implications, or permission requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no filler. The first sentence front-loads the action, and the second provides a distinct usage tip, making every word earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex create tool with 12 parameters, no output schema, and minimal annotations, the description is quite sparse. The schema covers parameter semantics, but the description omits return value expectations, prerequisites, or operational considerations beyond dryRun. It is adequate but leaves gaps for such a complex operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% parameter coverage with detailed descriptions for all 12 parameters, so the description doesn't need to add parameter meaning. Mentioning dryRun is redundant with the schema's description, and no other param semantics are provided. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Create' and names the resource 'new NAS volume instance', clearly distinguishing it from sibling tools that list, get, change, or delete NAS volumes. It also signals the alternative dryRun mode, reinforcing that this is the creation entry point.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear usage tip: 'Use dryRun=true to preview', which tells the agent when to use the dryRun flag. It does not explicitly compare with alternatives like create_nas_snapshot or list_nas_volumes, but the verb and resource name imply the creation context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_pipelineA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only provide destructiveHint=false, which is consistent with 'Create'. The description adds 'SourcePipeline' specificity but does not disclose additional behavior like return values, prerequisites, or the effect of dryRun. Since annotations are minimal, the description carries some burden but provides little extra behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One short, front-loaded sentence that captures the tool's purpose without waste. No redundancy or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the complex nested schema and no output schema, the description is minimal. It explains what the tool does but lacks information about return format, prerequisites beyond schema, or side effects. Adequate for tool selection but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so all parameters are described in the schema. The description only mentions 'tasks' and 'optional triggers', which adds no meaning beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create') and resource ('SourcePipeline pipeline'), and mentions key components ('tasks', 'optional triggers'). It clearly distinguishes from sibling update/delete/list/run pipeline tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The verb 'Create' clearly indicates when to use this tool (for creating new pipelines). However, it does not explicitly mention alternatives or exclusions (e.g., 'use update_pipeline for existing pipelines'). Context is clear enough without explicit alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_rule_directlyA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description clearly states the action (create) and the non-destructive nature aligns with destructiveHint=false. However, it does not disclose potential side effects, required permissions, failure modes, or what the response contains, so behavioral disclosure is minimal 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that leads with the action and key differentiator. Every word contributes value, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (5 parameters, nested arrays), the description is adequate for basic understanding but lacks context about prerequisites (e.g., how to obtain prodKey or metricGroupItemId) and does not mention what a successful call returns (e.g., rule ID). The schema covers parameter details, but the description could be more complete for a creation operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for all parameters, so the description does not need to add parameter-level details. It does loosely map 'monitoring targets' to resourceList and 'metrics' to cfgRuleList, but this adds limited meaning beyond the schema's own descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Create a Cloud Insight event rule'. It also distinguishes itself from alternatives by noting 'directly specifying monitoring targets and metrics (without pre-created groups)', which clearly separates it from rule-group-based creation tools in the sibling list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when you want to create an event rule without requiring pre-created groups. This provides clear context for selection, though it does not explicitly name alternative tools or list negative use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_sub_accountA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include only destructiveHint:false, and the description adds the valuable dry-run behavior, which is a safety feature not covered by annotations. It discloses a key behavioral trait: the ability to preview without side effects. However, it does not mention potential requirements like permissions, the fact that creating an access key is tied to canAPIGatewayAccess, or the return payload, leaving some behavioral aspects undisclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the primary purpose and followed by a practical tip. Every word earns its place, with no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 11 parameters and no output schema, the description is quite minimal. It covers the core purpose and a key usage flag, but does not explain what the response contains, any prerequisites, or common failure modes. The high schema coverage helps, but the description leaves the agent to infer broader context for a complex create operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are already well-documented in the input schema. The description mainly restates the dryRun parameter's purpose (preview without creating), which is already in the schema. It does not add meaningful new semantics for other parameters, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Create a new sub account (IAM user)' with a specific verb and resource, distinguishing this from sibling tools like create_group or delete_sub_account. The parenthetical IAM user further clarifies the resource type, leaving no ambiguity about the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a specific usage tip ('Use dryRun=true to preview without creating') but does not explicitly discuss when to use this tool versus alternatives such as create_group or attach_policy. The intended use is implied by the tool name, but without explicit guidance on choosing between related IAM tools, the usage context is only partially clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_cache_usersA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds operational context beyond the annotations: it warns with '⚠️ Destructive,' and instructs 'Set confirm=true to execute,' which is a crucial behavioral requirement not in the annotations. It clarifies that deletion is of ACL users. The annotations already declare destructiveHint=true and idempotentHint=true, but the description reinforces the destructive nature and adds the confirmation mechanism. No contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a clear warning symbol, the action, the resource, and the key execution requirement. Every element is functional; there is zero waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a destructive delete operation with no output schema. The description states the core action and confirmation requirement, but does not describe the immediate effect, return value, or whether the operation is asynchronous. Given the annotations and schema, the description is adequate but could benefit from mentioning that the deletion is permanent and affects authentication immediately, or what happens after successful deletion.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 cloudCacheInstanceNo, userNameList, confirm, and regionCode with descriptions. The description references the confirm parameter and the userNameList concept, but does not add new parameter-level information beyond what the schema provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Delete DB users (ACL) from a Cloud DB for Cache (Redis/Valkey) instance.' The verb is specific ('Delete'), the resource is clearly identified ('DB users (ACL)'), and the context (Cloud DB for Cache with Redis/Valkey) distinguishes it from sibling tools like add_cache_users, change_cache_users, and list_cache_users.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating the action and the need to 'Set confirm=true to execute.' It does not explicitly name alternatives or provide when/when-not guidance. It does communicate that this is a destructive operation requiring explicit confirmation, but lacks exclusionary or alternative-tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_drm_get_license_statisticsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds no further behavioral context such as return format, pagination behavior, or whether results are aggregated or raw records. It does not contradict annotations, but also adds minimal value beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that front-loads the tool's purpose and then lists the key filter dimensions. Every word earns its place with no redundancy or padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 8 parameters and no output schema, and the description covers the main purpose and filter types. However, it does not mention pagination parameters (pageNo/pageSize) or clarify whether the response is a list of records or aggregated statistics. Given the complexity and absence of an output schema, this is a noticeable gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters are already documented. The description adds value by grouping the filters into meaningful categories ('content/user/device, time range, status'), which helps agents intuitively map their intent to the available parameters. This goes beyond the schema's individual parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Get') and resource ('DRM license issuance statistics/history for a site'), and distinguishes this tool from siblings like ncloud_drm_get_site_logs or ncloud_drm_get_policy_logs. The filterable dimensions further clarify the scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for querying license issuance history/statistics, but it does not explicitly state when to use it over alternatives or mention exclusions. The context is clear enough for a straightforward read-only stats tool, but no alternative guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_export_postgresql_logA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, so the description's job is to add context. It discloses destination ('Object Storage') but does not mention whether the bucket must exist, whether overwrites occur, or response/async behavior. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with action and resource, and includes a helpful pointer to prerequisite tool. No redundant phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, description should explain what the tool returns. It does not. It also doesn't discuss prerequisites (bucket existence, permissions) or whether the operation is asynchronous. However, readOnlyHint and schema cover much of the context, making it adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 100% description coverage; all six parameters are described. The description adds no parameter details beyond the schema, only reiterates that fileName comes from ncloud_list_postgresql_logs. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Specific verb 'Export' + resource 'Cloud DB for PostgreSQL server log file' + destination 'Object Storage'. Distinguishes from sibling export tools (export_mysql_log, export_postgresql_backup) by explicit resource and target.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  States prerequisite: use ncloud_list_postgresql_logs to obtain log files. Does not explicitly exclude alternatives (e.g., ncloud_export_postgresql_backup), but gives clear context for its intended purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_functions_create_triggerA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only include destructiveHint:false, so the description adds value by clarifying that the tool can both create and update (an upsert behavior). This goes beyond the tool name and the annotation. However, it does not disclose side effects like overwriting existing trigger configurations or permission requirements, but given the annotation coverage this is a reasonable level of transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single six-word sentence that is front-loaded with the verb and resource. There is no filler, redundancy, or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has moderate complexity with nested objects like 'trigger' whose structure 'varies by type' and an open-ended additionalProperties schema. The description does not explain return values (no output schema) or type-specific configuration requirements. While the schema provides enum values and partial hints, the sparse description leaves notable gaps for correctly constructing configuration objects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with all five parameters having descriptions and two having enums. The tool description adds no additional parameter meaning, so the baseline score of 3 applies per the rubric.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Create or update a Cloud Functions trigger' uses a specific verb and resource, clearly distinguishing it from sibling tools like ncloud_functions_create_action, ncloud_functions_create_package, ncloud_functions_delete_trigger, and ncloud_functions_invoke_trigger. It precisely conveys both creation and update operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  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, such as 'for listing triggers use list_triggers'. Usage is implied by the tool name and sibling context, but there are no stated exclusions or prerequisites. It is adequate but not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_acg_detailA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the safety profile is already conveyed. The description adds that it returns 'detailed information' about a specific ACG but does not disclose response format, pagination, error behavior, or permission requirements. With annotations covering the key behavioral concern, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  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 resource with no filler or redundancy. It is immediately scannable and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 well-documented parameter, the description is sufficient to convey the tool's purpose and scope. No output schema is required for understanding the basic operation, and the sibling tool context clarifies naming conventions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the single required parameter (accessControlGroupNo), which already includes a description. The tool description adds no extra parameter-level semantics beyond the existing schema and the word 'specific', which is implicit in the endpoint.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') with a clear resource ('Access Control Group') and scope ('detailed information about a specific'). This distinguishes it from sibling tools like ncloud_list_acgs (which lists all) and ncloud_get_acg_rules (which fetches rules).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided on when to use this tool versus alternatives such as ncloud_list_acgs or ncloud_get_acg_rules. The word 'specific' implies it is for a single ACG, but the description does not mention alternatives or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_log_count_by_periodA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation. The description reinforces that with 'Get', but does not add behavioral details such as the output format (e.g., time series) or any limitations. The bar is lower due to the annotation, and the description provides some value by clarifying the time-interval scope, but it's not rich behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that immediately conveys the core action. It is concise with no redundant information, achieving maximum efficiency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple, and the schema covers all parameters. However, with no output schema, the description does not clarify what the return value looks like (e.g., counts grouped by interval). Given the sibling tools, a more explicit explanation of the output could improve completeness, but the current description is minimally adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with clear descriptions for startTime, endTime, interval, and regionCode. The description does not add any parameter-level meaning beyond what the schema already provides. Per the baseline rule, a score of 3 is appropriate when the schema fully documents parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: getting log counts over a time interval. It specifies the resource (log counts) and the key qualifier (time interval), distinguishing it from sibling tools like get_log_count_total, get_log_count_recent, and get_log_count_by_type. The verb 'get' is appropriate for a read-only operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'over a time interval' provides clear context for when to use this tool, implying it's for time-bucketed counts. However, it does not explicitly mention alternatives or when not to use it, which is a minor gap given the many sibling tools. Still, the context is unambiguous and not misleading.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_network_acl_detailA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this is a safe read operation. The description adds no extra behavioral details such as response contents, pagination, or errors, though with a simple get-by-ID tool this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler or redundant information, perfectly sized for this simple tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the tool is simple with one required parameter and a read-only annotation, there is no output schema and the description does not clarify what 'detailed information' includes, leaving the agent to infer the return structure.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the parameter networkAclNo is described as 'Network ACL number to query'. The description adds no additional parameter meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource ('Get detailed information about a specific Network ACL'), clearly distinguishing it from sibling tools like ncloud_list_network_acls and ncloud_get_network_acl_rules.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'a specific Network ACL' clearly implies the tool is for querying one ACL by identifier, but it does not explicitly name alternatives or state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_globalcdn_request_purgeA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations include destructiveHint=false, so the agent already knows this is not a destructive operation in the data-loss sense. The description adds that it purges whole or specific files via isWholeDomain/isWholePurge, but this is essentially parameter guidance. It does not disclose additional behavioral traits like asynchronous processing, propagation delay, or irreversibility beyond the basic 'purge' action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loads the core action ('Request a Global CDN cache purge'), and wastes no words. The second sentence succinctly summarizes the two key boolean parameters, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description does not mention what the API returns (e.g., a purge request ID) or that the purge might be asynchronous and take time to propagate. While the operation is straightforward and the schema covers parameters, these missing operational details are clear gaps for an agent invoking the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with detailed descriptions for each parameter already present. The description adds minimal extra meaning beyond noting that isWholeDomain/isWholePurge select scope, which mostly restates schema information. The baseline of 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool requests a Global CDN cache purge (invalidation), with a specific verb 'request', resource 'Global CDN cache', and scope ('whole content or specific files'). It explicitly mentions 'Global CDN', distinguishing it from the sibling tool 'ncloud_cdnplus_request_purge' for CDN+.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description prominently names 'Global CDN', making the intended context clear (use this for Global CDN cache purges). It does not explicitly list alternatives or exclusions, but the product-specific naming and sibling tool names provide sufficient differentiation for an agent to select this tool correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_hadoop_create_clusterA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that HA is always enabled (2 master nodes) and that dryRun provides a preview, adding useful context beyond the destructiveHint annotation. However, it does not cover other behavioral aspects like asynchronous creation, expected wait times, or post-creation status, so transparency is only partially addressed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences, each contributing a distinct piece of information: the action (create), a key characteristic (HA with 2 master nodes), and a usage tip (dryRun). There is no fluff or repetition, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex 29-parameter creation tool with no output schema, the description is minimal. It provides high-level context (HA, dryRun) and the schema fills parameter-level detail, but it lacks guidance on workflows like listing cluster types, checking login keys, or what to do after creation. The description is adequate but not complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema covers all parameters with descriptions (100% coverage), the description adds meaning beyond the schema: it explains that HA is forced (so no master node count parameter is needed) and clarifies the dryRun parameter's purpose as a preview mode. This extra context aids parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Create a new Cloud Hadoop cluster' with a specific verb and resource. It adds a distinguishing detail (HA always enabled, 2 master nodes) and mentions dryRun, making the tool's intent unambiguous even among many sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when a Cloud Hadoop cluster needs to be created, but it does not explicitly compare to alternatives or state prerequisites such as needing VPC subnets or consulting cluster type lists. The only usage hint is 'Use dryRun=true to preview', which applies to invocation rather than tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_create_custom_keyA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only provide destructiveHint=false, so the description carries the burden. It adds that only AES256/RSA2048 are supported and frames the operation as generating a wrapped key. However, it omits significant behavioral traits such as the deterministic effect of the 'context' parameter (convergent encryption) and the security sensitivity of requestPlainKey, which returns a plaintext key.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, each earning its place: the first states the core action and object, the second gives the purpose, and the third lists a key constraint. No redundancy or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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 ideally should explain what the tool returns (e.g., a wrapped key, with plaintext optionally when requestPlainKey is true). It does not describe the return structure or mention prerequisites like the master key existing. These gaps matter for a security-focused API, though the core function is adequately conveyed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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's mention of 'Only AES256 or RSA2048 key types supported' adds a useful constraint, but it is ambiguous relative to the bits parameter which lists 128/256/512, and there is no explicit mapping between bits and key type. Thus, added value beyond the schema is limited.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Generate a random raw key (data encryption key) wrapped by the specified master key.' It also specifies the use case ('Used for envelope encryption') and distinguishes from other KMS operations like create_key, which creates a master key, and encrypt/decrypt, which operate on existing data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly identifies the intended scenario: 'Used for envelope encryption,' giving an agent clear context for when to choose this tool. It does not explicitly name alternative tools or exclusions, but within the KMS family, the envelope encryption phrasing sufficiently directs usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_reencryptA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are empty, so the description carries the full burden. It usefully discloses that only AES256 or RSA2048 key types are supported and that re-encryption uses the latest key version. However, it does not disclose the output format, whether the original ciphertext is replaced or returned, or any side effects such as requiring certain permissions. This leaves important behavioral details unstated.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences, front-loaded with the primary action. Every sentence adds relevant information (what it does, when to use, constraints), with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema and no annotations, the description covers the core purpose and a key constraint (supported key types) but omits the return behavior. It does not explain what the tool returns (e.g., new ciphertext) or how the 'context' parameter affects the operation, leaving gaps for an agent unfamiliar with KMS. It is adequate but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides complete descriptions for all three parameters (keyTag, context, ciphertext), including that ciphertext can be a string or array. The tool description adds no parameter-specific detail beyond what the schema provides, so it meets the baseline for high schema coverage but does not go beyond it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Re-encrypt') and resource ('ciphertext with the latest version of the specified master key'), making the tool's function unambiguous. It also distinguishes itself from related KMS siblings like ncloud_kms_encrypt and ncloud_kms_decrypt by focusing on re-encryption after key rotation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly provides a use case: 'Used after key rotation to update encrypted data.' This gives clear context for when to invoke the tool. It does not explicitly list exclusions or alternatives, but the stated purpose is sufficient for an agent to select it appropriately among the many KMS operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_block_storageA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already signals that the tool performs a read-only operation, so the description's 'List' is consistent. The description adds the important 'current region' scoping constraint, but does not disclose pagination behavior, response format, or whether filters change the 'all' semantics. With annotations covering safety, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with zero wasted words. Every term ('List', 'block storage instances', 'current region') is meaningful and directly conveys the tool's function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the description is clear and the schema/annotations handle parameters and safety, the description is minimal. It does not mention that the tool supports filtering (despite saying 'List all') nor describe the return structure or pagination behavior. For a list tool without an output schema, this could leave the agent uncertain about what fields are returned. The description is adequate but has clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All four parameters in the schema have descriptions covering pagination pageNo/pageSize and filtering by serverInstanceNo/blockStorageInstanceNoList. The tool description adds no additional parameter semantics beyond what the schema already provides. According to the rubric, this is baseline 3 because schema coverage is 100%.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all block storage instances in the current region' uses a specific verb ('List') and resource ('block storage instances'), with clear scope ('current region'). It clearly distinguishes from sibling tools like ncloud_get_block_storage_detail (get a single instance) and ncloud_create_block_storage (create).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates the tool's use case: listing block storage instances. It does not explicitly mention exclusions or name alternative tools (e.g., 'for a single instance, use get_block_storage_detail'), but the context is straightforward and implies when to use this list operation. No misleading guidance is present.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_dashboardsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation, and the description is consistent with that. However, the description adds no further behavioral context beyond the annotation, such as return format or any edge cases. With annotations covering the safety profile, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It conveys the tool's purpose efficiently and is appropriately concise for a simple list operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool without an output schema, the description is sufficiently complete. It clearly indicates that the tool retrieves dashboards, and no additional context is needed for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema fully covers the input surface. According to the scoring rule, 0 params yields a baseline of 4. The description does not need to explain any parameters, and it doesn't.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get the list') and the resource ('Cloud Insight monitoring dashboards'). It is specific and distinct from sibling tools like ncloud_get_dashboard_widgets or ncloud_query_widget_preview, which focus on widgets rather than the dashboards themselves.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or relationships with other dashboard-related tools, leaving the agent to infer the usage context entirely.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_nat_gatewaysA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description's 'List' is consistent with a safe read operation. The description adds useful context by specifying the scope as 'current region' and noting that it lists all instances. This goes beyond the annotation but does not describe pagination or return format, making it slightly above average.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clean sentence that conveys the essential purpose without any unnecessary words or repetition. It is front-loaded with the verb and resource, making it highly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the schema documents all parameters, the description gives no information about pagination behavior, default result size, response structure (no output schema exists), or whether filters are optional. This is adequate for a simple list tool but leaves gaps for an agent unfamiliar with NAT Gateway APIs.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each of the 13 parameters fully documented in the schema. The description itself adds no parameter-specific details beyond what the schema already 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb (List) and clear resource (NAT Gateway instances) with a defined scope (current region). This clearly distinguishes it from sibling tools like ncloud_get_nat_gateway_detail, which fetches a single instance, and from create/delete/set tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for listing all NAT Gateways, but it does not explicitly state when to choose this over alternatives like ncloud_get_nat_gateway_detail or provide exclusion criteria. The intended use case is reasonably clear from the name and description, but no explicit guidance is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pca_create_ocspA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that the tool deploys the URL to existing certificates, which is a side-effect beyond the annotation's non-destructive hint. It does not mention whether existing OCSP settings are overwritten, idempotency, or any prerequisites. The annotation only confirms non-destructive, so the description adds some behavioral context but not rich detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is immediately informative and free of redundant wording. It front-loads the primary action and avoids verbose explanations, making it easy for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with no output schema, the description provides the core purpose but leaves out operational details like what the API returns, prerequisites, or how to verify success. The lack of an output schema increases the burden on the description to explain outcomes, which it does not fully address. It is adequate but not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 details beyond 'caTag' and 'ocspServers' already described in the schema. The mention of deploying to certificates indirectly ties the parameters together, but no new semantic information is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action (create OCSP) and the resource scope (deploy URL to certificates of this CA). It distinguishes from sibling tools like ncloud_pca_delete_ocsp by specifying creation and deployment. The verb 'Create' and the target 'OCSP' are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case (setting up OCSP for a CA) but does not provide explicit alternatives or exclusions. Sibling tools like ncloud_pca_delete_ocsp exist, but no guidance is given on when to choose one over the other. However, the context is clear enough that an agent can infer the appropriate scenario.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_acg_inbound_ruleA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the destructiveHint annotation, the description adds crucial behavioral context: 'Set confirm=true to execute.' This explains the safety confirmation mechanism not visible in annotations, though it does not elaborate on other behavioral aspects like idempotency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with the destructive warning front-loaded. Every word provides value, and there is no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the schema and annotations cover parameters and safety, the description lacks context about prerequisites, mutual exclusions (e.g., ipBlock vs accessControlGroupSequence), and what happens after removal. It is minimally adequate but not rich.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameter semantics are fully covered by the schema. The description's mention of confirm=true adds no new information beyond what the schema already states for that parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'Remove an inbound rule from an Access Control Group' using a specific verb and resource. It clearly distinguishes from sibling tools like ncloud_add_acg_inbound_rule and ncloud_remove_acg_outbound_rule.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide explicit guidance on when to use this tool versus alternatives. The name and context imply usage for removing inbound ACG rules, but there is no mention of exclusions or references to sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_nic_acgA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the destructiveHint and idempotentHint annotations, the description adds the crucial behavioral requirement that confirm must be true to execute, which is not part of the annotations. It also provides an explicit warning symbol, reinforcing the destructive nature. However, it does not elaborate on side effects beyond the action itself.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a warning emoji, a clear action, and the confirm requirement. Every phrase earns its place; no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  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 no output schema, the description covers the core purpose and the mandatory confirm flag. However, it lacks explicit usage guidance or reference to the complementary ncloud_add_nic_acg tool, leaving some contextual gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description does not add meaning beyond the schema; it restates the action and the confirm parameter, which is already fully described in the schema ('Must be true to actually execute the destructive operation'). With 100% schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Remove' and the resource 'access control groups (ACGs) from a network interface,' which distinguishes it from related tools like ncloud_add_nic_acg. It also includes the critical safety requirement to set confirm=true, reinforcing the specific action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when ACGs need to be detached from a network interface, but it does not explicitly mention alternative tools or provide when-to-use/when-not-to-use guidance. The sibling ncloud_add_nic_acg exists, but no direct comparison is made.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_get_subnet_list_g3A
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this a safe read operation. The description adds the G3/KVM-specific scope and cluster creation context, but it does not disclose additional behavioral details such as pagination, rate limits, or return format. The description aligns with the annotation and introduces no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 16 words that immediately conveys the action, resource, and constraint. Every word contributes to meaning, with no redundancy or filler. It is front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description should clarify what the return value contains. It says 'available subnet list' but does not explain whether it returns subnet IDs, names, or other fields. It also omits that vpcNo is required to scope the list. For a simple list tool, this is a moderate gap that could lead to uncertainty about the result structure.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single parameter vpcNo with the description 'VPC number'. The tool description adds no extra parameter semantics beyond the schema, so the baseline of 3 is appropriate. It does not explain how to obtain the VPC number or how the parameter affects the result, but the schema already covers its meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: retrieving an available subnet list for Search Engine Service cluster creation. It specifically restricts to G3/KVM, which distinguishes it from the sibling ncloud_ses_get_subnet_list tool. This is a specific verb+resource+constraint combination, not a tautology.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'G3/KVM only' qualifier implies this is the tool to use when creating a G3/KVM Search Engine Service cluster, providing clear context. However, it does not explicitly name alternatives or state when not to use other tools, stopping short of explicit 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.

• ncloud_set_network_acl_descriptionA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond the simple 'set or update' action, such as effects on existing rules or whether the description is required to be non-empty. It does not contradict annotations, but provides no additional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the action and resource. Every word earns its place, with zero redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple update tool with only 2 documented parameters, no output schema, and annotations covering idempotency and destructiveness, the description is fully sufficient. The tool's purpose and required inputs are unambiguous, and no additional context is necessary for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and both parameters are clearly documented ('Network ACL number' and 'New description'). The description adds no extra meaning beyond the schema, but this is acceptable given the high coverage. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Set or update') and the resource ('Network ACL description'), making the tool's purpose unambiguous. It distinguishes from sibling tools like ncloud_get_network_acl_detail or ncloud_delete_network_acl by specifying exactly what it modifies.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for modifying an existing Network ACL's description, but provides no explicit guidance on when to prefer this tool over alternatives (e.g., using ncloud_set_subnet_network_acl for subnet association, or ncloud_create_network_acl for new ACLs). There are no exclusions or alternative recommendations, but the context is clear enough for basic selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcebuild_list_docker_enginesA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes this as a safe read operation. The description adds only the word 'available', which is largely implied by 'List', and does not disclose output format, pagination, or other behavioral details. This is acceptable given the annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The entire description is a single sentence that begins with the verb 'List' and contains no filler. Every word contributes meaning, making it highly concise and well-structured for a simple operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool, the description fully covers what the tool returns (Docker engine versions) and the scope (SourceBuild). No output schema is present, but the purpose is simple enough that no additional context is required.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero properties, and the description correctly implies that no parameters are needed. With no parameters to explain, the baseline of 4 applies, and the description adds no unnecessary parameter detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and identifies the resource as 'Docker engine versions for SourceBuild', which exactly matches the tool name. This clearly differentiates it from sibling tools like ncloud_sourcebuild_list_runtimes or ncloud_sourcebuild_list_os.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives. There are no scenarios, exclusions, or comparisons with sibling list tools such as ncloud_sourcebuild_list_runtime_versions, so the agent has no basis for choosing among similar list operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcebuild_list_runtimesA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation, and the description does not contradict it. The description adds minimal behavioral context beyond the annotation, such as the fact that it is OS-scoped, but does not disclose output format or other behaviors. Given the annotation coverage, this meets the baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded with the verb and object. Every word earns its place, with no redundant or extraneous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one parameter, readOnlyHint annotation, and no output schema, the description is complete enough. It specifies what is listed and the scoping requirement (OS), and the return value is implied by the action of listing runtime types.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with a description for osId that references list_os. The tool description itself adds no additional meaning beyond the schema, so the schema handles the parameter semantics. The cross-reference in the schema is helpful but not attributable to the description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists available runtime types for a specific OS in SourceBuild, with a specific verb and resource. It distinguishes from the sibling tool list_runtime_versions by focusing on types rather than versions, even though this distinction is not explicitly stated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description and schema parameter hint that osId should come from list_os ('OS ID (from list_os)'), which implies a prerequisite. However, there is no explicit guidance on when to use this tool versus alternatives like list_runtime_versions or list_compute, and no exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_vodstation_create_channelA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only provide destructiveHint=false, which is not contradicted. The description adds the dryRun preview behavior but does not disclose other behavioral traits such as costs, prerequisites (e.g., existing storage bucket), or what happens on failure. Given the sparse annotations, more detail would be expected for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two sentences that convey the core action and a key option. It is front-loaded and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 10 parameters and no output schema, yet the description provides only minimal high-level context. It does not mention prerequisites, expected return values, or follow-up steps (e.g., starting the channel after creation). Given the tool's complexity, a bit more context is needed, though the schema covers parameter details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are already well-documented. The description adds no new parameter semantics beyond what the schema provides (the dryRun mention is redundant with the schema description). Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource ('Create a new VOD Station streaming channel') and clearly distinguishes from sibling tools like delete, start, stop, and list. It also mentions the dryRun preview feature, which adds clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 this tool (to create a VOD Station channel) and provides a specific usage tip (dryRun to preview without creating). It does not explicitly name alternatives or exclusions, but the verb 'create' and sibling tool names imply the use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_accept_reject_vpc_peeringA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the behavioral burden. It clearly indicates a mutating action (accept/reject), but does not disclose any consequences, reversibility, or permission requirements. The action itself is simple, but the description adds little beyond the name and schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that clearly communicates the tool's purpose. It is front-loaded with the action verb and resource, with no redundant words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, and the schema fully documents both parameters. The description covers the action and adds the 'pending' requirement. While there is no output schema, for a binary accept/reject action the lack of return value documentation is acceptable. It is complete enough for typical use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for both parameters with clear descriptions (isAccept: true to accept, false to reject; vpcPeeringInstanceNo: VPC Peering instance number). The tool description adds only the 'pending' context, which is already implied by the word 'pending' in the description. No additional parameter meaning is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (accept or reject), the resource (VPC Peering request), and the condition (pending). It distinguishes this tool from sibling tools like create/delete/describe peering by focusing on the response to a pending request.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'pending VPC Peering request' provides clear context that this tool is for responding to requests in a specific state. It does not explicitly name alternatives or exclusions, but the context is strong enough to know when to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_add_cache_usersA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include destructiveHint=false, indicating the operation is not destructive. The description adds some context (ACL management, Redis/Valkey target) but does not disclose behaviors like idempotency, duplicate handling, or permission requirements. It carries reasonable burden given minimal annotation coverage, but lacks rich detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence with no redundancy. It front-loads the action and resource, making it easy to scan and understand.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward add operation with fully described schema and a safety annotation, the description is adequate. It identifies the resource type and operation clearly. Minor gap: no mention of prerequisites (e.g., instance must exist) or whether the operation is synchronous, but these are not critical for tool selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all parameters (regionCode, cloudCacheUserList, cloudCacheInstanceNo) fully described including constraints. The description itself adds no parameter details, but the schema carries the semantic load. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Add' with a clear resource 'DB users (ACL) to a Cloud DB for Cache (Redis/Valkey) instance', distinguishing it from sibling tools like ncloud_change_cache_users and ncloud_delete_cache_users. The target service and operation are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool (to add new ACL users) without explicitly naming alternatives. It differentiates from sibling operations via the verb and resource, but lacks explicit 'use change_cache_users instead' type guidance. Context is clear but exclusions are not stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdnplus_list_instancesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: that filtering by instance number and pagination are supported. It does not contradict the annotation and adds clarity about the operation's optional parameters.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that front-loads the primary action and then notes optional parameters. There is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list operation with three optional parameters, the description covers the essential purpose and parameters. While there is no output schema to explain return values, the verb 'List' implies a collection result, which is sufficient for this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with all three parameters (pageNo, pageSize, cdnInstanceNo) described. The description groups them into 'filtering by instance number' and 'pagination', which adds mild organizational value but does not provide additional details beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('List CDN+ instances') with a specific verb and resource. It also mentions optional filtering and pagination, which precisely scopes the operation and helps distinguish it from other CDN-related tools like monitoring or purge tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by indicating this is for listing CDN+ instances with optional pagination and filtering, but it does not explicitly state when to use it versus alternative tools (e.g., global CDN listing or monitoring). No exclusions or preferred use cases are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_delete_config_groupA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already mark destructiveHint and idempotentHint. The description adds the confirmation gate requirement, which is a meaningful behavioral detail not present in annotations or schema alone.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single short sentence with a front-loaded warning, conveying all essential information without unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation, the description covers the core action, the destructive nature, and the confirmation requirement. It lacks details about post-deletion behavior or prerequisites, but these are not critical given the simple scope and annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers both parameters with concise descriptions, so the description adds little beyond reinforcing the confirm flag. With 100% schema coverage, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Delete a Config Group', with an explicit destructive warning. It distinguishes this tool from siblings that list, create, or apply config groups by its specific delete operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides the execution requirement 'Set confirm=true to execute', but does not explicitly state when to use this tool versus alternatives or any prerequisites. Usage is implied by the resource type and action.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_get_load_balancersA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint: true, and the description is consistent. The description adds context that the returned load balancers are scoped to the CDSS broker node public endpoint, but it does not disclose additional behaviors like return format or filtering criteria. Given the annotation coverage, this is an adequate but unexceptional level of transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no extraneous words. It states the action and resource immediately.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one parameter and a readOnlyHint annotation, the description is sufficient. It clearly explains the purpose and scope. Though the output schema is absent, the tool is simple enough that the description covers the essential context without needing to detail return values.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the sole parameter, serviceGroupInstanceNo, with the description 'Cluster instance number.' The tool description adds no additional parameter-specific insight, so the baseline score of 3 applies due to the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' with a clear resource ('load balancers') and context ('for CDSS broker node public endpoint'), cleanly distinguishing this tool from the generic ncloud_list_load_balancers sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for CDSS broker node public endpoint' provides clear contextual usage guidance, showing when this tool is relevant. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_get_node_productsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description is consistent with the readOnlyHint annotation, describing a 'get' operation. It adds purpose context (CDSS cluster creation) but does not disclose behavioral details such as whether the full list is returned, regional constraints, or output structure. The annotation provides the safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence, front-loaded with the verb 'Get', and zero filler. All words contribute to understanding the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 lookup, the description is adequate. It states what is returned and the context. It could explicitly mention that it returns a list, but the simplicity of the tool and the presence of annotations make this a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters, the schema is trivially covered. The description adds semantic value by explaining that the result is node server types (product codes), which is useful since there are no parameters to describe.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets available node server types (product codes) for CDSS cluster creation. It uses a specific verb ('Get') and resource ('node server types (product codes)'), and the context ('for CDSS cluster creation') distinguishes it from sibling tools that list server specs, generations, or images.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is used when selecting node server types for CDSS cluster creation, but it does not explicitly state when to use this tool versus alternatives like ncloud_cdss_get_server_spec_list or ncloud_cdss_get_server_generations. No exclusions or alternative guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_get_os_monitoringA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds context about the metric type and node scope, but does not disclose other behavioral traits such as response format, node specificity, or time range defaults. This is consistent with the annotation but adds limited incremental transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key distinguishing details. There is no redundant or wasted wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only monitoring tool with a clear description, good annotations, and a 100% documented schema, the contextual information is sufficient. The lack of an output schema is partially mitigated by the descriptive metric types, though return format remains unspecified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description does not add further meaning to the parameters beyond the schema, such as time range semantics or the role of serviceGroupInstanceNo. Baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get'), the resource ('OS-level monitoring metrics'), and the target ('CDSS cluster nodes'), specifying metric types (CPU, memory, disk). This distinguishes it from sibling tools like ncloud_cdss_get_monitoring or ncloud_ses_get_os_monitoring, making its purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly provides usage context by specifying the metric level (OS-level) and resource (CDSS cluster nodes), indicating when this tool should be selected. However, it does not explicitly reference alternative tools or provide exclusions, so it stops short of a full usage guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_get_subnet_listA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation confirms this is a safe read operation, and the description aligns with that. The description adds minimal behavioral context beyond the CDSS-specific purpose, but there is 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no wasted words, front-loading the action and clearly stating the purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with one optional parameter, the description and schema together are sufficient. It doesn't describe the return format, but that's acceptable given the low complexity and no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the single parameter vpcNo with a clear description, so the description does not need to repeat it. Baseline of 3 applies due to 100% schema description coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves an available subnet list specifically for CDSS cluster creation, using a specific verb and resource. It distinguishes from other subnet listing tools like ncloud_ses_get_subnet_list by the CDSS context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for CDSS cluster creation' provides clear context for when to use this tool, implying it should be used in the CDSS cluster creation flow. It does not explicitly mention alternatives or exclusions, but the scoping is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_list_nodesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the read-only nature. The description adds node type context but does not disclose additional behavioral traits like return format or pagination, which are not covered by annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that immediately conveys the operation. No unnecessary words or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one parameter and clear annotations, the description is sufficient. It does not describe the response structure, but that is acceptable given the absence of an output schema and the simple nature of the operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides a description for serviceGroupInstanceNo ('Cluster instance number'), and the tool description does not add further parameter-specific meaning. With 100% schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List), the resource (nodes), and the scope (CDSS cluster), and specifies node types (broker, manager). This distinguishes it from sibling tools like list_clusters and get_cluster_detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it lists nodes in a CDSS cluster, and the required parameter (serviceGroupInstanceNo) indicates the cluster. It does not explicitly compare against alternatives or state exclusions, but the usage context is direct.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_restart_cmakA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already disclose idempotency and non-destructiveness. The description adds only the target component and cluster context, but does not discuss potential side effects like temporary unavailability of the CMAK UI or that only CMAK is restarted, not Kafka brokers. With annotations covering the safety profile, this is a minimal passing score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 14 words, front-loaded with the verb and resource. It contains no fluff or repetition, and every word contributes to understanding what the tool does.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description is adequate. It specifies the operation, resource, and cluster context. Minor gaps like potential downtime or prerequisites are not critical given the annotations cover safety, and the description is otherwise sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with the sole parameter 'serviceGroupInstanceNo' already described as 'Cluster instance number'. The description adds no extra parameter details beyond that, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Restart') and resource ('CMAK (Cluster Manager for Apache Kafka)') with a clear scope ('in a CDSS cluster'). It distinguishes from sibling tools like ncloud_cdss_restart_kafka and ncloud_cdss_restart_all_services by targeting the CMAK component specifically.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly identifies the tool's purpose, making the usage context obvious. However, it does not explicitly state when not to use this tool or mention alternatives (e.g., use restart_kafka for Kafka brokers). The sibling list provides context but the description itself lacks direct comparative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_change_server_specA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds the precondition that the server must be stopped, which is useful context, but it doesn't detail side effects like restart requirements or response behavior, so a moderate score is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that includes the action, object, and key condition without any fluff. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 annotations, the description is mostly complete: it states the operation, the precondition, and is supported by schema and annotations. It stops short of explaining what happens after the change (e.g., whether the server needs to be restarted), but given the simplicity and annotations, it is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for both parameters (serverInstanceNo and serverProductCode), covering 100% of the schema. The description clarifies that 'product code' refers to the server spec, slightly adding meaning, but the schema descriptions are sufficient, so baseline 3 is warranted.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Change'), the target ('server spec'), and an important precondition ('stopped server instance'), making it distinct from sibling tools that list specs or manage servers. The parenthetical '(product code)' adds technical precision.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description specifies that the server must be stopped, providing a clear usage context. However, it doesn't explicitly mention alternatives or when not to use it (e.g., for running servers), so there's room for more explicit exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_bucketA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the dryRun preview behavior, which is beyond the annotations that only declare destructiveHint=false. However, it doesn't disclose other behavioral details such as idempotency, naming constraints, or what happens if the bucket already exists. Given annotations are minimal, the description carries some burden but partially fulfills it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, consisting of two short sentences. It front-loads the primary purpose in the first sentence and adds a valuable usage tip in the second. Every word serves a purpose, with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a relatively simple create operation with only two parameters and no output schema, the description covers the essential purpose and the key dryRun behavior. It doesn't elaborate on return values or error handling, but the tool's low complexity and comprehensive schema make this an adequate level of completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes both parameters (bucketName and dryRun) with clear descriptions. The description's mention of dryRun=true adds a concrete usage example but not new semantic meaning beyond the schema's definition. With 100% schema coverage, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action 'Create' and the resource 'Object Storage bucket', which is specific and distinguishes it from sibling tools like 'delete_bucket' or 'list_buckets'. It uses a direct verb+resource structure with no ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear usage hint with 'Use dryRun=true to preview', which tells the agent when to use this parameter for validation without actually creating. It doesn't explicitly exclude alternatives, but for a simple create operation, the context is sufficient and there are no competing create-bucket tools among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_mysql_recoveryA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only provide `destructiveHint: false`, which the description does not contradict (creating a recovery server is non-destructive to the source instance). The description adds the key behavioral detail that the tool restores from backup or point-in-time, which is useful beyond the annotation. However, it does not disclose any potential side effects, prerequisites (e.g., needing `cloudMysqlInstanceNo` already exist), or what happens to the original instance. With annotations covering the safety profile, the description adds modest context but not rich behavioral transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the action and resource. Every word earns its place: 'Create a Recovery server instance' identifies the operation, and 'Restores from backup file or point-in-time' clarifies the method. There is no redundancy or filler, making it extremely concise and structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 6 parameters and no output schema, the description is reasonably complete: it states the core action and restore methods, while the schema handles parameter details. It does not mention the return value or how to monitor the operation, but for a creation tool that is often acceptable, especially with sibling tools like `ncloud_get_mysql_instance_detail` available for post-creation checks. The description covers the essential decision points, though it could briefly mention the need to specify either `fileName` or `recoveryTime` or reference the prerequisite `cloudMysqlInstanceNo` to be slightly more self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 much beyond the schema: it mentions 'backup file or point-in-time', which loosely maps to `fileName` and `recoveryTime`, but the schema already provides detailed semantics (e.g., mutual exclusivity, format, references to helper tools). Since the schema descriptions are comprehensive and the description adds no new parameter-level meaning, a score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: 'Create a Recovery server instance for a Cloud DB for MySQL instance.' It uses a specific verb ('Create') and a specific resource ('Recovery server instance'), distinguishing it from sibling tools like `ncloud_create_mysql_instance` or `ncloud_create_mysql_slave`. The additional phrase 'Restores from backup file or point-in-time' adds specificity about the recovery purpose, making the tool's function unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for when to use this tool: when recovering a Cloud DB for MySQL from a backup or point-in-time. While it does not explicitly name alternatives or exclusions, the phrase 'Restores from backup file or point-in-time' implies the appropriate use case. Given the sibling list includes `ncloud_create_mysql_instance` (creating a new instance) and `ncloud_create_mysql_slave` (creating a replica), the recovery-specific wording serves as sufficient implicit guidance, though it lacks explicit 'when-not' direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_network_aclA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the VPC scoping detail but does not disclose behaviors such as default rules, idempotency, or return value. The destructiveHint=false annotation already indicates this is a non-destructive operation, and the description is consistent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, clear sentence with no redundant information. Front-loaded with the action and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity, full schema parameter coverage, and non-destructive annotation, the description is adequate. However, it does not specify the response format or any post-create behavior, which could be relevant given the absence of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the description adds no additional parameter meaning beyond what the schema already provides. The parameter descriptions in the schema are sufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Create' and identifies the resource 'Network ACL' with context 'in a VPC', clearly distinguishing it from sibling tools like delete_network_acl or add_network_acl_inbound.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context (a Network ACL within a VPC) but does not explicitly state when to use this versus alternatives, such as when to add rules or delete an ACL. It implies usage but lacks exclusions or alternative references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_server_image_from_snapshotA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include destructiveHint=false, so the agent knows this is not a destructive operation. The description adds no further behavioral context (e.g., whether the operation is asynchronous, effects on the snapshots, or required states). Since annotations already cover the safety profile, the description is adequate but not enriching.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence ('Create a server image from block storage snapshots') that is front-loaded with the action and resource. It contains no redundant words or irrelevant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create operation with no output schema, the description adequately covers the action and source. The schema fully documents parameters. The description lacks details about prerequisites or asynchronous behavior, but is sufficient for a straightforward image creation tool given the available annotations and schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% description coverage for all parameters, so the description does not need to explain basic parameter meaning. It adds the contextual hint that the source is block storage snapshots, but it does not elaborate on relationships between originalServerImageNo and blockStorageSnapshotInstanceNoList. Baseline of 3 is appropriate given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Create' and identifies the resource 'server image' with the source 'block storage snapshots', which clearly differentiates it from sibling image-creation tools like ncloud_create_server_image and ncloud_create_member_server_image.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states the specific use case (creating a server image from block storage snapshots), which implicitly guides the agent to select this tool when working with snapshots. However, it does not explicitly name alternative tools or provide exclusionary guidance, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_acgA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the critical behavioral detail that confirm=true is required to execute, which is not covered by the destructiveHint annotation. This explains the safety mechanism. The idempotentHint annotation is not elaborated, but the confirmation requirement is valuable context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One concise sentence with a clear warning prefix. Every word serves a purpose, front-loading the destructive nature and immediately indicating the execution requirement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward delete operation, the description covers the essential behavior: destructive, requires confirmation, and identifies the resource. The annotations provide safety hints. It lacks details about dependencies or errors, but these are not critical for a simple ACG deletion.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, providing baseline meaning for all parameters. The description adds specific instruction that confirm must be true to execute, enriching the semantic understanding of the confirm parameter beyond its schema description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Delete an Access Control Group' with a specific verb and resource, distinguishing it from sibling operations like ncloud_delete_vpc or ncloud_delete_subnet. The destructive warning immediately identifies the action's nature.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., VPC existence, ACG not in use) or scenarios where deletion is appropriate. The confirm flag is mentioned but not as a usage guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_asgA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare destructiveHint=true and idempotentHint=true. The description adds important context beyond annotations: the operation is permanent and requires confirm=true to execute. This explains the behavior of being gated by a confirmation flag, which annotations do not capture. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with an emoji warning. It immediately conveys the destructive nature, the action, and the required confirmation step. No redundant or unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with two parameters and no output schema, the description covers the essential aspects: destructive action, permanence, and the confirm flag. It does not explain return values, but that is not needed without an output schema. It could mention prerequisites, but the operation is straightforward and the schema covers parameter details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both confirm and autoScalingGroupNo already described. The description's mention of 'Set confirm=true to execute' adds no new meaning beyond the schema's own description of the confirm parameter. The description does not elaborate on autoScalingGroupNo beyond what schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'delete' and the specific resource 'Auto Scaling Group', and adds 'Permanently' to convey irreversibility. This distinguishes it from sibling tools like ncloud_delete_launch_config or ncloud_delete_vpc, which target different resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by warning 'Destructive' and 'Permanently delete', suggesting this is for intentional deletion only. However, it does not explicitly state when to use it instead of alternatives (e.g., update_asg) or provide exclusions. The confirm=true instruction is a parameter-level guideline, not a tool-level usage directive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_cache_config_groupA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructiveHint, but the description adds valuable context: 'Permanently' highlights irreversibility, and 'Set confirm=true to execute' reveals the safety mechanism that prevents accidental deletion without explicit confirmation. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with a clear warning symbol. Every word is purposeful: 'Destructive' warns, 'Permanently' stresses irreversibility, and the confirm requirement is concise. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive delete tool with two well-documented parameters, the description adequately covers purpose, permanence, and the confirmation gate. It could mention dependencies (e.g., whether the config group must be unused) or return values, but the annotations and schema fill most gaps, making it sufficiently complete for safe invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with descriptions for both parameters (cloudCacheConfigGroupNo and confirm). The description's mention of 'confirm=true' mirrors schema content without adding new parameter insights, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('delete') and the specific resource ('Cloud Cache config group'). The word 'Permanently' adds precision about irreversibility, making the tool's purpose unambiguous and easily distinguishable from sibling operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an operational instruction ('Set confirm=true to execute') but no explicit comparison to alternative tools or conditions for when to use this delete operation. Usage is implied by the 'delete' verb, but without exclusion criteria or references to list/create counterparts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_cache_manual_backupA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds crucial context that deletion is permanent and irreversible, and requires an explicit confirm=true flag to execute, which enhances the annotation-provided safety profile without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with an immediate warning and clear action. No filler words; every sentence adds value, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive tool with full schema coverage and appropriate annotations, the description is largely sufficient. It covers the core purpose, safety requirements, and parameters, though it could optionally note idempotency behavior for non-existent backups.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already fully documents both parameters. The description repeats the confirm requirement, adding no additional meaning beyond what the schema states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('delete') and clearly identifies the resource ('Cloud Cache manual backup'), adding 'permanently' to convey the irreversible nature. It distinguishes from sibling tools like list/create manual backup by explicitly stating the delete action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly name alternatives or state when versus when not to use the tool. However, the confirm=true instruction is a usage prerequisite for executing the destructive operation, though it doesn't cover selection criteria among sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_certificateA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful behavioral context beyond the destructiveHint annotation: it emphasizes permanence, requires confirm=true for execution, and warns about dependencies on Load Balancer, CDN+, and Global Edge. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences, each serving a distinct purpose: warning of destructiveness, stating the safety precondition, and specifying the confirmation flag. No fluff or redundant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with full schema coverage and no output schema, the description covers the essential aspects: what is deleted, permanence, dependency check, and confirmation requirement. It could mention success/error behavior, but that is not critical for a destructive action.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents all three parameters with clear descriptions (100% coverage). The description reinforces the confirm=true requirement but does not add significant semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Permanently delete a registered certificate') and identifies the resource type. It distinguishes from sibling tools like ncloud_pca_delete_ca by specifying 'registered certificate' and referencing Load Balancer, CDN+, and Global Edge dependencies.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context (delete when you have an unneeded certificate) and provides a precondition (ensure not in use). However, it does not explicitly contrast with alternatives or state when not to use this tool, leaving usage guidance only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_init_scriptsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as destructive and idempotent, but the description adds critical context: the operation is permanent, supports multiple scripts, and requires confirm=true to execute. This goes beyond the structured fields by explaining the confirmation mechanism and the irreversibility.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that front-loads the destructive warning and clearly states the action and the confirmation requirement. Every word earns its place with no repetition or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 no output schema, the description plus schema fully cover the essentials: what the tool does, the confirmation flag, and the input list. The destructive warning adds important safety context. Some might expect a note about return values or error cases, but given the low complexity, this is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters (initScriptNoList and confirm) having descriptions. The description itself adds no additional parameter information beyond what the schema provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action with a specific verb ('delete') and resource ('init scripts'), and specifies 'permanently' and 'one or more', making the scope explicit. It distinguishes this from other init script tools like list, get, and create.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating the action, but does not explicitly mention when to use this tool versus alternatives or any prerequisites (e.g., obtaining script numbers from list_init_scripts). No exclusions are provided, but the context is clear enough for a simple delete operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_integrationA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint and idempotentHint, and the description adds the specific resource type and the critical behavioral detail that confirm=true is required to execute. It does not contradict the idempotent hint and offers meaningful context beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two short sentences, with the destructive warning front-loaded and the key confirmation instruction included. Every word contributes to understanding the tool's purpose and usage.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with two parameters, the description covers the destructive nature, the specific resource, and the confirmation requirement. Annotations cover idempotency and destructiveness, and no output schema requires return-value explanation. Minor gap: it doesn't explicitly state permanence or post-delete effects, but the destructive warning sufficiently implies them.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters clearly described in the schema. The tool description merely repeats the confirm=true requirement already present in the schema, adding no new parameter semantics. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb 'Delete' and resource 'Cloud Insight integration', distinguishing it from sibling create, update, get, and list operations. The destructive warning reinforces the tool's purpose without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear prerequisite (confirm=true) and warns of destructive behavior, but it does not explicitly state when to use this tool versus alternatives like ncloud_get_integration or ncloud_list_integrations. Usage is implied rather than explicitly contrasted with read or update tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_lb_listenersA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, but the description adds the important confirm=true execution gate and a visual warning. This goes beyond the annotation by explaining the required safety mechanism, even though the schema also documents the confirm parameter.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loaded with a destructive warning, and contains no filler. Every word serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive deletion tool with a well-described schema, the description covers the essential operation and the confirmation requirement. No output schema exists, so omitting return-value details is acceptable. It could be more complete by mentioning prerequisites or side effects, but it is sufficient for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for all three parameters with descriptions. The tool description only reiterates the confirm=true instruction, which adds no new meaning beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Delete listeners from a load balancer' – a specific verb and resource. This distinguishes it from sibling tools like create/list/change listeners, even though alternative tools are not named.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied by the verb and resource: use this to delete listeners. The destructive warning and confirm flag imply caution, but there is no explicit guidance on when to choose this over alternative listener management operations (e.g., changing config).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_load_balancersA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already include destructiveHint=true, but the description adds behavioral context by specifying 'Permanently' and requiring confirm=true. This goes beyond the annotation by clarifying the irreversible nature and the need for explicit confirmation. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise sentence with a clear warning emoji. It fronts the destructive nature and immediately tells the agent what to do (set confirm=true). No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive delete operation, the description covers the critical facts: permanence, the need for confirmation, and the target resource. Minor gaps like behavior when confirm=false or post-deletion effects are not mentioned, but given the annotations and simple schema, it is sufficiently complete for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so both confirm and loadBalancerInstanceNoList are already documented in the schema. The description's mention of 'Set confirm=true to execute' is redundant with the schema's confirmation requirement, adding no new semantic meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action: 'Permanently delete load balancer instances.' This distinguishes it from sibling tools that list, get, or create load balancers. The verb 'delete' combined with the resource makes the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (when permanent deletion of load balancers is needed) and provides a key execution guideline ('Set confirm=true to execute'). However, it does not explicitly mention alternatives or when not to use it, such as using delete_lb_listeners for removing only listeners.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_metrics_group_forceA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds useful context beyond the annotations: it emphasizes irreversibility and the cascade deletion of ALL event rules. It does not contradict the destructiveHint or idempotentHint annotations. It lacks details on permissions or failure modes but is still informative.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with a front-loaded warning symbol, clearly conveying the destructive nature and scope. There is no redundant information or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive delete operation, the description covers the essential behavior: it deletes all associated rules and is irreversible. The schema and annotations fill in parameter details and safety hints. It could be slightly more complete by clarifying when the confirm parameter is required, but that is already captured in the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for both parameters (metricsGroupId and confirm), with 100% coverage. The description itself adds no additional parameter semantics, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action: force delete ALL event rules associated with a metrics group, and notes it is irreversible. This distinguishes it from sibling tools like ncloud_delete_metrics_group (non-force) and ncloud_delete_rule_group_by_id.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is used when you want to delete a metrics group along with all its event rules, but it does not explicitly explain when to choose this over the non-force ncloud_delete_metrics_group or when not to use it. No alternatives are named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_mongodb_usersA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds crucial context that confirm=true is required to execute, preventing accidental deletion. It also explicitly warns 'Destructive'. No contradiction with annotations. It does not elaborate on all consequences (e.g., irreversibility details), but the confirm requirement adds significant transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that front-loads the destructive warning and includes the essential execution condition. No filler or redundant words; every part is actionable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple delete operation, the description is largely adequate: it mentions the destructive nature and confirm requirement. However, it does not describe expected return values or behavior when confirm is false, and lacks any mention of prerequisites (e.g., list users first). With good annotation and schema support, these gaps are minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with descriptions for all parameters including confirm's safety role. The description does not add new meaning beyond the schema—it repeats the confirm requirement. Baseline of 3 is appropriate since the schema already provides adequate parameter clarity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Delete' and the resource 'users from a Cloud DB for MongoDB instance'. It distinguishes from sibling tools like ncloud_add_mongodb_users and ncloud_change_mongodb_users by indicating deletion specifically. The destructive warning and confirm requirement further clarify intent.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by describing the operation, but it does not explicitly state when to use this tool versus alternatives (e.g., 'Use this to remove users, for adding use ncloud_add_mongodb_users'). No exclusions or prerequisites are provided beyond the confirm flag, so guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_monitor_group_forceA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the destructiveHint annotation by explicitly stating 'This is irreversible' and emphasizing 'ALL' event rules, which communicates the full scope of impact. It also adds a warning emoji, reinforcing the destructive nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the destructive warning. It contains no fluff or redundant information, earning its place with each word.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive deletion tool, the description adequately communicates the target (all event rules for a monitor group), the irreversibility, and the force nature. It doesn't explicitly state that the monitor group itself is not deleted, but the phrasing implies that. No output schema exists, so return-value documentation is not required.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the description doesn't need to explain parameter meaning. The description does not add any parameter-level details beyond what the schema provides, which is appropriate given the complete schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: 'Force delete ALL event rules associated with a specific monitoring target group.' It specifies the resource (event rules of a monitoring target group), scope (ALL), and nature (force delete), effectively distinguishing it from other deletion tools like ncloud_delete_monitor_group.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a use case (bulk removal of event rules for a monitoring group) but does not explicitly state when to use this over alternatives or provide any exclusions. No comparison to sibling tools like ncloud_delete_monitor_group or ncloud_remove_resource_from_rules is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_nas_snapshotA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint and idempotentHint. The description adds the confirmation requirement ('Set confirm=true to execute') and the permanence of deletion, which are valuable behavioral details beyond the annotation flags. No contradiction detected.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with a warning emoji, front-loading the destructive nature. Every word is purposeful and there is no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter delete tool with annotations, the description covers the action, permanence, and confirm requirement. It could mention retry safety or error behavior, but given the low complexity and annotation coverage, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers both parameters with full descriptions (100% coverage), so the description adds little beyond reinforcing the confirm parameter's necessity. The schema already states 'Must be true to actually execute the destructive operation'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Permanently delete a NAS volume snapshot', specifying the verb and resource. The 'NAS volume snapshot' qualifier distinguishes it from generic snapshot deletion tools like ncloud_delete_snapshots.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the action 'delete' and the resource name, but there is no explicit when-to-use guidance or comparison with alternatives such as ncloud_restore_nas_volume_with_snapshot or ncloud_change_nas_snapshot_config. The confirm=true instruction is more about parameter usage than tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_nas_volumesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Given annotations already declare destructiveHint=true, the description adds value by stating 'Permanently' and the requirement for a confirmation flag, explaining a behavioral safeguard. It also clarifies the plural nature, but does not discuss return values or side effects beyond deletion, which is acceptable for a destructive operation with annotations covering safety.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise—two short sentences. It front-loads the critical warning with 'Destructive:' and then specifies the action and the confirmation requirement. Every word adds value, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with two parameters and provided annotations, the description conveys the essential information: the action, the target resource, and the confirm guard. Without an output schema, it does not describe return data, but that is not critical for a destructive call. It lacks explicit guidance on prerequisites (e.g., existing volumes) but remains sufficiently complete for an agent to use correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for both parameters (100% coverage). The description repeats the confirm=true requirement, which adds marginal emphasis but no new parameter details. It does not elaborate on the format or structure of nasVolumeInstanceNoList beyond what the schema states, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Permanently delete'), the resource ('NAS volume instances'), and supports plural usage ('one or more'). It distinctly identifies this as a deletion tool for NAS volumes, differentiating it from sibling tools like delete_nas_snapshot or other delete operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description includes an explicit prerequisite ('Set confirm=true to execute') which is useful guidance. However, it does not mention alternatives (e.g., listing volumes first with ncloud_list_nas_volumes) or when not to use this tool, leaving the context partially 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.

• ncloud_delete_network_aclA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it destructive and idempotent. The description adds that deletion is permanent and that confirm=true must be set to execute, which is valuable behavioral context 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence with a clear warning prefix and essential instruction. No verbose filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with two parameters and no output schema, the description covers purpose, destructiveness, and confirmation requirement. It lacks potential caveats (e.g., if the ACL is in use), but that's acceptable given the low complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents both parameters with 100% coverage. The description's mention of confirm=true mirrors the schema and adds no new semantic detail, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'delete' with the resource 'Network ACL' and notes permanence, clearly distinguishing it from sibling tools like ncloud_delete_acg or ncloud_remove_network_acl_* rules.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for deleting a Network ACL but does not provide explicit guidance on when to use it versus alternatives, nor any exclusions. No alternative tools are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_postgresql_databasesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint and idempotentHint, but the description adds critical behavioral context: the operation requires confirm=true to execute, reinforcing the destructive nature. This goes beyond the annotations by explaining the safety mechanism, which is valuable for an agent to avoid accidental data loss.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one short sentence with a clear warning prefix. It front-loads the destructive warning and essential execution requirement, with no redundant words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive operation with no output schema, the description adequately covers key aspects: destructive warning, confirm flag, and scope (databases from an instance). It doesn't explain return values or prerequisites, but those are not critical for a delete operation, and the schema handles parameter documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage of all three parameters (confirm, cloudPostgresqlInstanceNo, cloudPostgresqlDatabaseList) with descriptions. The description only reiterates the confirm=true requirement, which is already in the schema, adding no new semantic detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (delete databases) and the target resource (Cloud DB for PostgreSQL instance), distinguishing it from sibling tools like delete_postgresql_instance or delete_postgresql_users. The verb 'Delete' and resource scope are 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for deleting databases from a PostgreSQL instance but does not explicitly compare with alternatives or state exclusions. The confirm=true instruction provides operational guidance, but the 'when to use vs. alternatives' aspect is only inferred from the name and context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_postgresql_usersA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructiveHint=true, but the description adds a critical behavioral detail: 'Set confirm=true to execute.' This clarifies that the operation is a no-op without confirmation, which is not evident from annotations. It provides a warning and prerequisite for invocation, enhancing transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with a warning prefix and action. Every word earns its place; front-loaded with 'Destructive' and directly actionable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a delete operation with a well-described schema and annotations, the description is adequate. It states the action, resource, and confirmation requirement. It lacks mention of edge cases like idempotency or consequences of deleting nonexistent users, but given the concise nature and schema richness, it's sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all 3 parameters with descriptions (coverage 100%), including the confirm flag's requirement. The description restates the confirm behavior but adds no new parameter-level meaning beyond the schema. It reinforces the confirmation requirement, but that's already documented. Baseline of 3 applies due to high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Delete users from a Cloud DB for PostgreSQL instance' with a specific verb and resource. It distinguishes from sibling delete tools for the same service (e.g., delete_postgresql_databases, delete_postgresql_instance) by specifying 'users'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit when-to-use guidance or alternatives. It only gives the operation and a confirmation requirement. While the tool name and context imply usage, it does not contrast with other delete operations for the same service, so an agent would need to infer context from the name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_server_imagesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, so the warning is redundant but consistent. The description adds the critical gate: the operation will not actually execute unless confirm=true. This is meaningful behavioral context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence: warning icon, action, and confirmation instruction. Every word carries necessary information with no waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only two parameters, no output schema, and annotations covering destructiveness and idempotency, the description is sufficient for basic invocation. It could mention edge cases like partial failures or dependent resources, but for this simple delete operation, the key behavior (confirm gate) is covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both properties (confirm and serverImageInstanceNoList) documented. The description reinforces the confirm=true rule, but adds no semantic detail beyond what the schema already 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Delete one or more server image instances' with a clear verb and resource. It doesn't explicitly differentiate from the sibling tool ncloud_delete_member_server_images, so it misses the sibling-distinguishing level, but the core 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit operational rule: 'Set confirm=true to execute.' It also flags destructive intent. It doesn't mention when-not-to-use or alternatives, but the confirm requirement effectively guides safe invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_target_groupsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description reinforces this with '⚠️ Destructive' and 'Permanently delete,' adding the irreversibility aspect. It also discloses a critical behavioral requirement: the confirm parameter must be true for the operation to execute. This adds meaningful context beyond the annotation, clarifying both the risk and the safeguard.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a clear warning and an explicit conditional for execution. Every word is purposeful, with no filler or repetition. It efficiently conveys the core action, the destructive nature, and the necessary confirmation step.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (two parameters, no output schema) and the existing annotations, the description is largely complete. It covers the essential context: the action (delete), the target resource (target groups), the permanent impact, and the required confirmation. It could optionally mention that multiple target groups can be deleted at once (implied by the plural schema), but this is not a significant gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so both parameters are fully documented. The description adds no new semantics beyond the schema: it only restates the confirm requirement. Since the schema already explains each parameter adequately, the description provides marginal additional value, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Permanently delete target groups.' The verb 'delete' combined with the resource 'target groups' is specific and unambiguous. The name itself also clearly reflects this purpose, and there is no confusion with sibling tools like ncloud_list_target_groups or ncloud_get_target_group_detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by naming the action (delete target groups) and the requirement to set confirm=true for execution. However, it does not explicitly describe when to use this tool versus other related tools, nor does it provide alternative suggestions or exclusions. The guidance is minimal beyond the destructive warning and confirmation prerequisite.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_vpcA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint and idempotentHint. The description adds the confirm=true execution requirement and the permanence of the deletion, which are not present in the annotations, providing useful safety context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, front-loaded with the warning and action. Every word is necessary and there is no wasted content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive delete with full schema coverage and annotations, the description covers the essential behavior. It does not address dependencies (e.g., subnets), but this is not critical for the core operation given the tool's straightforward nature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% parameter descriptions for vpcNo and confirm. The description only repeats the confirm=true requirement already in the schema, adding no new semantic meaning beyond what the schema documents.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Permanently delete a VPC' with a specific verb and resource, distinguishing it from sibling VPC operations like create or get. The warning icon and 'Destructive' label further reinforce the action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied by the delete verb and the confirm parameter instruction, but no explicit when-to-use or alternative comparisons are provided. There are no exclusions or prerequisites mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_disassociate_public_ipA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, so the description's contribution is modest. It adds that the IP is disassociated from its 'currently associated' server, implying it must be attached, but does not disclose further effects such as the IP becoming available or network implications. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, tightly written sentence that conveys the action, target, and context without any redundant words. Front-loaded and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, the description plus schema provide sufficient context. It could mention that the public IP itself is not deleted, but the simple nature and annotations make the current level adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage for the single parameter, and the description does not add additional meaning beyond the parameter's own description. Baseline of 3 is appropriate since the schema carries the semantic weight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Disassociate') and resource ('public IP from its currently associated server instance'), clearly distinguishing it from sibling tools like associate, create, and delete. It is concise and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates the action's context (disassociating a public IP from its server), which is enough to infer when to use it. However, it does not explicitly name alternatives or specify when not to use it, so it falls short of full explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_dns_apply_domainA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide idempotentHint=true and destructiveHint=false, covering safety and destructive behavior. The description adds the key behavioral context that this is a 'publish' action that makes pending changes live, which is valuable beyond the annotations. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of ten words, front-loaded with the verb and resource. It contains zero redundant information and is highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter, no output schema, and clear annotations, the description is sufficiently complete. It explains the core operation (applying/publishing changes) while relying on schema and annotations for parameter and safety details. A minor gap is not defining 'pending changes', but sibling tools make this inferable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with the parameter 'domainId' described as 'Domain ID to apply'. The description does not add any extra meaning to the parameter, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Apply') and clearly identifies the resource ('pending changes to a Global DNS domain') with a clarifying parenthetical ('publish DNS records'). It distinguishes this tool from sibling DNS operations like list, create, delete, and rollback, which focus on different actions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'apply pending changes' implies this tool is used after making DNS record edits, but it does not explicitly state when to use it or mention alternatives. It lacks clear context such as 'use after create/update/delete records' or exclusions, leaving usage guidance mostly implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_dns_list_lb_recordsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint=true annotation already discloses the safe read-only nature, lowering the bar. The description adds only minimal context ('available', 'Global DNS integration') and does not disclose additional behavioral details such as result format, ordering, or any potential limitations. It does not contradict the annotation, but contributes little beyond it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action ('List') and the object ('Load Balancer records'). Every word is purposeful, and the qualifier 'for Global DNS integration' adds critical context without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity (no parameters, no output schema) and the read-only annotation, the description is nearly complete. It tells the agent what the tool does and when it applies. However, since there is no output schema, it would be slightly better if it described the return shape, but this is not critical for a simple list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has no parameters, and the schema is empty with 100% coverage. Per the rubric, a zero-parameter tool gets a baseline of 4. The description does not need to explain parameter semantics since there are none.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the verb (List) and resource (Load Balancer records) with a specific scope (for Global DNS integration). It distinguishes this tool from nearby siblings like ncloud_dns_list_records by specifying 'Load Balancer records' rather than general DNS records.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when needing Load Balancer records for Global DNS integration) but provides no explicit guidance on when not to use it or which alternative tools to consider. It does not reference any sibling tools or exclude scenarios, leaving usage context 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.

• ncloud_drm_disable_siteA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, covering safety and repeatability. The description adds a workflow constraint (before policy modification) but does not elaborate on other behavioral aspects like what happens to the site while disabled or whether prerequisites (e.g., site exists) are required. This adds some context but not rich detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short, purposeful sentences. The first sentence states the core action, and the second adds essential usage context. There is zero redundant or filler content, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter, state-change tool with no output schema and strong annotations, the description adequately covers the purpose and timing. It could mention what a successful response looks like or error conditions, but given the low complexity and existing annotations, the description is sufficiently complete for an agent to use effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already has 100% coverage with 'Site ID to disable.' The description does not add additional meaning beyond the schema—it only restates the resource type. With high schema coverage, baseline 3 is appropriate, and no extra parameter guidance is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Disable (deactivate) a DRM site.' This is a specific verb+resource combination that distinguishes it from sibling tools like enable, create, update, get, and list. The parenthetical 'deactivate' reinforces the meaning.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The second sentence provides explicit usage context: 'Disable a site before modifying its active policy.' This tells the agent when to use this tool relative to a workflow. It does not explicitly list alternatives or when-not-to-use, but the context is clear enough for a simple disable operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_drm_get_policyA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint: true already signals a safe read operation, lowering the bar for additional disclosure. The description adds 'detailed configuration' but does not elaborate on return format, fields included, or error behavior. With annotations covering the safety profile, this is adequate but not enriched.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clearly worded sentence that is front-loaded with the verb and resource. There is no wasted wording or redundant information; every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read tool with a readOnly annotation, the description is largely complete. It lacks an output schema, so it does not enumerate the fields returned in the 'detailed configuration', but this is a minor gap given the standard 'get detail' pattern. The source of the policyId in the schema helps the agent invoke it correctly, so overall it is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has full 100% coverage for the single parameter policyId, and the schema description adds important context: 'DRM policy ID (from ncloud_drm_list_policies)'. This tells the agent where to obtain the ID, which goes beyond the bare type and name. The description does not need to compensate further because the schema is self-sufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get detailed configuration of a specific DRM policy' uses a specific verb ('Get') and clearly identifies the resource ('detailed configuration of a specific DRM policy'). This distinguishes it from sibling tools like ncloud_drm_list_policies, which lists policies, and ncloud_drm_update_policy/delete_policy, which modify them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving details of a single policy but does not explicitly state when to use it versus alternatives. The parameter description hints that the policy ID comes from ncloud_drm_list_policies, which suggests a workflow, but no when-not or alternative guidance is provided. This is an implied usage, not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_export_mssql_logA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already signals that the operation is safe from a mutation perspective. The description adds that it exports to Object Storage, which implies a copy operation, but does not disclose potential side effects like storage costs, overwrite behavior, or whether it is synchronous/asynchronous. With annotations covering the safety profile, this level of added context is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two sentences. The first sentence states the purpose and destination, the second provides a cross-reference to the prerequisite listing tool. Every word earns its place, with no fluff or repetition of schema information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, but it is a focused export operation with well-documented parameters and a clear prerequisite reference. The description covers the main action and directs the user to obtain the required log file list. It does not describe the return format or how to monitor progress, but given the simplicity and strong schema coverage, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and all parameters have clear descriptions such as 'Object Storage bucket name to export to' and 'Full object name of the log file to export.' The description does not add extra meaning beyond the schema, but since the schema is comprehensive, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Export Cloud DB for MSSQL server logs to Object Storage.' The verb 'export' plus the resource 'Cloud DB for MSSQL server logs' and destination 'Object Storage' make the purpose unmistakable. It also distinguishes from sibling tools like export backups by specifying 'logs' and references the related list tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage context by stating 'Use ncloud_list_mssql_log_files to get available log files.' This tells the agent a key prerequisite and guides it toward the correct companion tool. However, it does not explicitly mention alternatives (e.g., export backups for backups) or provide exclusions, so it stops short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_functions_list_actionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds that it returns all actions and clarifies the packageName special value, which is useful context. But it doesn't disclose any further behavioral traits like sorting or pagination; consistent with the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence that is direct and front-loaded; zero wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with complete schema coverage and readOnly annotation, the description is sufficient. It covers the only non-obvious detail (unpackaged actions via '-') and the purpose. Minor gap: no information about the returned action list structure, but that is likely unnecessary for a list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%; both parameters have descriptions and defaults defined in the schema. The description largely duplicates the packageName parameter's schema description ('use '-' for unpackaged actions'), adding no new semantic information beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('actions') with a clear scope ('in a package'), and the parenthetical distinguishes unpackaged actions. It clearly differentiates from sibling tools like ncloud_functions_list_packages, which lists packages.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the appropriate use case: listing actions within a specific package, with a convention for unpackaged actions. However, it does not explicitly name alternatives or state when not to use it, though the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_bucket_locationA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint: true, so the agent knows this is a safe read. The description adds no additional behavioral context beyond clarifying the term 'location constraint'. It does not disclose edge cases or permission requirements, but with annotations covering the safety profile, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that conveys the essential purpose with no redundant words. It is front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, read-only, no output schema), the description is complete enough. It clearly indicates the return concept (the region) and does not require additional detail. However, a brief note on return format could have made it a 5, but it is not necessary.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the bucketName parameter already has a clear description. The tool description adds the parenthetical 'location constraint' but does not provide additional syntax or formatting details beyond what the schema already conveys, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource: 'region (location constraint) of an Object Storage bucket'. It is specific and distinct from sibling tools like get_bucket_acl or get_bucket_versioning, making the tool's purpose immediately clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is straightforward: this tool is for retrieving a bucket's region. No exclusions or alternatives are mentioned, but for a simple getter, the intended use is unambiguous and does not require contrast with siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_bucket_versioningA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation. The description adds the resource type and the specific state being retrieved, but does not disclose any additional behavioral details such as permissions, return format, or error conditions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant information. It efficiently conveys the operation without wasting words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read tool, the description is largely complete. The only gap is that it does not specify the possible return values (e.g., enabled/suspended), but with no output schema and low complexity, this is a minor omission.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides a full description for the only parameter (bucketName), covering 100% of the schema. The description repeats the parameter's purpose without adding extra syntax or format details, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' and identifies the exact resource ('versioning state of an Object Storage bucket'). This clearly differentiates from siblings like ncloud_put_bucket_versioning, which modifies the same state.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies a read-only query for checking versioning configuration, with no exclusions or prerequisites. It does not explicitly name alternatives, but the sibling 'ncloud_put_bucket_versioning' makes the contrasting use case obvious from the name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_contract_summary_listA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description aligns by indicating a read operation (get/returns). It adds useful context about grouping and month aggregation, but doesn't disclose other behaviors like pagination defaults or filtering constraints beyond what the schema offers. With annotations covering the core safety profile, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the primary action and outcome. Every sentence earns its place, with no fluff or repetition of schema content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with good annotations and full schema coverage, the description sufficiently covers the core functionality and return shape (grouped counts). It doesn't detail response structure, but no output schema exists and the operation is straightforward. Slight gap in not mentioning pagination or optional filters, but those are in the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the description need not repeat parameter meanings. It implies that contractMonth drives the 'specified month' and that region/contractType may influence grouping, but it doesn't add explicit detail beyond schema descriptions. Baseline 3 is appropriate when the schema handles parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves a contract summary list, with specific detail on grouping by region and contract type with counts for a specified month. This pairs a specific verb (get/returns) with a clear resource and scope, distinguishing it from related contract tools like usage or demand cost lists.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when a summary of contracts is needed for a month, providing clear context. However, it does not explicitly state when to use this instead of sibling tools like get_contract_usage_list, nor does it mention exclusions or alternatives, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_custom_resourceA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation, and the description does not contradict this. Yet it adds no additional behavioral context (e.g., error behavior, return format, permission requirements) beyond what the annotation and name already imply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, direct sentence with no filler. The purpose is front-loaded ('Get detailed information') and the resource and scope are immediately clear. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter getter with a read-only annotation, the description is adequate. It indicates the action, the resource type, and the scope. It does not specify return fields or error cases, but the lack of an output schema makes that less critical. Still, it could be slightly more descriptive about what 'detailed information' entails.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the only parameter (resourceId) with a clear description ('Custom resource ID'), and schema coverage is 100%. The description adds no new parameter details, so it meets the baseline without further contribution.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('detailed information about a specific custom resource in Cloud Insight'), clearly distinguishing it from list, create, update, and delete operations. The scope ('in Cloud Insight') adds context that separates it from other resource types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies the tool is for fetching a single resource when you have a specific resource ID, as opposed to listing resources. However, it does not explicitly state when not to use it or mention alternatives like list_custom_resources, so it lacks explicit exclusions but provides clear context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_ddos_event_detailA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the operation is read-only. The description adds the subscription eligibility requirement, which is useful, but does not disclose error behavior, required permissions beyond subscription, or return format. With annotation covering the safety profile, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the main action, and contains no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only detail tool, the description covers purpose and eligibility. No output schema exists, but the tool's return is implied as event details; still, it could mention response structure or error conditions. Given the low complexity, this is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter ticketId, so the schema fully documents its meaning. The description does not add any new parameter semantics beyond what the schema already provides, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('Get detailed information') and resource ('specific Anti-DDoS security event'). It distinguishes from sibling list_ddos_events by focusing on a single event detail rather than a list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it retrieves details for a specific event and notes the Security Monitoring subscription requirement. However, it does not explicitly name alternatives like list_ddos_events or state when-not-to-use, but the context is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_flow_log_configA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this is a safe read operation. The description adds the behavioral nuance that it returns all configurations by default and filters when a network interface number is provided. This is helpful but minimal; no additional context about response format, pagination, or permissions is given. The description is consistent with the annotation, so no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description consists of two crisp sentences with no filler. It leads with the action ('Get'), specifies the resource ('FlowLog configuration list'), and immediately explains the optional behavior. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with one optional parameter and no output schema, the description is complete enough. It covers the two possible behaviors (all vs. filtered) and implies the return type is a list. It does not enumerate fields of a FlowLog configuration, but for this straightforward operation that is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes the single parameter (networkInterfaceNo) with 100% coverage. The description reiterates the filtering functionality but adds no new semantic detail beyond what the schema provides. Baseline 3 is appropriate since the schema handles the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb+resource: 'Get FlowLog configuration list.' It further explains the exact behavior: returns all configurations or filters by network interface number. This unambiguously distinguishes it from the sibling enable/disable flow log tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description communicates when to use the tool: to retrieve flow log configurations, either in full or filtered. It does not explicitly mention alternatives or exclusions, but the read intent is clear from the context and the readOnlyHint annotation. There are no close sibling tools that do the same thing, so this is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_monitor_groupA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description aligns with the readOnlyHint annotation, so no contradiction. However, it adds little beyond the annotation: it only clarifies the resource type. It doesn't describe what 'detailed information' includes, authentication needs, or any limitations, but the annotation covers the safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single clear sentence conveys the essential purpose without any filler or redundancy. It is front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-ID tool with one parameter, readOnlyHint annotation, and no output schema, the description adequately conveys the core action. It lacks specifics about the return content but the tool is low-complexity, so the description is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single required parameter monitorGroupId. The description does not add additional meaning about the parameter format, source, or constraints. Baseline 3 is appropriate since the schema fully documents the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb (Get), resource (specific Cloud Insight monitoring target group), and scope (detailed information). It distinguishes from sibling tools like ncloud_list_monitor_groups (which lists groups) and ncloud_get_rules_by_monitor_group (which retrieves rules).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it: to fetch details of a single monitor group by ID. It does not explicitly name alternatives, but the word 'specific' indicates a contrast with listing tools. No exclusions or when-not-to-use guidance is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_network_acl_rulesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint: true annotation already covers safety. The description adds that it lists both inbound and outbound rules and requires a specific ACL. It does not disclose behavior like pagination, response format, or defaults, but the annotation lowers the burden. No contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence that is front-loaded with the action and resource. It wastes no words and is easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with low parameter complexity and full schema coverage, the description is sufficient. It doesn't mention pagination or return format, but these are expected for a list tool. Overall, it gives enough context for correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both networkAclNo and networkAclRuleTypeCode described. The description adds no extra parameter meaning beyond the schema, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists all inbound and outbound rules for a specific Network ACL. This uses a specific verb ('List') and resource ('Network ACL rules'), and distinguishes it from sibling tools like add/remove rule tools and get_network_acl_detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: call this when you need the rules for a specific Network ACL, identified by networkAclNo. It does not explicitly mention alternatives or exclusions (e.g., use ncloud_get_network_acl_detail for ACL properties), but the context is clear enough for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_object_aclA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the safe read-only nature, and the description does not contradict it. The description adds only the resource scope ('object in Object Storage') but no extra behavioral details like response format, required permissions, or side effects. This meets the baseline for annotation-backed tools.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no redundancy. It efficiently communicates the purpose without wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read-only operation with full schema coverage, the description is largely sufficient. It identifies the resource and the action, and the annotation covers safety. The lack of an output schema is partially mitigated by the clear 'Get ACL' phrasing, though a note about the return format would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters (bucketName and objectName) well described in the input schema. The description adds no additional parameter 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: 'Get the access control list (ACL) of an object in Object Storage.' It uses a specific verb ('Get') and identifies the exact resource (object ACL), distinguishing it from sibling tools like ncloud_put_object_acl and ncloud_get_bucket_acl.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by specifying 'of an object' and 'Object Storage', implying this is for object-level ACL retrieval rather than bucket-level. However, it does not explicitly name alternatives or state when-not-to-use, so it stops short of a perfect score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_pipeline_timezonesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes the safe, read-only nature, and the 'Get' verb is consistent with it. The description adds only the value domain (timezones for schedule triggers) but does not disclose return format, whether the list is exhaustive, or any ordering/caching behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence beginning with the verb 'Get', containing no filler or redundancy. Every word contributes meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only lookup with no output schema, the description adequately conveys the return value's purpose and scope. It is sufficiently complete for the tool's simplicity, though it could optionally mention the timezone value format.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so the rubric establishes a baseline of 4. There are no parameter semantics to clarify, and the description correctly makes no parameter claims.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 well-scoped resource ('available timezones for SourcePipeline schedule triggers'), making the tool's function immediately clear. It also distinguishes itself from the many pipeline sibling tools (list/get pipelines, history, etc.) by identifying a distinct metadata domain.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for SourcePipeline schedule triggers' implies the usage context — the tool is relevant when configuring pipeline schedules. However, it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_product_category_listA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation, so the description is not required to restate that. The description adds value by indicating the return content (available service categories with examples), but it does not disclose other behaviors like pagination, unfiltered results, or response structure. This is acceptable given the annotation, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that immediately states the operation and resource. It includes useful examples in a compact way without any filler or repetition of the tool name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with one optional parameter and no output schema, the description provides sufficient context about the resource and expected return categories. It could mention behavior when no filter is provided, but that is reasonably inferred from the schema and the tool's listing nature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes the optional productCategoryCode parameter with an example. The description adds examples of category values in the narrative, but these are also present in the schema's parameter description. With 100% schema coverage, the description neither compensates for missing schema info nor adds new parameter-level meaning beyond the schema baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving product category lists for Ncloud billing, with specific examples (COMPUTE, DATABASE, NETWORKING). This distinguishes it from sibling tools like ncloud_get_product_list or ncloud_get_product_price_list by focusing specifically on category data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by specifying this is for Ncloud billing and that it returns service categories. It does not explicitly discuss alternatives or exclusion criteria, but the domain context is unmistakable for an agent deciding to fetch category data.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_product_demand_cost_by_discount_listA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint=true annotation already declares the read-only nature, which the description confirms with 'Get'. The description adds the 6-month period limit and the per-service output structure. However, it does not disclose pagination behavior, access-mode nuances (e.g., isPartner/isOrganization), or any other operational quirks, which would be valuable for an 8-parameter billing query tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, containing only two sentences. It front-loads the verb and resource, immediately explains the output, and includes the critical period constraint. There is no redundant or extraneous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description does a good job explaining the return value ('per-service billing amounts showing how each discount was applied'). However, it omits discussion of pagination parameters, access modes (isPartner, isOrganization), or filter options (memberNoList, productDemandTypeCodeList), leaving some contextual gaps for a tool with 8 parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%; every parameter (startMonth, endMonth, pageNo, pageSize, etc.) has an individual description in the schema. The tool description only reinforces the period constraint ('max 6 months') without adding additional parameter semantics, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get billing history with discount details applied.' It specifies the resource (billing history), the output (per-service billing amounts), and the distinguishing feature (showing how each discount such as product discount and credit was applied). This effectively differentiates it from sibling tools like ncloud_get_product_demand_cost_list and ncloud_get_discount_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 the tool: when billing history with discount breakdowns is needed. The mention of 'per-service billing amounts showing how each discount was applied' implies the specific use case, though it does not explicitly name alternatives or exclude other scenarios. The clarity of the purpose is sufficient for basic guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_public_ip_target_serversA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description is consistent (a read-only list). It adds the filtering criterion (servers that 'can be assigned a public IP'), which is useful, but it does not disclose additional behavioral details such as return format, pagination, or prerequisites. The description adds some context beyond annotations but is 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no fluff. It immediately states the action and the resource, making it highly efficient and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, parameterless, read-only tool with no output schema, the description is largely sufficient. It specifies what is returned (eligible server instances). It could add a hint about its role as a prerequisite before associating a public IP, but overall it covers the essential context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema coverage is trivially 100%. With no parameters to document, the description does not need to add parameter-level semantics. The baseline for 0 parameters is 4, and the description is clear enough.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('server instances that can be assigned a public IP'), clearly distinguishing it from sibling tools like list_public_ips (which lists IPs) and list_servers (which lists all servers). It precisely captures the tool's focused scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  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 you need to find servers eligible for public IP assignment, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusions. Sibling tool names provide context, but the description itself offers no direct comparison.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_regionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint: true annotation already establishes this is a safe read operation, and the description 'List all available Ncloud regions' is consistent with that. However, the description adds no extra behavioral context beyond the annotation, such as return format, ordering, or any potential limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no filler. It is front-loaded and captures the essential purpose in just five words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list operation, the description covers the essential purpose. However, given the presence of related tools like ncloud_get_zones and ncloud_get_current_region, a brief note on what the output includes (e.g., region codes or names) would enhance completeness, though it is not strictly necessary.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the input schema is trivially complete. The description does not need to explain parameter semantics, and no additional detail would add value for a parameter-less call.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('List') and resource ('all available Ncloud regions'). It is unambiguous and easily distinguishable from sibling tools like ncloud_get_zones or ncloud_get_current_region, which operate on different resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  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 an agent needs to retrieve all available Ncloud regions, but it provides no explicit guidance on when not to use it or mentions alternative tools such as ncloud_get_zones or ncloud_get_current_region. This is a minor gap for a simple discovery function.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_routesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint: true, and the description's 'List' verb is consistent with that. The description adds the scope 'all routes', but doesn't disclose pagination, response format, or other behavioral details. With the read-only annotation present, the description adds some value but not rich context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is concise and front-loaded with the action and resource. Every word is necessary, and there is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with two well-documented parameters and a read-only annotation, the description and schema cover the essential context. It doesn't describe return values, but since there's no output schema and the tool's purpose is straightforward, this is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both vpcNo and routeTableNo have clear descriptions in the schema. The tool description doesn't add additional meaning beyond what the schema already provides for these parameters, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses specific verb 'List' and resource 'routes', and scopes it to 'a specific route table'. This clearly distinguishes it from sibling tools like ncloud_add_route, ncloud_remove_route, and ncloud_list_route_tables, which either mutate routes or list different entities.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies usage when you need all routes in a particular route table. It doesn't explicitly name alternatives or exclusions, but the resource type ('routes' vs 'route tables' or 'subnets') makes the intended use evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_rules_by_monitor_groupA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description's 'Get' matches that safe read behavior. The description adds no further behavioral context beyond the read-only hint, such as pagination or response format, but with annotations present this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the action and resource. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool (one parameter, read-only, no output schema), the description sufficiently conveys purpose and scope. It does not mention return format, but the operation is straightforward and the name further clarifies intent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with a clear description of 'monitorGroupIds'. The tool description's phrasing 'monitoring target group IDs' is essentially synonymous and does not add meaningful new meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('Cloud Insight event rules'), and clarifies association with 'specific monitoring target group IDs'. This clearly distinguishes it from sibling tools like ncloud_get_rules_by_metrics_group and ncloud_remove_resource_from_rules.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 this tool: when you need event rules for specific monitoring target group IDs. However, it does not explicitly mention alternatives or when-not-to-use conditions, which would merit a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_servers_topA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already indicates this is a safe read operation. The description adds the 'top 5' limit and the monitoring source, but does not disclose return format, ordering behavior, or any potential limitations. This goes slightly beyond annotations but remains minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that conveys the action, resource, metric types, and source without unnecessary words. It is well-structured and immediately understandable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, no output schema), the description provides enough context for an agent to invoke it correctly: it specifies the metric types and the top-5 nature. It could mention return format or sorting order, but these are not critical for such a straightforward read operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameter semantics with an enum and description. The description essentially rephrases the metricType values (CPU, memory, filesystem) but does not add significant new meaning beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Get the top 5 servers') with a defined resource type (servers) and scope (CPU, memory, or filesystem usage from Cloud Insight monitoring). It is easily distinguished from sibling tools like ncloud_list_servers which lists all servers, while this focuses on top-ranked ones.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies clear usage context: it is for ranking servers by a given metric to get the top 5. However, it does not explicitly mention alternatives or exclusions, such as when to use ncloud_list_servers or monitoring query tools instead.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_globalcdn_get_monitoringA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, so safety is known. Description adds that it retrieves traffic and requests for instances over a time range, but does not disclose return format, pagination, or any limitations. Similar to the get_calls example, it adds modest context but not rich behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single, front-loaded sentence with no filler: 'Get Global CDN monitoring data (traffic, requests) for one or more instances over a time range'. Every word is informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only query with fully documented parameters and readOnlyHint annotation, the description covers purpose and data type. It could mention response format or granularity, but it's adequate for correct invocation. Does not require explaining return values since no output schema exists.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 100% coverage with clear descriptions for startDate, endDate, and cdnInstanceNoList. Description merely restates these concepts (one or more instances, time range) without adding format or additional meaning, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states specific verb 'Get', resource 'Global CDN monitoring data', and scope (traffic, requests, one or more instances, time range), clearly distinguishing from sibling tools like get_usage or purge.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Clearly defines the operation context (fetching monitoring data for Global CDN instances over a time range) but does not explicitly mention alternatives or exclusions. It's clear enough for the agent to select when monitoring data is needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_globalcdn_list_instancesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description aligns with a read-only listing operation. The description adds the optional filtering and pagination behavior, but does not disclose additional details like return format or default pagination size. Given annotations cover safety, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word contributes meaning, efficiently conveying the action, resource, and optional parameters.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with optional filters and read-only annotations, the description is sufficiently complete. It does not specify return format, but the tool name and schema provide adequate context for an agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for all three parameters. The description paraphrases them as 'filtering by instance number and pagination', which adds a high-level grouping but no new syntax or constraints beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('Global CDN instances'), clearly distinguishing it from sibling tools like ncloud_cdnplus_list_instances. It also mentions the optional filtering capability, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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: listing Global CDN instances, with optional filtering and pagination. It does not explicitly exclude alternatives, but the resource scope ('Global CDN') inherently differentiates it from other list tools in the sibling set.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_gtm_delete_geo_cidr_mapA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint=true, so the description adds value by stating the destruction is permanent and by explicitly disclosing the confirm=true requirement. It does not explain idempotency behavior or consequences on related resources, but the added context is meaningful beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one tightly packed sentence: a warning emoji, a clear destructive statement, and a key operational directive. No redundant phrases or filler; every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple nature of the delete operation, the schema covers all parameters, annotations cover destructive/idempotent hints, and no output schema exists. The description effectively conveys the essential context: permanence and confirmation. It lacks details on edge cases like non-existent maps, but these are not critical for a one-off delete tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters (mapId and confirm) are fully documented at the schema level. The description's mention of 'Set confirm=true' simply restates the schema's parameter description and does not add new semantic meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Permanently delete') and the resource ('Geo or CIDR map'), using a specific verb. It is directly distinguishable from sibling tools like create, update, get, and list by the explicit delete operation embedded in the name and description.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides context for when to use the tool (when you intend to delete a Geo/CIDR map) and includes a critical usage instruction ('Set confirm=true to execute'). However, it does not mention alternatives or exclusion criteria, such as 'use update to modify instead of delete' or any prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_gtm_delete_policy_health_checkA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint and idempotentHint, and the description supplements this with a ⚠️ Destructive warning and the explicit requirement to set confirm=true before execution. It adds operational context beyond the annotations, though it doesn't elaborate on irreversibility or side effects beyond the deletion itself.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single front-loaded sentence with a warning emoji, the action, the target, and the key safety condition. No filler or repetition; the description is minimal but complete.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive operation, the description covers the action, target, and confirmation requirement, and annotations supply safety/idempotency context. It doesn't describe the return value, but no output schema exists and delete operations often require no return detail; still, it could mention whether the operation is reversible or what happens to the policy afterward.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: policyId is described as 'Policy ID' and confirm as 'Must be true to execute.' The description reiterates the confirm requirement but adds no new semantic detail beyond the schema, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Delete health check configuration for a GTM policy.' It names a specific verb and resource, distinguishing it from sibling tools like ncloud_gtm_delete_policy and ncloud_gtm_update_policy_health_check.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when deleting a policy's health check configuration and provides the required confirm flag, but it does not explicitly contrast with alternatives or state prerequisites. The 'Set confirm=true to execute' is operational guidance rather than decision guidance for choosing this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_gtm_get_geolocation_infoA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description's 'Get' aligns with that. The parenthetical 'country/continent mappings' adds a small behavioral detail beyond annotations but does not disclose return format or any other operational nuances. The low bar is met without rich detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that is front-loaded with the verb and resource, with no redundant or extraneous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only getter with no output schema, the description sufficiently conveys the core purpose and result type ('country/continent mappings'). It does not detail the exact return structure, but the simplicity and annotations make this adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so per rubric the baseline is 4. Schema coverage is trivially 100%, and the description adds no parameter-specific detail because none are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Get') and resource ('geolocation information') for Global Traffic Manager, and clarifies it covers country/continent mappings. This distinguishes it from sibling GTM tools like health check regions or geo CIDR maps.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by indicating it returns geolocation data for GTM, but it does not explicitly state when to choose this over related sibling tools such as ncloud_gtm_get_geo_cidr_map_detail or ncloud_gtm_get_map_types. No exclusions are given, but the context is sufficient for a simple getter.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_gtm_get_resource_typesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation, and the description correctly reflects a 'Get' operation. The description doesn't add any behavioral details beyond the annotation (e.g., response format, pagination, or region dependence), but for a zero-parameter read-only tool, the behavior is straightforward and adequately disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence of 10 words with no filler or redundant information. Every word contributes to the meaning, stating exactly what resource is being retrieved and for what purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, read-only, no output schema), the description is reasonably complete. It identifies the subject (resource types) and domain (GTM policies), and the readOnlyHint annotation covers safety. It could arguably mention what the returned resource types look like, but that level of detail is not essential for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description need not explain any parameter semantics. The input schema confirms there are no parameters, and the description's phrase 'available resource types' sufficiently conveys what the tool returns. The baseline of 4 for zero parameters applies here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and noun ('resource types') scoped to 'Global Traffic Manager policies'. This distinguishes it from sibling tools like ncloud_gtm_get_policy_resources or ncloud_gtm_get_lb_types by focusing on the set of available resource types rather than a specific policy's resources or load balancer types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied by the name and description: an agent would call this to list resource types before creating or updating a GTM policy. However, there is no explicit statement of when to use it versus alternatives like ncloud_gtm_get_lb_types or ncloud_gtm_get_map_types, and no exclusions or prerequisites are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_hadoop_delete_clusterA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation destructiveHint is reinforced by the description's explicit 'All data will be lost' warning, which explains the consequence. The confirm=true requirement adds safety context that annotations do not provide, giving the agent a clear understanding of the operation's irreversibility and the required gate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence plus a short imperative, front-loading the destructive warning and stating the action, consequence, and required confirmation in about 20 words. Every phrase earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive delete tool with three parameters and no output schema, the description covers the essential purpose, consequence, and activation prerequisite. It omits details about return values or behavior for nonexistent clusters, but these are not critical given the schema covers parameters and annotations cover idempotency.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with descriptions for cloudHadoopInstanceNo, confirm, and regionCode. The description only reiterates the confirm parameter's role ('Set confirm=true to execute'), adding no additional meaning for the other parameters. Thus the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'Permanently delete a Cloud Hadoop cluster,' identifying the exact action (delete) and resource (Cloud Hadoop cluster). This distinguishes it from sibling tools that delete notebooks or other cluster types, such as ncloud_ses_delete_cluster or ncloud_nks_delete_cluster.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not mention alternatives or when to avoid using this tool. However, it clearly implies use only when deleting a Cloud Hadoop cluster is intended and establishes a necessary precondition: 'Set confirm=true to execute.' This provides basic usage guidance but lacks explicit comparison to alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_hadoop_delete_notebookA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint and idempotentHint. The description adds 'permanently' and the confirm gate, which are useful behavioral details. However, it does not disclose potential side effects, permission requirements, or recovery options, so it provides only modest added value 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that immediately warns of destructiveness, states the action and resource, and specifies the confirmation requirement. No unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation, the description paired with annotations and schema is largely complete. It conveys the permanent nature, the mandatory confirm flag, and the target instance number is in the schema. It could mention irreversibility or post-deletion effects more explicitly, but 'permanently' covers the core concern.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already fully documents all three parameters. The description reinforces the confirm parameter's role as a required safety switch, but adds no new semantic information about regionCode or cloudHadoopNotebookInstanceNo beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Permanently delete') and the resource ('Cloud Hadoop notebook'), distinguishing it from sibling tools like ncloud_hadoop_delete_cluster. The warning prefix and confirm requirement add specificity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly conveys when to use this tool (to delete a specific notebook) and explicitly requires confirm=true to proceed. It does not explicitly name alternatives for other operations, but the delete intent is unmistakable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_hadoop_list_login_keysA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, which the description aligns with via 'List'. The description adds the Hadoop SSH access scope but does not disclose further behavioral traits such as pagination, filtering behavior, or response format. Given the annotations cover the safety profile, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence of 10 words, front-loaded with the action verb 'List' followed by the specific resource and scope. There is zero wasted text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one optional parameter, the description covers the essential purpose and scope, making it sufficient for tool selection and invocation. It could be slightly richer with explicit alternative guidance, but the current level of detail is adequate given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema coverage is 100%, with regionCode described as 'Region code' in the schema. The description does not mention parameters, but since the schema fully documents the only parameter, the baseline of 3 applies. No additional parameter semantics are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'List' with resource 'login keys' scoped to 'Cloud Hadoop SSH access', clearly identifying its function. It distinguishes itself from the general ncloud_list_login_keys and the SES-specific ncloud_ses_get_login_keys siblings by the Hadoop context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context about when to use this tool (for Cloud Hadoop SSH login keys), which effectively guides selection among siblings that operate on different resource types. It does not explicitly name alternatives or exclusions, but the Hadoop scope makes the intended use unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_hadoop_list_target_vpcsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a safe read operation. The description adds that the result is filtered to VPCs available for Hadoop deployment, which is useful behavioral context. However, it does not clarify what 'available' means (e.g., region eligibility, zone support) or describe return format/pagination, so the bar is only partially met.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single seven-word sentence, front-loaded with the verb 'List,' and contains zero redundant information. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter, read-only list tool, the description adequately conveys purpose and scope. It lacks an explicit note that regionCode is optional or details on what makes a VPC 'available,' but the low complexity and readOnlyHint annotation make the description sufficient for selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The sole parameter regionCode is fully described in the input schema as 'Region code' (100% coverage). The description adds no parameter-specific detail beyond the schema, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('VPCs'), and clearly scopes it to 'available for Cloud Hadoop deployment.' This distinguishes it from the general ncloud_list_vpcs and related Hadoop target-list tools (e.g., ncloud_hadoop_list_target_subnets).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'available for Cloud Hadoop deployment' clearly implies this tool is for selecting VPCs when provisioning Hadoop clusters, providing clear context. It does not explicitly name alternatives or exclusions, but the Hadoop-specific scoping makes the intended usage evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_head_objectA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this is safe, and the description adds the key behavioral detail of returning metadata without the object body. However, it does not disclose other relevant behaviors such as potential 404 responses or required permissions. The added context is modest.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The entire description is a single, focused sentence that immediately conveys the tool's purpose and key distinction. There is no redundancy or extraneous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only retrieval tool with two well-documented parameters and a readOnlyHint annotation, the description provides sufficient context for correct invocation. It could mention return header details, but this is not critical given the standard HTTP semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% parameter coverage with descriptions for both bucketName and objectName. The tool description adds no additional parameter semantics, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Retrieve') and clearly identifies the resource ('metadata of an object') while distinguishing this from body-returning operations via 'without returning the object body (HEAD request)'. This differentiates it from sibling tools like ncloud_get_object and ncloud_list_objects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly conveys the appropriate use case: when only metadata is needed and the body is not required. It does not explicitly name alternatives or exclusions, but the HEAD request semantics provide clear context for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_add_acl_ruleA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=false, and the description adds the key effect of allowing token requests from the specified IP. It does not disclose side effects like duplication handling or prerequisites such as IP ACL being enabled, but given the non-destructive annotation, the description adds some useful context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 14 words, with the verb and resource front-loaded. It is concise, clear, and contains no unnecessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 no output schema, the description covers the operation's purpose sufficiently. It could mention that the IP ACL must be enabled for the rule to take effect, but given the simplicity and non-destructive nature, it is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides complete descriptions for all three parameters (100% coverage), including examples for 'ip' and the meaning of 'keyTag'. The description adds minimal additional parameter meaning 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action 'Add', the resource 'ACL rules for a KMS key', and the purpose 'to allow token requests from that IP'. It distinguishes from sibling KMS ACL tools like delete/get by using the specific verb 'add' and specifying the target.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a clear usage context: adding an IP to allow token requests for a KMS key. It does not explicitly mention alternatives like ncloud_kms_enable_ip_acl or ncloud_kms_delete_acl_rule, but the purpose is clear enough for an agent to understand when to invoke this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_create_token_generatorA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=false, and the description adds the 'activate' aspect and the resulting capability. However, it does not disclose full behavioral traits like idempotency, prerequisites (e.g., key must exist), or what happens if a token generator already exists. With annotations covering the destructive profile, this is baseline adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the verb, and no fluff. Every word contributes to explaining the tool's purpose and effect.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, the description is largely sufficient. It explains what it does and why. It could be slightly more complete by explicitly stating prerequisites (e.g., the key must already exist) but these are reasonably implied by the reference to a KMS key.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage for the only parameter (keyTag) with a clear description. The tool description adds no additional parameter-specific meaning beyond referencing the KMS key, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action (Create/activate) and the resource (token generator for a KMS key), plus the purpose (enables token-based authentication). It distinguishes itself from sibling tools like update/get/delete token generator.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is used to create/activate a token generator for a KMS key to enable token-based authentication. However, it does not explicitly contrast with alternatives (e.g., when to use update_token_generator instead) or state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_create_token_setA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare destructiveHint=false, so the description adds the clue that this is a creation operation requiring an active token generator. However, it does not disclose what happens if the generator is missing, whether existing token sets are affected, or any rate/expiration details. It adds minimal behavioral context 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence, front-loaded with the action, includes a parenthetical clarification and an important prerequisite. Zero wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter creation tool with no output schema, the description provides the essential purpose and a prerequisite. The response isn't described, but the phrase 'access token + refresh token' hints at the expected output. It is nearly complete, though it could be stronger by stating the exact result or ties to the token generator key tag.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes keyTag at 100% coverage, so the baseline is 3. The description adds no further semantic detail about the parameter, though it does relate the token generator prerequisite to the overall workflow.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource ('Create a token set') and explains the composition (access token + refresh token) and purpose (token-based authentication). It also includes a prerequisite that distinguishes it from the sibling ncloud_kms_create_token_generator, which creates a different entity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly states the purpose and the requirement of an active token generator, giving the agent a condition to check before invoking. It does not explicitly name alternatives or exclusions, but the context is clear enough for this tool's niche.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_disable_keyA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide idempotentHint=true and destructiveHint=false, and the description adds the key behavioral detail that the key becomes unusable for cryptographic operations. This goes beyond the annotations, although it does not discuss reversibility or implications for existing operations. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the action and followed by the consequence. Every word earns its place, with no redundant or vague phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a single required parameter, full schema coverage, and safe annotations (non-destructive, idempotent), the description adequately explains the purpose and effect. It omits explicit mention of reversibility or return value, but these are 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: keyTag is described as a unique identifier derived from key name. The description does not add any further parameter information, so it provides no extra value beyond the schema, which is the baseline case.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Disable an active KMS key') and its functional effect ('Disabled keys cannot be used for cryptographic operations'). It distinguishes this tool from siblings like ncloud_kms_enable_key and ncloud_kms_delete_key by specifying the exact operation on the key.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a context for use (when a key needs to be made inactive) and states a consequence, but it does not explicitly mention when to use this tool over related actions like enable, delete, or request deletion. No exclusions or alternatives are referenced.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_enable_keyA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false. The description adds the state transition (disabled → enabled) and the consequence of usability, which is useful context. It does not mention permissions, reversibility, or side effects, but with annotations covering the safety profile, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that is front-loaded with the action and clearly states the condition and result. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with comprehensive schema coverage and solid annotations, the description sufficiently covers the purpose and outcome. It does not explicitly state prerequisites (e.g., key must exist and be disabled), but this is implied and the tool is simple enough that the description is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the only parameter, keyTag, as a 'unique identifier derived from key name'. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Enable a disabled KMS key') with a clear result ('make it usable again'). It distinguishes itself from sibling tools like ncloud_kms_disable_key (opposite action) and ncloud_kms_enable_key_version (targets key version, not the key).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'disabled KMS key' explicitly indicates the condition under which to use the tool. However, no alternative tools or exclusions are mentioned (e.g., cannot enable a key pending deletion), but the context is clear for a single-state transition.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_get_key_listA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes this as a safe read operation. The description adds the pagination behavior, which is useful, but does not disclose details such as default page size, ordering, or potential inconsistencies when paginating through a changing dataset. This meets the baseline for a tool with annotation support.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant wording. It wastes no space and directly states the key aspects: action, resource, and pagination.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only listing tool with two optional parameters and no output schema, the description plus schema is sufficient to guide an agent. It identifies the resource and pagination, and the annotations cover side-effect safety. It does not explain return structure, but that is not necessarily required for such a straightforward list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes both parameters (pageNo, pageSize) with defaults and constraints, so schema coverage is high. The description's mention of pagination adds marginal context but does not go beyond what the schema implies. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get'), the resource ('list of all KMS keys'), and the scope ('all'), which distinguishes it from sibling tools like ncloud_kms_get_key_info (single key) and ncloud_kms_get_key_version_list (key versions). This is a specific and unambiguous verb+resource combination.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is the tool to call when you need a paginated list of all KMS keys, and the sibling context confirms this is distinct from detail/version/log tools. However, there is no explicit when-to-use or when-not-to-use guidance or named alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_get_public_keyA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation, but the description adds meaningful behavioral context by limiting the tool to RSA2048 or ECDSA keys. This warns the agent that other key types are unsupported, which is valuable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence with high information density. It front-loads the verb and resource, includes a key constraint, and contains no filler or redundant text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter, a clear read-only purpose, and supportive annotations. While there is no output schema and the return format (e.g., PEM, base64) is not specified, the description is sufficient for a straightforward getter. Missing return format is a minor gap but does not hinder task selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the only parameter 'keyTag' with a clear description. The tool description adds no additional parameter semantics, so it relies entirely on the schema, which already covers 100% of parameters. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' and clearly identifies the resource: 'the public key for an asymmetric key'. It also adds a key constraint ('RSA2048 or ECDSA only') that differentiates this from other KMS operations. No sibling tool retrieves public keys, so 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (when you need the public key of an asymmetric key) but does not explicitly state when to use this versus alternatives, nor does it mention any exclusions. There are no competing tools for this exact operation, but guidance is minimal and relies on the name and context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_cache_manual_backup_detailsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation, so the description does not need to restate that. The description adds only 'detailed information' scope but does not disclose return format, possible error conditions, or rate limits. It is consistent with annotations, adding minimal extra context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  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 target. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 well-documented parameter, the description is adequate. It could mention what 'detailed information' includes or that no output schema is provided, but given the low complexity and high schema coverage, it is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes the single parameter ('Cloud Cache manual backup number') with 100% coverage. The description does not add meaningful detail beyond the schema, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('detailed information about a specific Cloud Cache manual backup'), clearly distinguishing it from the sibling tool 'ncloud_list_cache_manual_backups' which lists backups. The scope is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'a specific Cloud Cache manual backup' implies this tool is for fetching details of one backup by ID, while the sibling list tool is for discovering IDs. There is no explicit when-not-to-use guidance, but the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_cache_usersA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already marks this as a safe read operation, and the description's 'List' verb is consistent. The description adds no extra behavioral detail such as pagination, response format, or access prerequisites, so it provides only basic transparency beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, complete sentence that directly states the tool's purpose. No superfluous words, and the key scoping qualifiers (DB users, ACL, Redis/Valkey) are positioned clearly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has two well-documented parameters and a clear listing purpose; the description sufficiently conveys what the tool does. It lacks any mention of output structure or pagination, but given the simplicity and existing schema documentation, it is complete enough for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%; both regionCode and cloudCacheInstanceNo have descriptive text in the schema. The tool description does not add any parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List'), the resource ('DB users (ACL)'), and the target system ('Cloud DB for Cache (Redis/Valkey) instance'). It distinguishes this from sibling tools like ncloud_add_cache_users, ncloud_change_cache_users, and ncloud_delete_cache_users, which perform mutations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this is the read-only listing operation for cache DB users. It does not explicitly mention when not to use it or direct to alternatives, but the contrast with mutation siblings is evident from the tool name and context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_certificatesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already conveys that this is a safe read operation. The description adds the domain ('registered SSL/TLS certificates') and filter capability, but does not disclose other behavioral aspects such as pagination, sorting, or response format. This is consistent with the annotation but does not go beyond it significantly, matching the '3' benchmark.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no fluff. The first sentence front-loads the core purpose, and the second succinctly lists the filter parameters. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with no required parameters and no output schema, the description covers the main action and filters adequately. It does not explain the return value structure, but the tool name and description make it obvious that a list of certificates is returned. Given its simplicity, it is near-complete, but could slightly benefit from mentioning that all parameters are optional for an unfiltered list, which the schema already implies.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (certificateName, certificateNo, instanceNo) already described as a filter. The description reiterates these filter fields but adds no new semantic meaning, such as how filters combine or whether they are mutually exclusive. Thus it provides no extra value over the schema, warranting the baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists all registered SSL/TLS certificates in Certificate Manager, using the specific verb 'List' and identifying the resource and scope. It distinguishes itself from sibling certificate tools like issue_private_certificate, register_external_certificate, and delete_certificate by its focus on listing registered certificates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 listing registered SSL/TLS certificates in Certificate Manager. However, it does not explicitly mention alternatives or when not to use it (e.g., distinguishing from ncloud_pca_list_cas for private CA certificates), so it misses the explicit exclusion/alternative guidance for a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_init_scriptsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, which matches the description. The description adds the region scoping constraint but does not disclose pagination behaviour or return format. Given the annotation already covers safety, this is acceptable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence ('List all init scripts in the current region') that immediately conveys the action, resource, and scope without any unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with full schema coverage and a readOnlyHint annotation, the description is adequate. However, since there is no output schema, a little more context about the return structure or pagination defaults would improve completeness, but it is not essential.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema descriptions cover 100% of parameters, including pagination and filtering. The description's phrase 'all' could slightly conflict with the optional initScriptNoList filter, but the schema clarifies this. The description 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List', a clear resource 'init scripts', and scopes it to 'the current region'. This clearly distinguishes it from sibling tools like ncloud_get_init_script_detail, ncloud_create_init_script, and ncloud_delete_init_scripts.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates when to use it (to enumerate init scripts in the current region) without mentioning alternatives or exclusions. The context is clear, but it does not explicitly state when not to use it or point to alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_ips_eventsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already conveys that the operation is read-only, and the description does not contradict this. The description adds the context that events are from Security Monitoring and that a subscription is required, but does not disclose other behavioral aspects such as pagination behavior or response structure. Given the existing annotation, the description adds some value but lacks richer behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise, consisting of two sentences that state the primary purpose and a key prerequisite. Every word is necessary and contributes to user understanding, with no redundancy or padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 11 parameters and no output schema, the description is adequate for a straightforward listing tool. The schema covers all parameter details, and the annotation clarifies the read-only safety profile. The main gap is the lack of response format information, but this is not critical for a list operation and the description sufficiently covers the tool's purpose and constraints.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions, so the schema already provides the parameter meanings. The description does not add any additional parameter semantics beyond what is already documented, so it meets the baseline of 3 but does not exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('IPS intrusion prevention events'), clearly identifying the tool's function. It distinguishes it from sibling event-list tools by naming the event type (IPS) and the source service (Security Monitoring).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear usage context by stating the requirement of being subscribed to Security Monitoring, which helps the agent determine eligibility. However, it does not explicitly mention when to use this tool over alternatives like ncloud_list_av_events or ncloud_list_waf_events, though the tool name and description make the distinction obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_launch_configsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint already present, the description adds the current region scoping but does not disclose pagination behavior or return format. It does not contradict the annotation, but offers limited behavioral context beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded with the action verb and resource. Every word carries meaning, with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with no required parameters, the description, schema, and readOnlyHint cover the essentials: what, where, and safety. Minor gaps remain around pagination defaults and the absence of an output schema, but the tool is straightforward enough that these are not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters (pageNo, pageSize, launchConfigurationNoList) are already explained. The description adds no additional parameter meaning, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and resource 'launch configurations for Auto Scaling' with a clear scope 'in the current region'. This clearly distinguishes it from sibling tools like get_launch_config_detail, create_launch_config, and delete_launch_config.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 the tool (when you need to enumerate launch configurations in the region). However, it does not explicitly mention alternatives or exclusions, such as using get_launch_config_detail for individual configs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_lb_rulesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation. The description adds the scope 'registered to a load balancer listener' but does not disclose additional behavioral details such as pagination, ordering, or return format. Given the annotation coverage, this is adequate but not enriched.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, short, front-loaded sentence with no filler. Every word earns its place, and it immediately communicates the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a low-complexity list tool with one parameter and a read-only annotation. The description, combined with the schema and annotation, provides sufficient information for an agent to select and invoke the tool. The absence of an output schema or details about rule structure is acceptable given the simplicity, though a note about return content would push it to 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the only parameter, loadBalancerListenerNo, is described as 'Load balancer listener number' in the schema. The tool description adds no additional parameter meaning, such as format, validation, or source of the value. Since the schema fully documents the parameter, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('rules registered to a load balancer listener'), clearly distinguishing this from siblings like ncloud_list_lb_listeners and ncloud_list_load_balancers. It precisely states the tool's function without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies clear usage context: use this when you need to retrieve rules for a specific load balancer listener. It does not explicitly name alternatives or exclusions, but the resource scoping ('registered to a load balancer listener') makes it obvious when to select this tool over others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_mongodb_instancesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The phrase 'all' and 'current region' disclose behavioral scope—returns all instances in the current region—beyond the readOnlyHint annotation. This adds useful context without contradicting the annotation, though pagination behavior is left to the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence with a front-loaded action verb 'List' and a direct object. No filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list tool with no output schema, the description adequately sets expectations for returning MongoDB instances in the current region. Pagination and filters are documented in the schema, so overall completeness is strong for a simple read operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all four parameters with clear descriptions (pagination and filters). The description does not add meaning beyond the schema, so it meets the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the explicit verb 'List' with the resource 'Cloud DB for MongoDB instances' and scopes it to 'current region', clearly distinguishing it from sibling tools like ncloud_get_mongodb_instance_detail and ncloud_list_mongodb_users.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for enumerating MongoDB instances in the current region but does not mention alternatives, when-not-to-use, or exclusion scenarios. No explicit guidance is given beyond the inherent list operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_mssql_bucketsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already declares this is a read operation. The description adds the specific purpose but does not disclose additional behavioral traits such as region filtering behavior or response format. This is acceptable given the annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no filler. It front-loads the action and resource, and every word contributes meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (1 optional parameter, no output schema, readOnly annotation), the description is sufficiently complete. It clearly states the tool's scope and purpose. A minor gap is lack of detail on return values, but the rule says description needn't explain return values when no output schema exists.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100% for the single parameter regionCode. The description does not add any parameter semantics beyond the schema, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('Object Storage buckets') with a clear qualifier ('available for Cloud DB for MSSQL backup export'). This distinguishes it from generic bucket listing tools and other database-specific bucket listers like ncloud_list_postgresql_buckets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you need to list Object Storage buckets for MSSQL backup export. It provides context for selection among siblings, though it does not explicitly name alternatives or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_multipart_uploadsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description aligns with that by using 'List'. It adds context about 'in-progress' uploads, which is useful behavioral information beyond the annotation, but does not disclose details like pagination, response format, or default limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the core action. Every word 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with full schema coverage and a read-only annotation, the description is mostly adequate. However, since there is no output schema, a brief note on the returned fields (e.g., upload ID, key, initiation time) would have made it more complete for an agent parsing results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with each parameter (prefix, delimiter, bucketName) having clear descriptions. The tool description does not add parameter-level semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 ('in-progress multipart uploads') and scope ('for a bucket'), making its purpose unambiguous. It distinguishes itself from sibling tools like ncloud_list_objects, ncloud_list_parts, and ncloud_initiate_multipart_upload by specifying 'in-progress multipart uploads'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use the tool: when you need to see ongoing multipart uploads for a bucket. It does not explicitly mention alternatives or exclusions, but the context is clear enough for a listing operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_object_versionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description is consistent with this. The description adds the useful context that this operation lists ALL versions and requires versioning-enabled, but it does not disclose pagination behavior, potential large result sets, or what happens when versioning is disabled. This is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that immediately states the tool's purpose. It is front-loaded with the action and resource, and every word earns its place. There is no redundant or vague wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is sufficiently complete for a simple listing operation. It includes the key condition (versioning-enabled), and the schema fully describes all parameters. Without an output schema, the return format is not explained, but for a list operation this is not a major gap. The annotation and schema cover the rest.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all 6 parameters, so the schema fully documents each parameter. The description does not add any additional meaning beyond what the schema provides, matching the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' with the resource 'all versions of objects in a versioning-enabled Object Storage bucket'. It clearly distinguishes this tool from sibling ncloud_list_objects by focusing on object versions rather than current objects, and it correctly identifies the required bucket configuration.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states the prerequisite that the bucket must be versioning-enabled, which gives clear context for when to use this tool. It does not mention alternatives or exclusions, but the purpose is unambiguous and the required condition is stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_partsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals this is a safe read operation. The description adds the 'in progress' constraint, which is useful context (the tool only works for active uploads). However, it does not mention potential errors, pagination, or response format, so it adds only marginal behavioral detail beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that conveys all necessary information without any wasted words. It is front-loaded with the action and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with a 100% schema coverage and no output schema, the description is largely complete. It clearly states the purpose and the condition ('in progress'), though it could have explicitly mentioned that bucketName, objectName, and uploadId identify the specific upload, but this is already evident from the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides complete coverage (100%) with clear descriptions for all three required parameters: bucketName, objectName, and uploadId. The tool description does not add further parameter details, but given the high schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List uploaded parts') and the specific resource ('a multipart upload in progress'), which precisely identifies this tool and differentiates it from sibling tools like ncloud_list_multipart_uploads (which lists uploads, not parts). The verb and resource are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'in progress' implies this tool is used after initiating a multipart upload and after uploading parts, but before completing or aborting. It provides clear context for when to use it, though it does not explicitly name alternative tools or state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_pipelinesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile, so the description does not need to justify read-only behavior. It adds a little context by mentioning pagination and name search, but does not disclose default behavior (e.g., whether all pipelines are returned by default, max page size, or how pagination parameters interact). This is a simple list operation, so the gap is minor but present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that immediately conveys the tool's purpose and key options. There is no redundancy or wasted words; every phrase adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with fully described optional parameters and a readOnlyHint annotation, the description is largely sufficient. It lacks details about default pagination behavior or the response structure, but these are not critical given the tool's simplicity and the absence of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter (pageNo, pageSize, projectName) is already clearly described in the schema. The description's mention of 'optional pagination and name search' simply summarizes the existing schema information without adding new semantic detail, justifying the baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List'), the resource ('SourcePipeline pipelines'), and key capabilities ('optional pagination and name search'). This distinguishes it from sibling tools like ncloud_get_pipeline (which retrieves a single pipeline) and ncloud_list_pipeline_history (which lists run history), so 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for listing SourcePipeline pipelines and mentions pagination and name search, which helps the agent choose when to call it. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of the best examples.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_policiesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the scope of 'all available' but does not disclose that results are paginated or that filters exist (both are visible in the schema). It provides modest additional context beyond the annotation but lacks details about response structure or pagination behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the verb and resource. Every word earns its place, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with all parameters self-documented in the schema and read-only annotations, the description is adequate. It names the exact resource ('IAM policies') and implies a list operation. However, the absence of an output schema and any mention of pagination or return format leaves some gaps, but these are minor for a straightforward listing tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, meaning all five parameters already have descriptive text. The description adds no extra 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all available IAM policies' uses a specific verb ('List') and clearly identifies the resource ('IAM policies'), distinguishing it from sibling tools like ncloud_gtm_list_policies and ncloud_drm_list_policies. It precisely states what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly scopes usage to IAM policies, making it obvious this is for IAM rather than GTM or DRM policies. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select this tool over similar policy-listing tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_port_pluginsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already declares this as a safe read operation. The description adds the 'full list' scope (no filtering), which is useful context, but it doesn't disclose additional behavioral traits such as return format, pagination, or whether the list includes plugins from all servers. With annotations covering the safety profile, the description meets the bar but doesn't exceed it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 10 words, front-loaded with the verb 'Get.' Every word earns its place — it states the action, the resource, and the scope ('full list'). There is zero waste or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool with no output schema, the description is largely complete: it states what is retrieved and the annotation confirms it's a safe read. The only gap is that it doesn't relate itself to the companion tools (get/add/remove/set_port_plugin) or describe the return structure, but these are not critical for a simple enumeration operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and schema description coverage is 100% (empty schema). Per the rubric, 0 params earns a baseline of 4. The description reinforces that no parameters are needed by framing this as a 'full list' operation, which is sufficient since there is nothing to document.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get the full list of Cloud Insight port monitoring plugins.' The word 'full' clarifies scope, and the phrase 'Cloud Insight port monitoring plugins' precisely identifies the resource. This distinguishes it from siblings like ncloud_get_port_plugin (single plugin) and ncloud_list_process_plugins (different plugin type).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context — this is the list-all operation for port plugins — but it does not explicitly name alternatives or state when not to use it. Sibling tools like ncloud_get_port_plugin and ncloud_add_port_plugin exist, and the description could have mentioned 'for a single plugin, use get_port_plugin' but does not. Usage is clear but only by implication from the name and 'full list' phrasing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_public_ipsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description is consistent. It adds the 'current region' scoping but does not disclose pagination defaults or filtering behavior beyond what the schema provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, front-loaded, with no unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with optional filters, the description is sufficient, though it does not mention pagination behavior or output format; the lack of output schema is mitigated by the straightforward nature of the operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 four parameters. The description adds no additional parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('public IP instances') with scope ('current region'), clearly distinguishing it from sibling tools like ncloud_get_public_ip_detail or ncloud_create_public_ip.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context for when to use the tool (listing public IPs in the current region), but does not explicitly mention alternatives or when not to use it, such as when a specific IP detail is needed via ncloud_get_public_ip_detail.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ncr_list_registriesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals that this is a safe read operation. The description adds the regional scope but does not disclose pagination behavior, response format, or potential limits beyond what the schema parameters imply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that conveys the essential purpose and scope. Every word is meaningful, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with two optional, well-documented parameters and a readOnly annotation, the description is mostly complete. It could improve by mentioning that results are paginated, but the schema already provides page/pageSize hints.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema documents both parameters with clear descriptions ('Page number (must be > 0)' and 'Page size (must be > 0)'), and schema coverage is 100%. The tool description adds no additional param semantics, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('container registries') with an explicit scope ('current region'). It clearly distinguishes itself from sibling tools like ncloud_ncr_list_images or ncloud_ncr_create_registry by naming the exact resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by indicating that it lists registries in the current region. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_get_server_specsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation is consistent with the 'List' action, and the description adds valuable context about the dependency on ncloud_nks_get_server_images. However, it does not disclose potential response format, pagination, or other behavioral traits beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the core purpose, no filler or redundant information. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with full schema coverage and a read-only annotation, the description is adequate. It clearly states purpose and prerequisites. It could optionally mention the return value (list of server specifications), but the tool name and nature make this obvious.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents all parameters with descriptions, achieving 100% coverage. The description adds minimal extra meaning, mostly repeating the dependency on ncloud_nks_get_server_images and the zoneCode/zoneNo mutual requirement already present in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: 'List available server specifications for NKS cluster/node pool creation.' It uses a specific verb ('List'), identifies the resource ('server specifications'), and scopes it to NKS cluster/node pool creation, distinguishing it from sibling tools like ncloud_get_server_specs or ncloud_ses_get_server_specs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by stating this is for NKS cluster/node pool creation and listing required prerequisites (softwareCode from ncloud_nks_get_server_images and zoneCode or zoneNo). However, it does not explicitly mention when not to use it or name alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_update_node_poolA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool idempotent and non-destructive. The description adds minimal behavioral context beyond stating what it updates; it does not disclose parameter interactions, prerequisites, or operational implications. With annotations covering safety, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence, front-loaded with the verb, clearly communicating the purpose without any unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given full schema documentation and clear annotations, the description provides sufficient context for correct invocation. It could mention parameter selection rules more explicitly, but the schema's description of nodeCount ('required if autoscale disabled') already covers the main constraint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so all parameters are already documented. The description reinforces the two key parameters (nodeCount and autoscale) but adds no new semantic details beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Update'), the resource ('node pool settings'), and the specific scope ('node count or autoscale') within an NKS cluster. This distinguishes it from sibling tools that update labels, taints, or subnets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 the tool (updating node count or autoscale), but does not explicitly name alternatives or exclusion cases, such as using ncloud_nks_update_node_pool_label for label updates.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_update_node_pool_labelA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds crucial behavioral context beyond the annotations: 'PUT replaces all labels'. This warns the agent that existing labels will be overwritten, which is important despite destructiveHint=false. The idempotentHint=true is consistent with PUT semantics, and the description adds value by clarifying the replacement behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the core action and includes a critical behavioral note. Every word adds value, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple scope (update labels), the description combined with full schema coverage and annotations provides sufficient context. It clearly states the operation and the full-replacement behavior. No output schema exists, so return values need not be explained. Minor omission: no guidance on empty labels behavior, but not essential.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 (clusterUuid, instanceNo, labels) with descriptions. The tool description does not add additional parameter-level semantics 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Update') and resource ('labels on a node pool in an NKS cluster'), clearly distinguishing it from sibling tools like update_node_pool_taint or update_node_pool. The target and scope are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when you need to update node pool labels), but does not provide explicit guidance on alternatives or exclusions. No mention of related tools for taints or other node pool properties.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pca_get_crl_configA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true and the description's 'Get' is consistent, so there's no contradiction. However, the description adds no further behavioral context such as return format, specific fields, or prerequisites. It mostly restates the tool's purpose, providing minimal additional transparency beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It immediately states the action and resource, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one required param, read-only) and the description sufficiently conveys what it does. However, without an output schema, it doesn't specify the exact response fields (e.g., interval value and units), so it's not maximally complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single parameter caTag with its own description 'CA tag value'. The tool description adds no extra parameter meaning, so baseline 3 applies because the schema already fully documents the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and identifies the exact resource ('CRL update interval configuration') scoped to a Private CA. This clearly distinguishes it from sibling tools like ncloud_pca_get_ca_crl (gets the actual CRL) and ncloud_pca_update_crl_config (updates the config).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: use this to fetch CRL update interval settings. It doesn't explicitly state when not to use or mention alternatives, but the wording naturally differentiates it from related PCA tools. The agent can infer usage from the precise resource name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pca_revoke_end_certA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already include destructiveHint=true, and the description reinforces this with the warning 'Destructive' and adds new behavioral context: 'irreversible' and 'certificate will no longer be trusted.' These details go beyond the annotation by explaining the permanence and consequence of the action, which is valuable for an agent. No contradiction with annotations (idempotentHint=true is not addressed but does not conflict).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise sentence with a leading warning icon and word 'Destructive'. It front-loads the critical safety information and conveys the action and consequence without any filler. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with strong annotations (destructive and idempotent) and a 100% schema coverage, the description provides sufficient context: what it does, how it's done (by serial number), and key consequences. It does not cover return values, but there is no output schema to explain; it also omits prerequisite details like requiring an active CA, but these are not critical given the schema and annotations. Overall, it is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both caTag and serialNo have clear descriptions in the input schema. The tool description only mentions 'by its serial number', which reinforces serialNo but adds no new meaning beyond the schema. This meets the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Revoke an end-entity certificate by its serial number.' It uses a specific verb and resource, distinguishing it from sibling operations like issuing, signing, or listing certificates. The consequence 'the certificate will no longer be trusted' further clarifies the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (for revoking a certificate) but does not explicitly mention alternatives or when-not-to-use conditions. It lacks guidance such as 'use list_end_certs to find the serial number first' or 'for revoking a CA, use pca_trim_ca instead.' The usage context is understandable but not fully defined.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pipeline_list_sourcedeploy_projectsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the safe read-only nature, and the description correctly aligns with that. The description adds little behavioral depth beyond stating the listing action; it does not disclose pagination, return format, or any account-specific restrictions. With annotations present, a baseline 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly communicates the action and purpose with no unnecessary words. It is concise and to the point.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with complete schema documentation and read-only annotations, the description is adequate. It indicates the general purpose and relies on the schema for parameter details. It does not describe the response structure, but that is not critical for a list operation. Slightly more detail on return values or criteria would have earned a 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all three parameters (pageNo, pageSize, searchWord), so the schema already fully explains parameter semantics. The description does not add extra meaning to the parameters, making the baseline 3 the correct score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a list operation on SourceDeploy projects with the specific purpose of pipeline task configuration. It uses a specific verb ('List') and resource ('SourceDeploy projects'), and the qualifier 'for pipeline task configuration' distinguishes it from the generic ncloud_sourcedeploy_list_projects sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context by indicating this is for pipeline task configuration, which implies the tool should be used when selecting a SourceDeploy project within a pipeline. However, it does not explicitly call out alternatives or exclusions, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_reboot_cache_serverA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, establishing the safety profile. The description adds no extra behavioral context such as potential downtime, duration, or post-reboot status. It simply restates the action without additional transparency 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence with no filler or redundancy. The description is front-loaded with the action and resource, making it immediately scannable and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (one required parameter), the presence of idempotent and non-destructive annotations, and the absence of an output schema, the description is sufficient to understand the tool's function. It could mention that the reboot may temporarily disrupt the cache service, but that is not essential given the clear action.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the single parameter, including a clear description ('Cloud Cache server instance number to reboot'). The tool description adds no additional meaning, examples, or format details beyond the schema, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific action ('Reboot') and a specific resource ('Cloud DB for Cache server instance'), which clearly distinguishes it from sibling reboot tools like ncloud_reboot_mysql_server or ncloud_reboot_server. It is concise and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly identifies the resource type, making it evident when this tool should be used (for Cloud DB for Cache instances) versus other reboot tools. However, it does not explicitly state exclusions or alternatives, falling slightly short of the full guidance provided in top-tier examples.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_reboot_serverA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, so the description is not burdened with the full safety profile. It adds the prerequisite that instances must be running and that multiple servers can be included, but it does not disclose potential downtime or whether the reboot is graceful. This is adequate given 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the action, resource, and scope. There is no redundancy or unnecessary detail—every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a low-complexity tool with one parameter and no output schema. The description covers the action and scope, and the annotation covers idempotency and safety. It could have mentioned that it is for compute server instances (as opposed to database servers), but the tool name and sibling context make this clear. Overall, the description is complete enough for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, serverInstanceNoList, is fully described in the schema (100% coverage) as a list of server instance numbers to reboot. The main description adds no additional parameter semantics, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Reboot') with a clear resource ('server instances') and scope ('one or more running'), distinguishing it from sibling tools like start_server, stop_server, and terminate_server. It is immediately obvious what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'running server instances' establishes a clear context for when to use the tool (only on running instances) and indicates support for multiple instances. However, it does not explicitly mention alternatives or when-not-to-use cases, though the verb itself makes the usage clear relative to start/stop/terminate siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_register_external_certificateA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include destructiveHint=false, indicating a non-destructive operation. The description adds little beyond that; it does not disclose side effects, permissions, validation behaviors, or idempotency. It is not contradictory, but the added behavioral context is minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that immediately conveys the tool's purpose with relevant examples. There is no redundant or extraneous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the straightforward nature of registering a certificate, the description combined with the fully documented schema is largely complete for an agent to select and invoke the tool. It lacks explicit return-value or alternative-tool guidance, but those are not critical here.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all four parameters (privateKey, certificateName, certificateChain, publicKeyCertificate) clearly described. The tool description itself adds no parameter-level information beyond what the schema already provides, so it meets the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Register') and resource ('external SSL certificate issued by a third-party CA'), with concrete examples (Let's Encrypt, ZeroSSL, DigiCert). It distinguishes itself from sibling tools like ncloud_issue_private_certificate by specifying the certificate source.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 the tool: when registering an external certificate from a third-party CA. However, it does not explicitly mention alternatives or state when not to use it, though the scope is implicitly defined by the 'external' and 'third-party CA' wording.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_acg_outbound_ruleA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Although destructiveHint annotation already signals destructiveness, the description adds value by explicitly warning with ⚠️ and highlighting the confirm=true gate required to execute. This goes beyond the annotation, though it does not elaborate on idempotency or side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the warning, states the action, and gives the essential confirm instruction. No wasted words, highly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive removal tool with comprehensive schema and annotations, the description sufficiently covers the critical operational context (destructive, confirm required). It does not cover success/failure return values or prerequisites, but those are less critical given the simple single-object operation and existing structured metadata.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 only repeats the confirm=true instruction already present in the schema (property 'confirm'), adding no additional meaning beyond what structured data provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Remove an outbound rule from an Access Control Group.' This specific verb+resource+scope distinguishes it from sibling tools like ncloud_remove_acg_inbound_rule by explicitly naming 'outbound'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides implicit context (destructive, requires confirm=true) but does not explicitly state when to use this tool over alternatives, mention exclusions, or describe scenarios. It relies on the tool name and schema for context, offering no direct guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_file_pluginA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds value by explicitly stating what is destroyed ('file monitoring plugin(s)') and requiring a confirmation flag ('Set confirm=true to execute'), which is crucial for safe usage. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is a single concise sentence preceded by a warning symbol. Every word contributes: it names the action, target, and critical confirmation requirement. No wasted text or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive removal tool, the description adequately covers the action, the lifecycle (confirmation required), and the target. The annotations supply safety context, and the schema covers parameter details. It does not explain return values, but that is not critical for this operation type.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and all parameters already have descriptions (e.g., configList 'File paths to remove', confirm 'Must be true to actually execute'). The tool description does not add additional parameter semantics beyond what the schema provides, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the specific action ('Remove') and resource ('file monitoring plugin(s)') with target ('server instance'), distinguishing it from sibling tools like list/get/add/set file plugins. The verb+resource structure leaves no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives (e.g., list/add/set file plugins). It provides the important safety instruction 'Set confirm=true to execute' but that is an invocation detail, not a selection guideline. Usage context is implied by the name and destructive warning.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_member_server_image_sharingA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare destructiveHint and idempotentHint. The description adds the confirm=true safeguard requirement and a strong 'DESTRUCTIVE' warning, going beyond the structured annotations. It does not detail post-conditions or reversibility, but the annotations already cover the destructive nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with a clear warning emoji and front-loaded destructive alert. Every word contributes: the action, the resource, and the execution requirement. No redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema covers all parameters, annotations cover destructive/idempotent behavior, and the description specifies the confirmation gate. For a focused permission removal tool, this is largely complete. It lacks mention of what happens after removal (e.g., immediate loss of access), but the destructive hint already signals consequences.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 additional meaning to the parameters; it only repeats the confirm requirement already present in the schema. No extra context for targetLoginIdList or memberServerImageInstanceNo is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action: 'Remove sharing permission for a member server image.' It includes the resource type ('member server image') and distinguishes from sibling tools like ncloud_remove_server_image_sharing by scoping to member images. The destructive warning and confirm requirement add clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly mention when to use this tool versus alternatives such as ncloud_add_member_server_image_sharing or ncloud_remove_server_image_sharing. It provides an operational guideline ('Set confirm=true to execute') but no selection guidance or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_network_acl_inboundA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds the confirm-gating behavior ('Set confirm=true to execute'), which is not in the annotations, and reinforces the destructive nature. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences: the first states the core action, the second provides the necessary confirmation requirement. No filler or redundant details; every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the annotations cover the destructive/idempotent nature and the schema fully documents parameters, the description provides the essential extra context (confirm=true requirement). It is sufficient for a destructive removal tool, though it could theoretically mention the effect on traffic, which is not necessary given annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 8 parameters have descriptions in the schema (100% coverage), so the schema carries the parameter semantics. The description mentions 'confirm', but that is also documented in the schema, adding no new meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Remove an inbound rule from a Network ACL' with a specific verb and resource, clearly distinguishing from sibling tools like ncloud_remove_network_acl_outbound and ncloud_add_network_acl_inbound. It is unambiguous and immediately conveys the exact operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly compare with alternatives or state when not to use. It provides an execution prerequisite ('Set confirm=true to execute'), but usage context is otherwise only implied by the tool's name and purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_port_pluginA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already include destructiveHint and idempotentHint. The description adds a warning and clarifies the confirm flag requirement, explaining that execution only happens when confirm=true. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One concise sentence with a warning prefix. Information is front-loaded and every word adds value; no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive tool with 4 parameters and no output schema, the description covers the essential safety and execution requirements. It could mention prerequisites or side effects, but the current description is sufficient for an agent 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are documented in the schema. The description reinforces the confirm behavior already described in the schema but adds no new parameter-specific meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Remove port monitoring plugin(s) from a server instance' with a specific verb and resource. It distinguishes itself from sibling tools like ncloud_list_port_plugins, ncloud_add_port_plugin, and ncloud_set_port_plugins.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied (use when you want to remove port monitoring plugins), but there is no explicit when-to-use or when-not-to-use guidance or alternatives mentioned. The instruction 'Set confirm=true to execute' provides execution context but not tool-selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_routeA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint and idempotentHint, and the description reinforces this with a '⚠️ Destructive' warning. It also adds the confirmation gate ('Set confirm=true to execute'), which is behavioral context beyond the annotations. This discloses that the destructive operation will not execute unless confirmed, giving the agent a clear safety mechanism.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two sentences, with the critical warning placed first and the operational instruction second. Every word is necessary, and there is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple destructive operation, annotations cover safety, and schema covers all parameters, the description is complete enough. It adds the key confirmation requirement. Since there is no output schema, the description does not need to explain return values. A minor gap is the lack of prerequisites (e.g., valid route table), but that is implied by the parameter descriptions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: all six parameters (routeTableNo, vpcNo, destinationCidrBlock, targetTypeCode, targetNo, confirm) have descriptive text. The description adds no new parameter-level semantics beyond what the schema provides, so the baseline of 3 applies. It does reiterate the 'confirm' behavior but that is already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action: 'Remove a route from a route table.' This distinguishes it from sibling tools like ncloud_add_route (adding) and ncloud_remove_route_table_subnet (removing a subnet, not a route). The verb 'remove' plus resource 'route' is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (you use this when you need to delete a route) and provides a critical instruction ('Set confirm=true to execute'), but it does not explicitly mention when to prefer this tool over alternatives like ncloud_remove_route_table_subnet or ncloud_add_route. No exclusions or alternative tools are named, so guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_restore_objectA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full behavioral disclosure burden. It does disclose a key behavior: the restored copy is available for a specified number of days. However, it omits other traits like whether the restore is asynchronous, whether it incurs cost, or whether it affects the original archived object, and it doesn't describe any return value or error conditions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, zero filler. The main action is front-loaded in the first sentence, and the second sentence explains the duration parameter. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 3 required parameters and no output schema, the description covers the essential context: what triggers the restore, what makes it accessible, and the time-bound nature. The absence of notes about async behavior or permissions is a minor gap, but the tool is simple enough that this is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% parameter coverage with descriptive text for bucketName, objectName, and days. The description reiterates the meaning of days ('available for the specified number of days') but adds no new semantic detail beyond the schema. Baseline of 3 is appropriate when schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Restore') with a clear resource ('an object stored in Archive class') and states the outcome ('make it accessible'). This clearly distinguishes it from sibling tools like ncloud_get_object which retrieve accessible objects, and ncloud_copy_object which copies objects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly conditions the use case: objects stored in Archive class. This tells the agent when to use this tool versus other object operations. However, it doesn't explicitly name alternatives or exclusions, such as 'use get_object for objects not in Archive', which would strengthen guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_get_cluster_detailA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description 'Get detailed information' aligns with a read-only operation. The description adds no extra behavioral traits beyond specificity, so the annotation carries the load, making a 3 appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the action and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only get-detail tool with one documented parameter and a readOnlyHint, the description is sufficient for an agent to select and invoke it. It does not detail the response contents, but the tool name and description adequately convey its purpose.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers the sole parameter fully with a clear description, meeting the high schema coverage baseline. The tool description adds no further parameter semantics, so a 3 is warranted.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb (get) and resource (specific Search Engine Service cluster), clearly distinguishing it from list-type siblings like ncloud_ses_list_clusters and aspect-specific tools like ncloud_ses_get_cluster_acg.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The word 'specific' implies a targeted lookup on a known cluster, and the parameter description ('from getClusterInfoList') hints at a prerequisite. However, it does not explicitly compare to alternatives or state when not to use it, so clear context is present but exclusions are missing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_get_server_specsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals this is a safe read operation. The description adds no additional behavioral context such as auth requirements, rate limits, or what kind of data is returned. It does not contradict the annotation, but it also doesn't go beyond it, earning a middle score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states the action, resource, and constraint without any redundant words. It is immediately scannable and richly informative for its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With one required parameter, a read-only annotation, and no output schema, the description gives the essential scope (SES, G3/KVM only) and the schema covers parameter provenance. It lacks a note about the return shape, but the operation is sufficiently simple that this is not a major gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter softwareProductCode is fully described in the schema ('OS product code (from getClusterServerImageList)') with 100% schema description coverage. The tool description itself adds no extra parameter semantics, which is acceptable given the schema carries the burden effectively.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get available node server types for Search Engine Service (G3/KVM only)' clearly states a specific verb ('Get'), a precise resource ('node server types for Search Engine Service'), and a scoping qualifier ('G3/KVM only'). This effectively distinguishes it from sibling tools like ncloud_get_server_specs (general compute) and ncloud_nks_get_server_specs (Kubernetes).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: this is for Search Engine Service and specifically G3/KVM node types. However, it does not explicitly name alternative tools or state when not to use it. The context is sufficient for an agent to select it among SES-related tools, but lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_get_snapshot_bucketsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true is consistent with the description's 'Get ... list' action. The description adds that the list is filtered to buckets available for snapshot storage, but does not disclose additional behavior such as output format or permission requirements. Annotation coverage makes this acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the action and purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one parameter, the description adequately conveys what the tool does. It does not specify the exact return structure, but the wording 'bucket list' implies a list of buckets. Given the low complexity and no output schema, this is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage, with the single parameter 'serviceGroupInstanceNo' described as 'Cluster instance number'. The tool description does not add any extra parameter context, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and resource ('Object Storage bucket list') with a specific purpose ('available for storing cluster snapshots'). This distinguishes it from sibling tools like ncloud_ses_get_import_buckets, which serve a different need.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for selecting buckets when setting up or managing cluster snapshots, providing clear context. It does not explicitly name alternatives or exclusions, but the purpose scoping makes the use case obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_get_snapshot_historyA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already communicates that this is a safe read operation. The description adds context about the resource type (Search Engine Service cluster) but does not disclose details such as the response structure, pagination, or any filtering behavior. This adds some value but not substantial behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It directly states the operation and target resource, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only get with one parameter and no output schema, the description conveys the essential information: what is retrieved (snapshot creation history) and for which resource (SES cluster). It does not explicitly describe the return format, but given the simplicity of the tool, this is largely adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents the single parameter 'serviceGroupInstanceNo' with the description 'Cluster instance number' at 100% coverage. The tool description reinforces the cluster context but does not add meaning beyond what the schema provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' and clearly identifies the resource as 'snapshot creation history' for a 'Search Engine Service cluster'. This distinguishes it from sibling snapshot tools like ncloud_ses_get_snapshot_buckets or ncloud_get_snapshot_detail, making its purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool (when snapshot creation history is needed for an SES cluster), providing clear context. However, it does not explicitly mention alternatives or state when not to use it, which is typically present for a score of 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_get_versionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation aligns with the 'Get' action, so there is no contradiction. However, the description adds no extra behavioral context, such as the format of the returned versions or any regional considerations. Given the annotation, this is acceptable but minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence of ten words, with the action and object front-loaded. Every word is necessary; there's no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter read-only operation, the description sufficiently communicates the tool's output scope. It lacks details on the response format, but the absence of an output schema and the simple nature of the task make this a minor omission. The description is complete enough to inform an agent of the tool's function.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  This tool accepts no parameters, and the input schema is empty. The description doesn't need to explain parameter semantics, so the baseline score of 4 applies. It does specify the engine type (Elasticsearch/OpenSearch), which provides context beyond an empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('available Search Engine versions'), explicitly naming Elasticsearch/OpenSearch. This clearly differentiates it from sibling version tools like ncloud_nks_get_versions (Kubernetes) and ncloud_cdss_get_kafka_versions (Kafka).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no explicit guidance on when to employ this tool versus similar version-listing siblings. Usage is implied by the name and description, but no alternatives or exclusions are mentioned, which is a notable gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_list_clustersA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, so the read-only nature is covered. The description adds useful context about region scoping and the service type, but it does not disclose pagination behavior, potential large result sets, or that 'all' might require iterating pages. With annotations covering safety, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with no redundancy. It states the action, resource, and scope efficiently. Every word contributes to understanding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a straightforward list operation with readOnly annotation and fully documented optional parameters. While there is no output schema, the description covers the essential scope and resource type. The only minor gap is not explicitly stating the return format, but for a list tool this is largely implied and pagination is handled by documented parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (pageNo, vpcName, pageSize, inputText) having a clear description including defaults and matching semantics. The tool description adds no parameter-specific details, but the schema fully carries that burden, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and identifies the exact resource ('Search Engine Service clusters') with clarifying parenthetical '(Elasticsearch/OpenSearch)'. It also specifies scope ('in the current region'), distinguishing it from sibling list tools like ncloud_cdss_list_clusters and ncloud_hadoop_list_clusters.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly conveys what the tool does (lists all clusters in the current region), providing enough context for an agent to know when to use it. However, it does not explicitly mention alternatives or exclusion criteria (e.g., when to use ncloud_ses_get_cluster_detail instead), so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_unset_snapshot_scheduleA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description must carry the full burden. It discloses a key behavioral trait: it only removes the schedule and does not delete existing snapshots, which is crucial for a mutating operation. However, it does not mention other potential side effects (e.g., idempotency, impact on future snapshots), so it is not maximally transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the primary action. Every word adds value, and the 'not existing snapshots' clarification is a valuable addition without unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple unset tool with one parameter and no output schema, the description is sufficiently complete. It clearly states what is removed and what is preserved, which covers the essential context. It does not mention return values or asynchronous behavior, but these are less critical for this type of operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for the only parameter (serviceGroupInstanceNo described as 'Cluster instance number'). The description adds no additional parameter-level meaning, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Unset (disable)') and clearly identifies the resource ('snapshot scheduling for a Search Engine Service cluster'). It distinguishes this from sibling tools like ncloud_ses_set_snapshot_schedule by its opposite action, and the scope clarification ('only removes the schedule, not existing snapshots') removes ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (to disable snapshot scheduling) but does not explicitly mention alternatives or exclusions. It lacks a direct reference to sibling tools like ncloud_ses_set_snapshot_schedule or ncloud_ses_create_snapshot, making the usage guidance indirect rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_set_regionA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey that the operation is idempotent and not destructive/read-only. The description adds accepted values but does not disclose broader behavioral details such as whether the region change is global or per-session, or affects subsequent calls. With annotations covering the safety profile, this is acceptable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single compact sentence that states the purpose and accepted values with no unnecessary words. It is front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple setter with one parameter, no output schema, and clear annotations, the description is adequate. It explains the parameter format and the operation. It could mention the scope of the change (e.g., global vs. session), but this is not critical given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage of the 'region' parameter with explicit mappings (KR: KR-CENTRAL, KRS: KR-SOUTH, 한국, 한국남부). The description loosely repeats this information without adding new semantic meaning, so it does not exceed the schema's clarity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Set the active Ncloud (Gov) region by code or Korean name.' It uses a specific verb ('Set') and resource ('active region'), and explains accepted input formats (KR, KRS, 한국, 한국남부). This distinguishes it from sibling tools like ncloud_get_current_region or ncloud_get_regions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when you need to change the active region) but does not explicitly name alternatives or state when not to use it. Context is clear, but no exclusions or comparisons to related region tools are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcebuild_get_projectA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the read-only nature, which the description aligns with ('Get'). The description adds minimal extra context (e.g., 'detailed information') but does not disclose other behavioral traits such as return format or potential not-found conditions. Since annotations already cover the safety profile, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant words. It is appropriately concise for a tool with one parameter and clear purpose, earning full marks.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a simple contract (one parameter, no output schema) and the description sufficiently conveys the operation. It could mention details about the returned data, but 'detailed information' covers this reasonably well. The presence of readOnlyHint and a self-explanatory parameter makes the description nearly complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the sole parameter (projectId), so the schema already documents its meaning. The description does not add any further syntax or value beyond identifying the project, so the baseline score of 3 holds.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and resource ('detailed information about a specific SourceBuild project'), making it distinct from the sibling tool ncloud_sourcebuild_list_projects and the build history getter. It is a specific verb+resource statement with no ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'specific SourceBuild project' clearly implies this is for retrieving details of a single project, given its one required projectId parameter. It provides clear context without explicitly naming alternatives, which is sufficient for a get-type tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcebuild_list_runtime_versionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation already declares readOnlyHint=true, and the description's 'List' aligns with a read operation. No additional behavioral traits (e.g., error handling, auth requirements, rate limits) are disclosed, but the lack of side effects makes this acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that efficiently conveys the tool's purpose without redundancy or wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation, the combination of schema, annotation, and description is sufficient. Though no output schema exists, the purpose is clear enough for an agent to understand the expected return type (a list of versions).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with each parameter described and cross-referenced to source tools. The description adds no extra parameter detail beyond the schema, which already provides sufficient guidance on parameter origins.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (list), resource (runtime versions), and scope (for a specific OS and runtime in SourceBuild). It is specific and distinguishes from sibling tools like list_os and list_runtimes, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used after obtaining an OS and runtime ID, as it requires both parameters. It provides clear context but does not explicitly state exclusions or alternatives, though sibling differentiation is inherent in the scope.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcecommit_create_repoA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only include destructiveHint: false. The description adds valuable context about the dryRun preview behavior, which goes beyond the annotation. It does not contradict the annotation and provides a safety note for a creation operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no wasted words. It states the core purpose and the most important usage modifier (dryRun).

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create tool with fully documented schema parameters, the description is sufficient. It covers the action and a key behavioral option (dryRun). Lack of output schema is not a gap for this simple create operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all 5 parameters with 100% coverage. The description does not add parameter-level detail beyond that, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Create a new SourceCommit repository' with a specific verb and resource. This clearly distinguishes it from sibling tools like ncloud_sourcecommit_list_repos, ncloud_sourcecommit_edit_repo, and ncloud_sourcecommit_delete_repo.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description mentions use of dryRun=true to preview without creating, which is a useful usage hint. However, it does not explicitly compare against alternatives or provide when-not-to-use guidance, though the create operation is self-evident among the sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcecommit_delete_repo_by_idA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true, so the description need not repeat basic destructiveness. It adds value by specifying 'Permanently delete' and the requirement that 'confirm=true' must be set to execute, which is not obvious from annotations alone. This contextual disclosure helps the agent understand the irreversible nature and the safety gate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single compact sentence with a warning emoji, conveying the essential destructive nature and the confirmation requirement. Every element earns its place; no redundant filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive tool with two parameters, full schema coverage, and annotations indicating destructiveness and idempotency, the description covers the critical aspects: the operation, the target identifier, and the confirm gate. It does not delve into return values or edge cases, but those are not required given the simple operation and existing annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameter descriptions, including 'Repository ID to delete' and 'Must be true to actually execute the destructive operation.' The description's mention of 'by ID' and 'Set confirm=true' adds no new semantic value beyond the schema, so it earns the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Permanently delete a SourceCommit repository by ID' providing a specific verb, resource, and identifier method. The 'by ID' qualifier distinguishes it from sibling tools like ncloud_sourcecommit_delete_repo, which likely operates by name. The confirm=true instruction also clarifies the operation's semantics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to choose this tool over alternatives such as ncloud_sourcecommit_delete_repo or other deletion tools. It implies usage when the repository ID is known but lacks explicit exclusions or alternative guidance. The confirm=true tip is a usage instruction, but not about tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_create_projectA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation only indicates destructiveHint=false, which is consistent with a creation tool. The description adds the dryRun preview behavior, which is helpful, but it doesn't disclose other behavioral aspects such as potential side effects (e.g., resource creation costs, name uniqueness conflicts, or required permissions). For a mutating create operation, more transparency about consequences would be beneficial, but the dryRun note provides some safety context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: one sentence for the core purpose and a second sentence for the dryRun tip. Every word earns its place, with no fluff or redundant details. It is front-loaded with the primary action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (2 parameters, no output schema, no nested objects), the description provides sufficient context: it names the resource, states the creation action, and explains the preview capability. It doesn't cover every possible scenario (e.g., permissions prerequisites), but for a straightforward create operation, it is adequately complete. The schema fills in parameter details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers both parameters completely (100% coverage): 'name' includes format constraints and 'dryRun' is described as returning a preview without actually creating. The description's mention of dryRun=true adds no new semantics beyond what the schema already states, so it meets the baseline but does not elevate it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action: 'Create a new SourceDeploy deployment project.' This clearly distinguishes it from sibling tools such as ncloud_sourcedeploy_delete_project, ncloud_sourcedeploy_list_projects, and ncloud_sourcedeploy_create_stage, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear usage context for the tool: creating a SourceDeploy project. It also includes a practical guideline for a key alternative mode: 'Use dryRun=true to preview without creating.' While it doesn't explicitly mention alternatives like listing or deleting projects, the primary usage and the dryRun option are well communicated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_delete_stageA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Although annotations already declare destructiveHint=true and idempotentHint=true, the description adds the critical behavioral requirement that confirm=true must be set to execute the deletion. This goes beyond the annotations and is essential for safe invocation. No contradictions with annotations are present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, highly informative sentence with a warning emoji, front-loading the destructive nature. It contains no redundant words or filler, earning its place with actionable content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with strong annotations and full schema coverage, the description is mostly complete. It tells the agent what the tool does, the confirm requirement, and the resource being affected. It could mention irreversibility or absence of output, but the destructive warning largely covers this. No output schema exists, so return values don't need explanation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for all three parameters (confirm, stageId, projectId). The tool description does not add meaning beyond the schema; it only restates the confirm requirement. Baseline of 3 is appropriate since the schema carries the parameter documentation burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('Delete') and resource ('a deployment stage from a SourceDeploy project'), and it distinguishes itself from sibling tools like edit_stage, create_stage, and get_stage. The destructive warning and confirm requirement add clarity about the operation's nature.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage ('Delete a deployment stage') but does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. No reference to sibling tools or exclusions is provided, so the guidance is only implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_get_target_groupsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description's 'Get' verb aligns with a read-only operation. The description adds the scoping to an ASG, which is useful context, but doesn't disclose additional behavioral details like pagination or return format. Since annotations cover the safety profile, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence conveys the purpose without extraneous words. It is front-loaded and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, read-only annotation, no output schema), the description adequately states the operation's scope. However, it doesn't cover expected return value structure or edge cases, which would be helpful but not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the single parameter with a clear description: 'Auto Scaling group number'. The description reinforces its role by mentioning 'connected to an Auto Scaling group', but doesn't add novel semantic detail beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' and identifies the exact resource: 'load balancer target groups connected to an Auto Scaling group'. This clearly distinguishes it from sibling getters like ncloud_sourcedeploy_get_autoscaling_groups or ncloud_sourcedeploy_get_servers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case: when you need target groups associated with a specific ASG. It provides clear context but does not explicitly name alternatives or exclusions, so it falls short of full when/when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_list_projectsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the safe, non-mutating nature. The description adds the 'all' scope and optional name filter, which is useful, but it does not mention pagination behavior, response format, or any other behavioral details. Since the annotation covers the main safety aspect, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence: verb first, then resource, then optional filter. No redundant words or filler. It is optimally concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with all-optional parameters and a readOnlyHint annotation, the description adequately covers the purpose and the main filter. There is no output schema, but 'List all ... projects' implies a collection response. It is sufficiently complete for the agent 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% — each parameter (pageNo, pageSize, projectName) has a clear description in the schema. The tool description only restates 'name filter' for projectName and does not add additional meaning. Baseline 3 applies because the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and identifies the resource as 'SourceDeploy deployment projects', clearly distinguishing it from sibling tools like ncloud_sourcedeploy_list_stages or ncloud_sourcebuild_list_projects. It also mentions the optional name filter, which adds precision.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for read-only listing of SourceDeploy projects and indicates the optional filter. It does not explicitly state when not to use it or name alternatives, but the purpose is clear enough for a simple list operation. No exclusions are present.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_start_serverA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool is idempotent and non-destructive, so the safety profile is covered. The description adds a meaningful precondition (instances must be stopped) and indicates multiple instances are supported, but it does not describe response behavior or any additional side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded seven-word sentence with no filler or redundancy. Every word contributes to conveying the tool's action and target condition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter start action with robust annotations and no output schema, the description combined with the schema provides sufficient information for an agent to select and invoke the tool. It could mention return values or status updates, but the low complexity makes the current level acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the sole parameter serverInstanceNoList with type, minItems, and description. The description's 'one or more' reiterates the schema's minItems constraint and adds no new semantic detail beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Start' plus the resource 'server instances' and qualifies the target as 'stopped', which clearly distinguishes it from sibling tools like ncloud_stop_server, ncloud_reboot_server, and ncloud_terminate_server.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'stopped server instances' provides a clear precondition for when to use this tool, implying it is only for instances currently in a stopped state. It does not explicitly name alternatives or exclusion cases, but the context is unambiguous enough for correct selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_update_extended_enableA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description accurately states the primary effect but adds no extra behavioral context such as billing impact, propagation delay, or prerequisites beyond what annotations and schema provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence that is front-loaded with the action ('Enable') and contains no filler. Every word contributes to understanding the tool's purpose and scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple idempotent enable operation with fully documented required parameters and a non-destructive annotation, the description is adequately complete. It does not mention how to verify the result, but the sibling ncloud_get_extended_status can be inferred and no output schema is provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: cw_key is identified as product key and instanceIds as comma-separated server instance numbers. The description does not add further parameter meaning, but the schema is sufficient for selecting and invoking with correct values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Enable' with a clear resource 'Extended Metric collection' and target context 'instances in Cloud Insight'. It clearly differentiates from the sibling ncloud_update_extended_disable by indicating the enabling action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use it to enable extended metric collection for Cloud Insight instances. It does not explicitly mention alternatives or exclusions, but the counterpart disable tool is identifiable from the name, so no confusion arises.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_vodstation_get_channelA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, and the description's 'Get' aligns with that. However, the description adds little beyond the annotation—'detailed information' is vague and doesn't disclose what fields are returned or error behavior. It doesn't contradict annotations, so a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 10 words, front-loaded with the key verb and resource. No filler or redundancy; every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-detail tool with one well-documented parameter and a readOnly annotation, the description is sufficient. While there's no output schema, 'detailed information' conveys the return type. It doesn't enumerate fields, but that's acceptable for this simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: the channelId property includes a description and example format. The description adds no additional meaning beyond restating that it targets a specific channel. Baseline 3 is correct when the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get' with the resource 'detailed information about a specific VOD Station channel'. It clearly distinguishes from sibling tools like list_channels (for listing all channels) and create/delete/start/stop (for mutations), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: use this when you need details about a specific channel identified by channelId. It doesn't explicitly name alternatives or exclusions, but the sibling context (list_channels for a list) makes the use case clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_vodstation_list_channelsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds that the operation uses pagination, which is useful beyond the readOnlyHint annotation. However, it does not disclose return format, ordering, defaults, or other behavioral details, so it provides minimal extra context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the core purpose and includes the key capability (pagination). No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a simple list operation with only two optional pagination parameters, and the description plus annotations cover its safety profile. However, since there is no output schema, the description could have mentioned the return structure (e.g., channel list) to be fully complete, but the name and purpose make it largely inferable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents both parameters (pageNo and pageSizeNo) with descriptions and defaults, achieving 100% coverage. The description's mention of pagination adds little to what the schema already conveys, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('VOD Station streaming channels'), and clearly states scope ('all') and pagination, distinguishing it from sibling tools like ncloud_vodstation_get_channel.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies the tool is for listing all channels, which is a distinct context from the single-channel retrieval of get_channel. However, it does not explicitly name alternatives or exclude scenarios, so it falls short of a score 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_wms_get_monitorA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers the safety profile. The description adds that it returns detailed configuration, which is useful but doesn't disclose additional behavioral traits like required permissions or error conditions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the action and resource. No redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one parameter, read-only) and the description sufficiently conveys the return type (configuration) and the need for a specific scenario ID. However, without an output schema, more detail on the exact configuration fields returned could be helpful, though not essential for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single scenarioId parameter, and its description ('from ncloud_wms_list_monitors') adds valuable source context. The tool description itself doesn't elaborate on parameters, so baseline is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('detailed configuration of a specific WMS monitoring scenario'), clearly distinguishing it from sibling tools like ncloud_wms_list_monitors (listing) and ncloud_wms_get_results (retrieving results). It precisely states what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The tool description itself doesn't mention alternatives, but the parameter description in the schema ('Scenario ID from ncloud_wms_list_monitors') provides a clear prerequisite, implying that one should first list monitoring scenarios to obtain the ID. This gives clear context even though it doesn't explicitly state when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_wms_set_statusA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explains the serviceYn parameter's meaning (true=start, false=pause) but adds no extra behavioral context beyond what the annotations already convey (idempotent, non-destructive). It does not contradict the annotations, and for a simple toggle operation 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the action and parameter meaning. Zero wasted words or redundant phrases.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with full schema coverage and no output schema, the description is complete. It explains the core purpose and the key parameter semantics. Slight deduction for not mentioning any prerequisites or side effects of pausing, but given the simplicity this is minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the description repeats the serviceYn meaning already present in the schema. No additional parameter information is provided beyond what the schema already documents, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (start or pause) and the resource (WMS monitoring scenario), using a specific verb and resource. It also distinguishes this tool from sibling tools that fetch monitoring data or results by focusing on status changes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 the tool: to start or pause a WMS monitoring scenario. It doesn't explicitly mention alternatives or exclusions, but the action itself is unambiguous and the siblings are clearly different (e.g., get_monitor, get_results).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_cache_instanceA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the non-destructive preview behavior via dryRun, which adds value beyond the destructiveHint annotation. It clearly states that the tool creates an instance, and the dryRun hint provides an important safety behavior. It does not mention async behavior or billing, but the core create semantics are transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences. The first states the primary purpose with a clear verb and resource; the second adds a crucial safety tip. No filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 15-parameter create tool, the description is minimal. It gives the essential purpose and dryRun guidance, but does not explain return values (there is no output schema) or high-level configuration guidance (e.g., cluster mode). The schema covers individual parameters, but the description alone is borderline sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 mention dryRun, but the schema already thoroughly explains that parameter ('If true, returns a preview without actually creating the instance'). No additional parameter semantics are added beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific action ('Create') and a specific resource ('Cloud DB for Cache (Redis/Valkey) instance'), clearly distinguishing it from sibling instance creation tools for MySQL, Postgres, MongoDB, etc. It also highlights the unique dryRun preview feature.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: this is for creating a Cache (Redis/Valkey) instance. It provides a concrete usage tip (use dryRun=true to preview), which implies a safe workflow. It doesn't explicitly exclude alternative tools, but the resource specificity makes the intended use obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_snapshotA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare destructiveHint=false, which the description aligns with by describing creation. The dryRun feature is disclosed as a preview option, adding behavioral context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, front-loaded with the primary action and a useful tip. No filler or redundant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate for a simple create operation with full schema coverage, but lacks information about response format or asynchronous behavior (no output schema exists). It does not note prerequisites or potential delays, leaving some gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 100% description coverage for all four parameters, so the description adds no new semantic meaning. The dryRun mention in the description essentially repeats the schema's dryRun description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it creates a snapshot from a block storage instance, using a specific verb and resource. Distinguishes from sibling create_nas_snapshot by specifying block storage.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Description implies the use case (creating block storage snapshots) but does not explicitly name alternatives or exclusion criteria. The dryRun hint provides usage guidance for previewing, giving clear context for when to use the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_fabric_clusterA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations already marking destructiveHint and idempotentHint, the description adds valuable behavioral context by stating the operation is destructive, permanent, and gated by the confirm parameter. This goes beyond the annotation flags and clarifies the execution prerequisite.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one sentence, front-loaded with the destructive warning, and packs essential information (permanence, confirmation requirement) with zero wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a delete tool with simple parameters and no output schema, the description covers all necessary context: the action, the destructive/permanent nature, and the required confirm flag. It is fully sufficient for an agent 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both confirm and fabricClusterNo having clear descriptions. The description reiterates the confirm requirement but doesn't add new parameter meaning beyond what the schema already provides, keeping it at the high-coverage baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('delete') and the resource ('fabric cluster'), with the important qualifier 'permanently' indicating irreversibility. It is specific enough to distinguish from sibling tools by resource type, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear guidance on how to execute the operation ('Set confirm=true to execute'), which is an essential usage condition. It does not mention when to use this over other delete tools, but the resource-specific naming and the explicit confirmation requirement give sufficient context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_mssql_instanceA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructiveHint=true and idempotentHint=true, so the description's 'Destructive' label is redundant. However, it adds the crucial requirement that confirm=true must be set to execute, which is important behavioral context not in 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that leads with a warning and states the action and the required confirmation. Every word is purposeful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive delete operation, this description covers the essential points: what is deleted, permanence, and the required confirmation. The schema handles parameter details, and annotations handle safety flags, making the description complete for this simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema (100% coverage). The description merely restates the confirm requirement already present in the schema, adding no new meaning for either parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('delete') and identifies the exact resource ('Cloud DB for MSSQL instance'), distinguishing it from sibling tools like delete_mssql_server. The word 'permanently' adds clarity about the operation's scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for deleting MSSQL instances but provides no explicit alternatives or when-not-to-use guidance. The instruction to set confirm=true is a usage prerequisite, but it doesn't help choose between this and related delete tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_rule_groupA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructiveHint and idempotentHint, and the description adds context beyond those: it specifies that deletion is permanent and that associated monitoring alerts are stopped. This gives the agent a concrete understanding of consequences without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two sentences, with the critical warning front-loaded. Every word contributes value, and no unnecessary details are included.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive delete operation with only two parameters and no output schema, the description provides essential context: the warning, the permanence, and the impact on monitoring alerts. Combined with the annotations and schema (which cover the confirm behavior), the tool is fully understood for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents both parameters with clear descriptions (confirm and ruleGroupId), and the schema coverage is 100%. The tool description does not add parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Delete a Cloud Insight event rule group.' It specifies both the verb and the resource, distinguishing it from related tools like ncloud_update_rule_group or ncloud_copy_rule_group. The additional consequence 'stop all associated monitoring alerts' further clarifies the scope and impact.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description emphasizes the destructive nature with a warning, and the schema's confirm parameter implies a safety guideline, but it does not explicitly state when to use this tool versus alternatives like ncloud_delete_rule_group_by_id. No clear exclusions or alternative-selection guidance is provided, leaving some ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_drm_update_policyA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations (idempotentHint=true, destructiveHint=false) already establish that repeated updates are safe and non-destructive. The description adds valuable behavioral context not inferable from annotations: that sites actively using the policy must be disabled first, implying a risk of disruption or failure if this step is skipped. This is a meaningful disclosure beyond structured metadata, though it does not elaborate on failure modes or side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no filler. The first sentence states the core action, and the second delivers the most critical usage warning. It is perfectly front-loaded and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with six required parameters, a complex nested policy configuration, and no output schema, the description is minimal. It covers the purpose and the single most important prerequisite, but does not mention what the operation returns, how to verify success, or whether the update replaces or merges existing policy settings. The rich schema mitigates but does not eliminate this gap, so this is a bare-minimum score rather than a serious deficiency.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% description coverage for all six parameters, including nested drmPolicyConfig fields with detailed enums and constraints. The tool description adds no parameter-specific information, so the schema carries the full burden. Per the calibration baseline, when schema coverage is high, a score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource construction, 'Update a DRM policy,' which unambiguously identifies the tool's function. It clearly distinguishes itself from sibling tools like ncloud_drm_create_policy, ncloud_drm_delete_policy, and ncloud_drm_get_policy. The purpose is immediately understandable without needing to inspect the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an explicit operational prerequisite: 'Disable any site using this policy before updating.' This tells the agent the necessary precondition and implies when caution is needed. However, it does not mention alternative tools (e.g., creating a new policy instead of updating an existing one) or explicitly state when not to use this tool, so it falls short of the highest bar.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_export_mysql_backupA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true signals safe read behavior, and the description adds the destination (Object Storage) and the prerequisite lookup. However, it does not disclose whether the export is synchronous/asynchronous, whether the bucket must already exist, or what the response contains. This leaves the agent guessing about operational side effects beyond the source DB not being modified.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with zero filler. The first sentence states purpose, and the second provides the essential prerequisite. No repetition of schema details or annotations. This is concise and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 5 parameters, no output schema, and an annotation that could be misleading for an action that writes to Object Storage. The description does not explain what the tool returns, whether it triggers a long-running job, or if the destination bucket must be pre-created. Given the moderate complexity and missing return-value guidance, the description is adequate but has clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage, the parameter fields are already well explained. The description adds practical cross-tool guidance by telling the agent to use ncloud_list_mysql_backup_details to obtain the fileName, which helps understand where that value comes from. This slightly exceeds the baseline of 3 for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Export'), the resource ('Cloud DB for MySQL backup file'), and the destination ('Object Storage'), using a specific verb+resource structure. It distinguishes from sibling export tools (e.g., ncloud_export_mysql_log, ncloud_export_mongodb_backup) by naming the MySQL backup context, and from other MySQL tools by specifying export to Object Storage.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly points to ncloud_list_mysql_backup_details as the prerequisite for obtaining available file names, which is valuable guidance for using the tool correctly. While it doesn't mention when-not-to-use or alternative export tools, the resource-specific name makes the intended context clear. The absence of exclusions keeps it just short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_cache_image_productsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds context about the content being Redis/Valkey versions but does not disclose any additional behavioral traits such as pagination, response format, or rate limits. This is acceptable for a simple list operation but adds limited value beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that immediately states the action and resource, with no fluff or redundancy. The parenthetical adds valuable specificity about the Redis/Valkey versions.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one optional parameter, no output schema, and a read-only annotation, the description is sufficient. It tells the agent exactly what will be returned (image product codes) and the relevant service context. No further explanation of return values is needed since the description already indicates the output.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The sole parameter 'regionCode' is fully documented in the schema with its description 'Region code (KR, KRS)', so schema coverage is 100%. The tool description does not add any additional meaning about how the parameter affects results, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' and clearly identifies the resource as 'Cloud Cache image product codes' with the parenthetical '(Redis/Valkey versions)' providing necessary clarification. This distinguishes it from sibling tools like ncloud_get_cache_products or image product listings for other services.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states the function is to list available Cloud Cache image product codes, which provides clear context for when an agent would need this tool. However, it does not explicitly mention when not to use it or contrast with alternative sibling tools like ncloud_get_cache_products, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_cost_relation_code_listA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares the tool as read-only. The description adds value by explaining that the tool returns a mapping and enumerates the specific entities involved, giving useful context about the output beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action, and contains no filler. Every sentence contributes meaning: the first states what it does, the second explains its utility.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Since there is no output schema, the description provides a high-level indication of return content (the mapping), but it does not detail the response structure or explain how the optional filter parameters affect results. Adequate for a simple list tool, but leaves some gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all six parameters. The description itself adds no parameter-specific information, and thus the score remains at the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get cost relation code list') and resource, and specifies what the tool returns (mapping between contract types, product item kinds, rating types, metering types, demand types, and product categories). This differentiates it from sibling cost tools like ncloud_get_price_list or ncloud_get_product_category_list by focusing on code relationships rather than prices or categories.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Useful for understanding billing code relationships' provides a clear context for when to use this tool. However, it does not explicitly mention when not to use it or name alternative tools, which would warrant a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_current_regionA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, and the description adds that the tool returns both code and name, which is useful context. However, no additional behavioral traits (e.g., authentication, rate limits) are disclosed, though for a trivial getter this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the verb and object, and contains no unnecessary words. It is maximally concise while conveying the essential information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only getter with no output schema, the description fully covers what a user needs: it states what is retrieved ('code and name') and the scope ('currently active'). No further detail is required for this simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 with 100% coverage, so the description has no parameters to explain. Baseline 4 for 0-parameter tools is appropriate; the description adds nothing needed here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and identifies a distinct resource ('currently active Ncloud region code and name'). It clearly differentiates from sibling tools like ncloud_get_regions (which lists all regions) and ncloud_set_region (which changes the active region).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (when you need the current active region) but does not explicitly state alternatives or provide exclusion criteria. Given the simplicity of the tool, implied usage is adequate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_ids_event_detailA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already covers the safety profile, so the description adds value by noting the subscription constraint, which is a behavioral prerequisite. It does not describe the return format or potential errors, but the annotation lowers the bar. This additional context about access eligibility is meaningful beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences. It front-loads the action and resource, then adds the subscription constraint. Every sentence carries 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.

  Completeness3/5

  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 should ideally indicate what 'detailed information' includes. The description is adequate for a simple read operation with one well-defined parameter, but the response structure and any notable fields (e.g., event time, source IP) are left unspecified. This is a clear gap for a 'get detail' tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the parameter 'ticketId' is clearly described as 'The IDS event ticket ID to get details for'. The description adds no further parameter semantics, so the schema carries the full burden. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('IDS intrusion detection event'), clearly distinguishing it from list-type sibling tools like ncloud_list_ids_events. It also names the exact object (specific event) and the service (Security Monitoring), so the agent knows precisely what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states a clear eligibility requirement ('Only for users subscribed to the Security Monitoring service'), which guides when the tool can be used. It implies that this tool is for retrieving details of a specific event, contrasting with listing tools, but it does not explicitly name alternatives or exclude cases beyond the subscription requirement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_postgresql_target_vpcsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals this is a safe read operation. The description adds the context that it only returns VPCs eligible for PostgreSQL instance creation, which is useful, but does not describe return format or pagination. A baseline score of 3 is appropriate given annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the purpose without any filler. Every word adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a low-complexity list tool with one optional parameter, clear schema documentation, and a read-only annotation. The description sufficiently conveys what the tool does and when it would be used, making the context complete without needing to describe return values.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: regionCode is documented with valid values (KR, KRS) and a default. The description adds no additional parameter semantics, but the schema already fully explains the parameter, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('VPCs available for Cloud DB for PostgreSQL instance creation'), clearly distinguishing it from sibling tools like target_subnets or target_vpcs for other database services.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'available for Cloud DB for PostgreSQL instance creation' implies this should be used to fetch candidate VPCs before creating a PostgreSQL instance. It does not explicitly mention exclusions or name alternative tools, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_scaling_process_typesA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals a safe read operation, and the description's 'List' wording is consistent. The description adds the scoping detail 'for Auto Scaling Groups' but does not disclose additional behavioral traits such as return format, pagination, or any edge cases. This matches the annotation coverage without adding extra context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the action ('List') and specifies the resource and scope. Every word is necessary and there is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only list endpoint, the description completely conveys the tool's purpose and expected result. The absence of an output schema is not an issue because the description itself tells the agent what will be listed, and no additional context is required for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema coverage is 100% vacuously. The description adds no parameter-specific semantics, but the baseline for no-parameter tools is 4, and no compensation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' followed by the resource 'scaling process types' and a clear scope 'for Auto Scaling Groups'. This distinguishes it from related sibling tools like ncloud_get_adjustment_types and ncloud_suspend_processes, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is only implied: an agent would infer this is for retrieving available process types before managing them. No explicit when-to-use or alternative guidance is provided, though the simple list nature makes it reasonably obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_server_specsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint: true already declaring the read-only nature, the description adds beyond annotations by noting support for Gen2 XEN and Gen3 KVM, which implies the tool can show specs across different hypervisor generations. This is useful behavioral context not present in the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the main action, and no redundant words. Every sentence provides distinct information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is sufficient for a simple read-only listing tool with no output schema. However, given multiple sibling tools with similar names for other services, the description could have explicitly stated that this is for standard Cloud Servers to avoid ambiguity. Otherwise, it's complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining that serverImageNo should come from ncloud_get_server_images, which gives the agent an actionable way to populate that parameter beyond the schema's generic description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists available server specifications, which is a specific verb+resource. It also mentions Gen2 XEN/Gen3 KVM support, adding useful context. It does not explicitly distinguish from sibling tools like ncloud_nks_get_server_specs, but the name and context signal it's for standard servers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance to use serverImageNo from ncloud_get_server_images to filter compatible specs, which is a concrete cross-tool workflow. It doesn't mention when not to use this tool or alternatives, but the primary usage pattern is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_gtm_delete_policyA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint and idempotentHint. The description adds context beyond these: it clarifies the deletion is 'permanent' and that confirm=true is necessary. This goes beyond the structured annotations and helps the agent understand the irreversible nature and confirmation requirement without relying solely on the annotation flags.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and front-loaded with the critical warning. It conveys the action, permanence, and confirmation requirement in one sentence. No filler or redundant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter destructive operation with full schema coverage and no output schema, the description is complete. It states the action, permanence, and the confirmation requirement. No additional return-value explanation is needed, and the annotations cover the safety profile.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (both policyId and confirm have descriptions). The description reinforces the confirm parameter's role ('Set confirm=true to execute') but doesn't add new parameter-level meaning beyond what the schema already provides. Thus, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Permanently delete a Global Traffic Manager policy.' It uses a specific verb (delete) and resource (GTM policy), distinguishing it from sibling tools like create, update, or get. The destructive nature is explicitly flagged.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an important usage instruction: 'Set confirm=true to execute.' This implies the tool requires explicit confirmation for the destructive action. However, it doesn't explicitly mention when to use this tool vs alternatives (e.g., checking with get_policy_detail first or using update instead). The guidance is minimal but useful.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_cache_bucketsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this a safe read operation, and the description's 'List' aligns with that. No additional behavioral details (e.g., pagination, return format, or prerequisites) are provided, but with annotation coverage, this does not hurt usability.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that exactly states the tool's function and context. No wasted words or redundant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with one optional parameter and a clear purpose, the description fully covers what an agent needs to know. No output schema is needed, and the annotations provide safety context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the single parameter 'regionCode' with its description and optional nature (100% schema coverage). The description adds no parameter-specific information, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and identifies the resource ('Object Storage buckets') with a clear purpose ('available for Cloud DB for Cache backup export'). This distinguishes it from sibling bucket-list tools like ncloud_list_mysql_buckets or ncloud_hadoop_list_buckets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clearly implied by the purpose: use this tool when you need Object Storage buckets for Cloud DB for Cache backup export. It does not explicitly mention alternatives or exclusions, but the scope is specific enough to guide selection among many similar list tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_waf_eventsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the subscription requirement, which is useful contextual information, but does not disclose other behavioral details such as pagination defaults or error conditions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences deliver the core purpose and a key restriction with no filler. Information is front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given strong schema coverage and read-only annotation, the description sufficiently orients the agent for a list operation. It does not need to explain return values or filters because the schema covers those; the subscription caveat is a welcome addition.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 11 parameters are described in the schema (100% coverage), so the description need not repeat them. The description does not add any parameter-specific semantics beyond the schema, but none are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly identifies a specific operation: listing WAF security events from Security Monitoring. Expands WAF acronym and distinguishes from sibling event-list tools (AV, IDS, IPS, DDoS) through the WAF scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides a clear prerequisite (Security Monitoring subscription) and context that this is a read-only listing operation. Does not explicitly mention alternative tools for other event types, but the name and description imply the niche.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_abort_multipart_uploadA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the destructiveHint annotation by explicitly warning '⚠️ Destructive' and detailing what gets destroyed ('delete all uploaded parts'). It also introduces the safety requirement 'Set confirm=true to execute', which is critical behavioral context not present in the annotation alone.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, high-impact sentence that front-loads the destructive warning and clearly states the action and confirm requirement. No filler or redundant information; every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive action with 4 well-documented parameters and no output schema, the description covers the essential purpose, destructive effect, and confirmation gate. It lacks explicit references to related tools for obtaining uploadId, but this is not critical given the schema and name. Slight gap in usage context prevents a 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are already well-documented. The description reinforces the confirm parameter's necessity but does not add new meaning beyond the schema's existing descriptions for bucketName, objectName, uploadId, or confirm. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Abort a multipart upload and delete all uploaded parts.' This specifies the verb (abort), resource (multipart upload), and the effect (delete parts), distinguishing it from sibling operations like complete_multipart_upload or upload_part.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for cancelling an in-progress multipart upload, but does not explicitly contrast with alternatives (e.g., complete_multipart_upload) or provide when-to-use/when-not-to-use guidance. The name and warning make the primary use case clear, but no exclusions or alternatives are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_attach_block_storageA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the non-obvious polling behavior ('Automatically waits... polls until status is CREAT'), adding value beyond the annotations. It aligns with the idempotentHint and destructiveHint annotations, and no contradictions are present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the main action followed by a key behavioral note. No wasted words, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with annotations, the description covers purpose and the main behavioral nuance. It lacks details like timeout behavior or prerequisites, but these are not essential for the basic use case, so it is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Since schema description coverage is 100% and both parameters have clear descriptions in the schema, the tool description adds no additional parameter semantics. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Attach a block storage instance to a server.' It also adds the unique behavior of waiting for creation, distinguishing it from related tools like detach, create, or delete block storage.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 the tool (attaching a block storage to a server) and even specifies the automatic waiting behavior, which guides the user on expected execution. However, it does not explicitly mention alternatives or exclusions, hence not a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_delete_clusterA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint and idempotentHint. The description adds value by specifying the concrete consequence ('All data will be lost') and the mandatory confirm flag, which is not evident from the annotations alone. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: three short sentences with high information density. The warning emoji and front-loaded 'Destructive' immediately catch attention, and every clause (permanent deletion, data loss, confirm requirement) earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter delete operation with full schema coverage and appropriate annotations, the description covers the essential operational aspects: the destructive action, data-loss consequence, and the confirmation gate. A minor gap is not stating what happens when confirm=false, but the default 'false' and schema description imply a no-op.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers both parameters with descriptions (confirm defaulting to false, serviceGroupInstanceNo as required). The description reinforces the confirm requirement but does not add semantic detail beyond the schema, and with 100% schema coverage, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('delete') and the specific resource ('CDSS (Kafka) cluster'), and adds the critical qualifier 'permanently' with 'All data will be lost.' This distinguishes it from other delete tools such as ncloud_cdss_delete_config_group.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The destructive warning and the explicit 'Set confirm=true to execute' provide clear usage context, signaling that this is a high-risk operation requiring confirmation. However, it does not explicitly compare with alternative tools or state when not to use it, so it stops short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_get_cluster_detailA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description's 'Get detailed information' aligns with a read-only operation. The description adds no additional behavioral context beyond the annotation, such as response format or data scope, but no contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One concise sentence fully states the tool's purpose with no wasted words. It is appropriately front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple structure (one parameter, read-only annotation, no output schema), the description is sufficiently complete. It does not enumerate what 'detailed information' includes, but this is acceptable given the lack of output schema and the straightforward nature of a get-detail operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The parameter schema has 100% coverage with a clear description ('Cluster instance number from cluster list'). The main description reinforces the parameter's meaning by calling out 'specific cluster'. This adds value beyond the schema by indicating the source of the identifier.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('CDSS (Kafka) cluster'), clearly indicating this tool fetches details for one specific cluster. It distinguishes itself from siblings like ncloud_cdss_list_clusters (list) and ncloud_cdss_get_cluster_status (status) by focusing on detailed information.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'specific CDSS (Kafka) cluster' implies use when you need details of a particular cluster rather than a list or status. However, it does not explicitly name alternative tools like get_cluster_status or list_clusters, so exclusions are not stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_change_block_storageA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (idempotentHint=true, destructiveHint=false) are supplemented with useful behavioral context: generation support and the prerequisite that attached storage must have the server stopped to resize. No contradiction with annotations, but no mention of reversibility or failure modes.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences: purpose first, then platform support, then a critical prerequisite. No redundant wording; every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With full schema coverage and annotations, the description adds platform support and a key prerequisite. It lacks explicit guidance on when to choose this over ncloud_change_block_storage_size, and does not describe return values (though no output schema exists), but overall it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has 100% coverage with detailed parameter descriptions (e.g., blockStorageSize range, increment, and minimum). The description's 'resize volume and/or update name/description' maps to parameters but adds no additional parameter-level semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific verb and resource: 'Change block storage instance' with parenthetical details 'resize volume and/or update name/description'. This distinguishes it from siblings like ncloud_change_block_storage_size and ncloud_set_block_storage_protection.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear operational context: supports Gen2 (XEN) and Gen3 (KVM), and requires server to be stopped for attached storage resize. However, it does not explicitly mention alternatives or exclusions, such as using ncloud_change_block_storage_size for size-only changes.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_bucketA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, but the description adds meaningful context: 'Permanently delete', the empty-bucket requirement, and the confirm=true safeguard. The warning emoji also reinforces the destructive nature. This goes beyond the structured annotation without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, tightly-packed sentence with no waste. It front-loads the destructive warning, states the action, and gives both the precondition and the required confirmation flag. Every element earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with two parameters, no output schema, and strong annotations, the description covers the essential aspects: purpose, precondition, and confirmation mechanism. It could mention error behavior if the bucket is not empty, but it's already sufficient for the agent to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both confirm and bucketName are fully described in the input schema. The description adds a small reinforcing note about confirm=true, but most parameter meaning is already in the schema. 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly what the tool does: 'Permanently delete an Object Storage bucket.' The verb 'delete' and specific resource 'Object Storage bucket' clearly distinguish it from other deletion tools like ncloud_delete_object or ncloud_delete_multiple_objects. It also adds a crucial precondition (bucket must be empty).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear conditions for use: the bucket must be empty and confirm=true must be set. This effectively tells the agent when it's appropriate to invoke the tool and what's required. It doesn't explicitly mention alternatives or when not to use, but the context is clear given the tool name and sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_cache_instanceA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful behavioral context beyond the destructiveHint annotation by specifying 'permanently delete' and explicitly requiring 'Set confirm=true to execute.' This informs the agent of both the irreversibility and the needed confirmation, which is valuable for a destructive action. It does not contradict any annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, tightly crafted sentence that front-loads the destructive warning and clearly states the action and requirement. Every word earns its place: warning, permanence, resource type, and the execution prerequisite. No wasted text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (2 parameters, no output schema) and the strong annotations, the description sufficiently covers the core context: what is deleted, that it's permanent, and that confirmation is required. It does not document secondary effects or prerequisites, but for a straightforward delete operation, the provided information is complete enough for an agent to act correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters described, so the baseline is 3. The description adds value by explicitly stating 'Set confirm=true to execute,' which reinforces the confirm parameter's critical role in enabling the destructive operation. This explanation improves the agent's understanding of how to correctly invoke the tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Permanently delete a Cloud DB for Cache (Redis/Valkey) instance.' The verb 'delete' is specific, the resource type is explicit, and the 'permanently' qualifier distinguishes it from other cache-related operations. It clearly differentiates from sibling tools by narrowing scope to Cache instances.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys when to use this tool—when you want to permanently delete a Cache instance—but it does not explicitly mention alternatives or when-not-to-use scenarios. While the context is clear, it lacks explicit exclusionary guidance or references to alternative tools for similar operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_deny_allow_groupA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint and idempotentHint. The description adds the permanence of deletion and the confirm=true safety mechanism, providing valuable behavioral context beyond the annotations. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a warning icon and explicit instruction. Every word adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with full schema coverage and annotations, the description sufficiently conveys the action, destructive nature, and confirmation requirement. It could mention prerequisites (e.g., disassociating the group) but this is not critical for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters have descriptions. The description's 'Set confirm=true to execute' mirrors the confirm parameter's schema description, adding no new parameter semantics beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Permanently delete a Network ACL Deny-Allow Group' with a specific verb and resource. It distinguishes itself from sibling tools like create, get, or set operations on deny-allow groups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context that this is a destructive operation and instructs the user to set confirm=true to execute. However, it does not explicitly mention alternatives or when not to use this tool compared to other deny-allow group operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_groupA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (destructiveHint=true, idempotentHint=true), the description adds critical behaviors: the deletion is permanent and requires confirm=true to execute. This explains the safety mechanism and warns of irreversibility. It does not contradict the annotations and provides extra context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that includes a warning emoji, the action, and the critical confirm gate. Every word earns its place, and it is front-loaded with the destructive warning, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with two parameters and no output schema, the description covers the essential information: the action is destructive, permanent, and requires confirmation. It does not describe prerequisites (e.g., whether the group must be empty) or return values, but given the low complexity and the annotations, the description is sufficiently complete for an agent to use it safely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions (groupId and confirm). The description reinforces the confirm parameter's purpose ('Set confirm=true to execute') but does not add new semantics beyond what the schema already states. Thus baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Permanently delete an IAM group.' The verb 'delete' with the specific resource 'IAM group' distinguishes it from sibling tools like ncloud_create_group or ncloud_attach_policy_to_group. It also includes the critical confirm requirement, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides context for when to use the tool (to permanently delete an IAM group) and explicitly states the prerequisite of setting confirm=true to execute. It does not mention alternatives or exclusions, but the resource type is clearly named, so an agent can infer when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_login_keysA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (destructiveHint, idempotentHint), the description adds the crucial behavioral detail that deletion is permanent and requires setting `confirm=true`, a non-obvious safeguard not conveyed by the annotations. This adds meaningful context without contradicting 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with a clear warning and a concise action statement, followed by the essential execution requirement. Every sentence earns its place with no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with two well-documented parameters, relevant annotations, and no output schema, the description sufficiently covers the destructive nature, the confirm gate, and the resource scope. It does not elaborate on side effects or prerequisites, but none are essential for this operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both `confirm` and `keyNameList` already have descriptive schema text. The tool description only repeats the confirm requirement without additional parameter-level insights, so it adds no semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Permanently delete one or more login keys.' This uses a specific verb ('delete'), resource ('login keys'), and scope ('one or more'), which distinguishes it from sibling tools like ncloud_list_login_keys, ncloud_create_login_key, and ncloud_import_login_key.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for usage: it is a destructive operation requiring `confirm=true` to execute. It implies when to use (when deleting login keys) but does not explicitly reference alternatives or exclusion scenarios, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_maintenanceA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the tool as destructive and idempotent. The description adds the crucial behavioral requirement that confirm=true must be set to execute, which is not covered by the annotations. The destructive warning is redundant but consistent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with a warning prefix, front-loading the destructive nature. Every word contributes to the core meaning, with no unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward delete tool with two parameters, full schema coverage, and relevant annotations, the description captures the essential behavior and confirmation requirement. It omits peripheral details like permissions and return values, but those are not critical given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides full descriptions for both parameters (100% coverage). The description's mention of confirm=true essentially restates the schema's own description, adding no new semantic meaning beyond what is already structured.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Delete a planned maintenance schedule from Cloud Insight', using a specific verb and resource. It distinguishes itself from sibling tools like ncloud_create_maintenance, ncloud_update_maintenance, and ncloud_list_maintenances.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 the tool (to delete a planned maintenance schedule), and the confirm=true note offers an operational guideline. It does not explicitly mention alternatives or exclusions, but the delete scope is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_member_server_imagesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the confirm gate and explicitly warns 'Destructive', which goes beyond the destructiveHint annotation by explaining the execution requirement. It does not contradict the idempotentHint annotation and reinforces the destructive nature clearly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with the warning and key instruction front-loaded. Every word earns its place, making it highly efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with a confirm flag, the description covers the essential context: destructive potential, execution requirement, and target resource. It lacks details on return values or side effects, but given the absence of an output schema and the straightforward nature, the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for both parameters (confirm and memberServerImageInstanceNoList), covering 100% of the parameters. The description's mention of 'Set confirm=true' mirrors the schema's confirm description without adding new semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Delete') on a specific resource ('member server image instances'), including the batch nature ('one or more'). This distinguishes it from similar sibling tools like ncloud_delete_server_images, which targets a different resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides critical usage guidance by stating that confirm=true is required to execute the destructive operation. This is an explicit operational prerequisite. However, it does not explicitly discuss when to use this tool versus alternatives beyond the resource type.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_mongodb_instanceA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds behavioral context beyond those flags: the deletion is permanent and requires confirm=true to execute. This enhances understanding of the tool's impact without contradicting 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a warning icon, stating the destructive action and the confirmation requirement. Every word earns its place, and there is no redundant filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with only two parameters and annotations covering destructive/idempotent behavior, the description covers the essential context: permanent deletion and the need for confirm=true. It does not explain return values or async behavior, but this is not a significant gap given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with meaningful descriptions for both parameters. The description merely reiterates the confirm parameter's role ('Set confirm=true to execute') without adding new information or clarifying nuances beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Permanently delete') and the specific resource ('Cloud DB for MongoDB instance'), which distinguishes it from sibling deletion tools for other resources. The warning and confirmation requirement further clarify the tool's destructive scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when a MongoDB instance needs to be deleted and provides the key execution guideline ('Set confirm=true to execute'). It does not mention explicit exclusions or alternatives, but the resource-specific naming makes the usage context clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_mssql_serverA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint and idempotentHint, but the description adds value by warning with '⚠️ Destructive' and explicitly stating 'Set confirm=true to execute.' This reveals the safety gate beyond annotation data. It does not contradict annotations and adds useful context about the deletion's destructive nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with a warning emoji effectively communicates the destructive action and confirmation requirement. No wasted words; every part earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with two parameters, the description adequately covers the destructive nature, the slave scope, and the confirm gate. Annotations provide the safety profile, and no output schema is present, so return-value details are not required. It is complete enough for an agent to select and invoke the tool correctly, though it could mention irreversibility explicitly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters, and the schema already describes the confirm requirement ('Must be true to actually execute the destructive operation'). The description's phrase 'Set confirm=true to execute' merely repeats schema info, adding no new meaning. The baseline of 3 is appropriate since the schema carries the parameter documentation burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action: 'Delete a Slave server instance from a Cloud DB for MSSQL cluster.' It uses a specific verb and resource, and the 'Slave' qualifier distinguishes it from sibling tools like ncloud_delete_mssql_instance that delete the entire instance.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for deleting a slave server instance and explicitly mentions the confirm requirement for execution. However, it does not explicitly state when not to use this tool or compare it to alternatives like deleting the whole MSSQL instance. The scope is clear enough for correct selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_multiple_objectsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint=true and idempotentHint=true, and the description adds the critical safeguard: 'Set confirm=true to execute'. This goes beyond the structured hints, informing the agent that a confirmation flag gates execution. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the warning symbol, and contains zero filler. Every word adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the annotations cover destructive/idempotent behavior and the schema documents all parameters, the description provides adequate context for a bulk delete tool. It doesn't describe return values, but no output schema exists, and the core safety and usage details are present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all three parameters with descriptions, including the confirm parameter's explicit purpose. The description's mention of 'Set confirm=true' reinforces the existing schema documentation but adds no new meaning beyond it. With 100% schema coverage, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Delete' with the resource 'multiple objects from an Object Storage bucket' and scopes it 'in a single request'. This clearly distinguishes it from sibling tools like ncloud_delete_object (single object) and ncloud_delete_bucket (whole bucket).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'in a single request' signals the batch deletion use case, and the sibling tools list includes ncloud_delete_object for singular deletes, implying the contrast. However, it does not explicitly state when-not to use it or name alternatives, leaving some inference required.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_mysql_usersA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true, setting a solid baseline. The description adds a valuable behavioral detail: the operation only executes when confirm=true, which is not captured in the annotations. The warning emoji also reinforces the destructive nature. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence. It front-loads the critical destructive warning, then states the action and the key execution requirement. Every word earns its place, with no redundant or irrelevant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity destructive operation with good annotations and fully described schema parameters, the description is adequate. It covers what is deleted and how to execute. It could theoretically mention consequences (e.g., irreversible loss) or prerequisites, but the destructive hint and confirm flag already convey the essential safety context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are already fully documented. The description's mention of 'confirm=true' adds no new information beyond the schema's confirm parameter description. It doesn't elaborate on the user list or instance number further, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (delete), the resource (users from a Cloud DB for MySQL instance), and distinguishes it from sibling tools like ncloud_delete_mysql_databases or ncloud_delete_mysql_instance. The tool name and description align perfectly, leaving no ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use the tool (to delete MySQL users) and includes an essential usage instruction: 'Set confirm=true to execute.' It doesn't explicitly mention alternatives or exclusions, but for this straightforward destructive operation, the context is sufficient to guide an agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_nat_gatewayA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description adds that the deletion is permanent and requires confirm=true to execute, providing useful behavioral context beyond the annotation. This does not contradict any annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a warning emoji, effectively communicating the destructive nature and confirmation requirement without any waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple deletion operation, the schema documents all parameters, and annotations cover the safety profile. The description adds permanence and confirmation context. No output schema is needed, and the tool definition is sufficiently complete for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of parameters, including confirm and returnPublicIpInstance. The description's mention of 'confirm=true' mirrors the schema description, adding no new information. Baseline of 3 applies since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'delete' and resource 'NAT Gateway instance', with 'Permanently' emphasizing the irreversible nature. This distinguishes it from sibling tools like create_nat_gateway or set_nat_gateway_description.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 (to permanently remove a NAT Gateway) and the requirement to set confirm=true, but it does not explicitly name alternatives or exclusion conditions. The context is clear enough that no confusion with sibling tools arises.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_network_interfaceA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds value by emphasizing permanence ('Permanently delete') and revealing the confirm=true guardrail, which is critical behavioral context beyond the annotations. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, compact sentence with the destructive warning front-loaded using the ⚠️ symbol. Every element serves a purpose: it communicates the resource, the action, the permanence, and the required confirmation. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple two-parameter destructive tool with no output schema. The description, combined with annotations and schema, covers the essential context: what is deleted, permanence, and the confirm flag requirement. It could potentially mention side effects like what happens to associated resources, but that is not necessary for such a focused delete operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters (confirm and networkInterfaceNo) already well-documented in the input schema. The description reinforces the confirm parameter's purpose but does not add meaning beyond what the schema provides, so a baseline score is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Permanently delete a network interface.' This is a specific verb+resource combination that distinguishes it from sibling operations like create, attach, or detach network interfaces. The addition of 'Set confirm=true to execute' also clarifies the required execution guard.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates this is for deleting a network interface and implies the usage context through the destructive warning and confirm requirement. It does not explicitly mention alternatives or when-not-to-use scenarios, but the clear delete semantics provide sufficient context for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_pipelineA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint=true and idempotentHint=true, so the description doesn't need to restate those. It adds value by noting the action is 'Permanently delete' (irreversibility) and the confirm=true guardrail, which is essential behavior not captured in annotations. This is sufficient for an agent to understand the safety requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no filler. The warning emoji and word 'Destructive' front-load the critical safety context, followed by the action and the required confirmation flag. Every word earns its place, making it highly efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive delete operation with only two parameters and no output schema, the description is adequately complete. It communicates the permanent effect, the confirmation mechanism, and the resource type. It could mention how to obtain the projectId (e.g., via list_pipelines) or state the expected return, but these are minor gaps given the annotations and schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters ('projectId' and 'confirm') already described clearly. The description's mention of 'Set confirm=true to execute' is redundant with the schema's confirm description, adding no new semantic information. Therefore it earns the baseline score for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Permanently delete') and the resource ('a SourcePipeline pipeline'), making the tool's purpose unambiguous. It also distinguishes itself from sibling pipeline tools (e.g., create, update, run, cancel) by being the delete operation. The mention of 'confirm=true' adds a critical execution detail without blurring the core purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case: when you need to permanently remove a SourcePipeline pipeline. It clearly states the destructive nature and the required confirm flag, giving context for when to invoke it. However, it does not explicitly mention alternatives or when not to use it (e.g., canceling a running pipeline vs. deleting a definition), but the intent is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_placement_groupA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare destructiveHint: true and idempotentHint: true, so the description's '⚠️ Destructive' label repeats that. However, it adds behavioral context by stating 'permanently' and explicitly requiring the confirm flag to be set to true for execution, which is a critical safety guardrail. The description does not contradict the annotations and adds the confirm requirement on top of the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long and immediately conveys the core action and safety condition. The warning emoji and 'Destructive' label are efficient and the confirm instruction is direct. No unnecessary words are used.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple nature of the tool (two parameters, no output schema), the description covers the essential action and the critical confirm guardrail. It does not mention any prerequisites or side effects (e.g., whether the placement group must be empty), but the presence of annotations and schema coverage mitigates the need for more detail. Overall, it is sufficiently complete for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for both parameters (confirm and placementGroupNo), covering 100% of parameters. The description adds no additional parameter semantics beyond restating the confirm requirement, so the parameters are adequately documented but not enhanced.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Permanently delete a placement group.' The verb 'delete' and object 'placement group' are specific, and the warning icon distinguishes it as a destructive operation. It is unambiguous and differentiates well from sibling tools like ncloud_remove_placement_group_server, which removes servers rather than deleting the group.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 the tool (to permanently delete a placement group) and gives an explicit execution requirement: 'Set confirm=true to execute.' It does not, however, explicitly mention alternatives or exclusions, such as noting that removing a server from a group uses a different tool. The destructive nature is highlighted, which serves as a cautionary guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_postgresql_instanceA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds 'Permanently' and the confirmation requirement, offering context about irreversibility and a safety guardrail. It doesn't contradict the annotations and provides useful behavioral transparency beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a warning emoji. Every word earns its place, and the critical confirmation note is included without any waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter destructive operation with annotations and no output schema, the description is sufficiently complete. It covers the operation's purpose, irreversibility, and the confirm requirement. It doesn't explain return values, but that is not necessary given the lack of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 reinforces that confirm must be true to execute, which adds slight meaning beyond the schema, but it doesn't provide deeper parameter semantics (e.g., format, examples, or constraints) for cloudPostgresqlInstanceNo.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'delete' and resource 'Cloud DB for PostgreSQL instance', clearly distinguishing it from sibling tools like ncloud_delete_postgresql_read_replica or ncloud_delete_postgresql_databases. The scope is unambiguous and immediately actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly states the destructive nature and the requirement to set confirm=true to execute, which is key usage guidance. However, it doesn't explicitly contrast with alternative delete tools for PostgreSQL components, such as read replicas or databases, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_product_schemaA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint and idempotentHint, and the description reinforces this with a '⚠️ Destructive' warning. It adds behavioral value by disclosing the safety guard: the operation only executes when confirm=true.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single front-loaded sentence that covers the destructive nature, target resource, and required confirm flag. 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low parameter complexity, full schema coverage, and annotations, the description is nearly complete for a simple destructive delete operation. It covers what is deleted, the destructive implication, and the execution requirement, though it does not mention irreversibility explicitly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes all three parameters with clear definitions, including the confirm default false. The description adds marginal meaning by emphasizing confirm=true, but mostly duplicates schema content.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action (delete), the resource (user-defined custom schema from Cloud Insight), and the context (Cloud Insight). It is distinct from sibling tools like get_product_schema, create_custom_schema, and update_product_schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by marking the operation as destructive and explicitly instructing that confirm=true is required to execute. It does not enumerate alternatives, but the delete-only scope makes this unnecessary.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_public_ipA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description reinforces this with a warning. It adds important behavioral context: the confirm parameter must be true to actually execute, preventing accidental deletions. This goes beyond the structured annotation information.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the critical warning and action. It includes no filler and is immediately scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with annotations covering destructive and idempotent behavior, the description is sufficient. It explains the resource and the confirmation requirement. The lack of an output schema is acceptable given the straightforward nature of the operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes both parameters with 100% coverage. The description reiterates the confirm parameter's requirement ('Set confirm=true to execute') but does not add additional semantic value beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Delete a public IP instance.' It uses a specific verb and resource, distinguishing it from other delete tools and making the tool's purpose immediately obvious.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on how to use the tool ('Set confirm=true to execute'), which is essential for safe execution. It implicitly conveys when to use this tool (to delete a public IP) without mentioning alternatives, but the instruction is explicit enough for an agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_roleA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (destructiveHint=true), the description adds critical behavioral detail: the operation is 'permanently' destructive and requires explicit confirmation to execute. This enhances the agent's understanding of consequences and safeguards.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence conveys the destructive nature, the target resource, and the execution requirement. Every word earns its place, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation, the description covers purpose, parameter requirement, and safety warning. It does not mention potential side effects on dependent resources, but these are not explicitly requested and the annotation already flags destructiveness, making it sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for both parameters (roleNo and confirm), covering 100% of parameter semantics. The description's mention of 'confirm=true' duplicates the schema's explanation without adding new meaning, so it stays at the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Permanently delete') and the resource ('IAM role'), making it unambiguous. It also distinguishes itself from sibling tools like ncloud_create_role and ncloud_list_roles by specifying deletion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by warning 'Destructive' and requiring 'confirm=true to execute'. It lacks explicit alternatives or when-not-to-use guidance, but the context is sufficient for an agent to know this is the deletion tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_detach_policy_from_groupA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (destructiveHint=true, idempotentHint=true), the description adds the critical behavior that confirm must be set to true for execution, acting as a safety guard. The ⚠️ Destructive label also reinforces the destructive nature, providing useful context beyond the structured annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise—two sentences that deliver the key warning and the necessary execution flag. It is front-loaded with the destructive warning and contains no redundant words, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple detach operation with no output schema, the description is sufficiently complete. It covers the action, the destructive nature, and the confirm requirement. It does not explain return values or prerequisites, but these are unnecessary given the simplicity and schema coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description covers 100% of parameters, so the baseline is 3. The description reiterates the confirm parameter's purpose but does not add new meaning beyond the schema's existing descriptions for groupId and policyId. It provides minimal added value for parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Remove an IAM policy from a group.' It uses a specific verb and resource, and the tool name aligns perfectly. It is easily distinguished from siblings like attach_policy_to_group or detach_policy_from_sub_account by naming the exact operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by stating the operational requirement 'Set confirm=true to execute,' which is essential for safe usage. It does not explicitly mention alternatives or when-not-to-use scenarios, but the tool name and existing sibling structure make the use case obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_detach_policy_from_sub_accountA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly flags the operation as destructive and adds a critical behavioral detail—the need to set confirm=true to execute. This goes beyond the annotations (destructiveHint: true, idempotentHint: true) by explaining the confirmation mechanism, which is essential for safe invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence with a clear warning prefix. It conveys the essential information (destructive, action, confirm requirement) without unnecessary words, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive tool with 3 parameters (no output schema), the description covers the core purpose and the critical confirm guardrail. It could mention potential side effects of detaching a policy, but given the schema covers all parameters, the description is sufficiently complete for this operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for all three parameters (confirm, policyId, subAccountId) with 100% coverage. The description itself does not add parameter details beyond referencing confirm=true, which is already documented in the schema. Baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Remove an IAM policy from a sub account') with a specific verb (remove), resource (IAM policy), and target (sub account). This directly distinguishes it from siblings like ncloud_detach_policy_from_group and ncloud_attach_policy_to_sub_account.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use this tool: to remove an IAM policy from a sub account. It does not explicitly mention alternatives or exclusions, but the wording makes the scope unambiguous relative to sibling tools that handle groups or attachments.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_disable_flow_logA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide idempotentHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral detail by stating that capturing of network traffic logs stops, which goes beyond the annotations and helps the agent understand the effect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the action, and contains no redundant or filler content. Every word adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter operation with idempotency and non-destructive annotations, the description adequately covers purpose and effect. There is no output schema, but the operation is straightforward enough that this is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the only parameter, networkInterfaceNo, with 100% coverage. The description does not add additional parameter semantics beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Disable') and resource ('FlowLog on a network interface'), clearly stating what the tool does. It also distinguishes from the sibling 'enable_flow_log' tool by specifying the opposite action and adding the effect 'Stops capturing network traffic logs.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates when to use the tool: when you need to disable FlowLog on a network interface. It does not explicitly mention alternatives or exclusions, but the context is clear and the sibling enable tool is obvious from naming.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_dns_delete_recordsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as destructive and idempotent, so the description's 'Destructive' and 'permanently removes' are somewhat redundant. However, it adds critical behavioral context: 'Set confirm=true to execute.' This reveals a safety mechanism (confirmation flag) not present in the annotations, which is valuable for correct invocation. No contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences, front-loaded with the destructive warning. It efficiently conveys the action, consequences, and the confirmation requirement. While there is slight redundancy between 'Destructive' and 'permanently removes,' every sentence earns its place—no filler or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with no output schema, the description is nearly complete. It covers what is deleted, the permanent nature, and the confirm=true requirement. It could explicitly state what happens when confirm is false (e.g., no-op), but the implication is clear. A minor improvement would be to mention the default, but the schema handles that.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, with clear descriptions for domainId, recordIds, and confirm. The description adds no extra parameter-level meaning beyond what the schema already provides (e.g., 'specified records' maps to recordIds, but the schema already says that). Baseline 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action: 'Delete DNS records from a Global DNS domain.' This uses a specific verb (delete) and resource (DNS records), and distinguishes it from sibling tools like create, update, or list records. The addition of 'permanently removes' and the confirmation requirement reinforces its distinct destructive purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you need to remove DNS records. It states 'Delete' and 'permanently removes,' which is unambiguous. However, it does not explicitly name alternatives (like update_records for modifying), so it falls short of a 5. Still, the context is clear and there are no misleading exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_flush_cache_serverA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already include destructiveHint=true, so the baseline safety signal is present. The description adds valuable detail beyond that: 'Permanently deletes ALL data' emphasizes irreversibility, and the confirm=true guard explains the required safety mechanism. This enriches the agent's understanding of the operation's side effects without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence. It begins with a warning symbol and the word 'Destructive', immediately conveying the critical safety concern. Every phrase ('Permanently deletes ALL data', 'FlushAll', 'Set confirm=true') adds necessary information with zero wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive operation with a guard, the description covers the essential behavior: what it does (deletes all data), the severity (permanent), and the execution requirement (confirm=true). With no output schema, not describing return values is acceptable. The tool is simple enough that this description is adequately complete, though could mention response or failure modes.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both parameters have clear descriptions (confirm: 'Must be true to actually execute the destructive operation'; cloudCacheServerInstanceNo: 'Cloud Cache server instance number to flush'). The tool description essentially restates the confirm requirement, adding no new semantic information. Baseline of 3 is appropriate given the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Permanently deletes ALL data from a Cloud Cache server (FlushAll)' uses a specific verb (deletes), names the resource (Cloud Cache server), and clarifies scope (ALL data, FlushAll). This clearly distinguishes it from other cache-related tools in the sibling list, which generally perform create/read/update operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by warning 'Destructive' and stating 'Set confirm=true to execute.' This tells the agent when to use the tool (and when to be cautious), but it does not explicitly name alternatives or exclusions. Still, the context is strong enough to guide proper invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_functions_delete_actionA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral context beyond the annotations by emphasizing 'Permanently' and specifying 'Set confirm=true to execute.' This discloses the confirmation requirement and irreversibility, which is valuable for an agent deciding to invoke the tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is just two sentences, front-loaded with the destructive warning and a clear verb. Every word earns its place without redundancy or digression.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive delete operation, the combination of annotations (destructiveHint, idempotentHint) and full schema coverage provides sufficient context. The description covers the critical confirm gate. It doesn't elaborate on return values, but that is not essential for this type of operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for all parameters. The description mentions confirm, but the schema already explains that confirm must be true to execute. Thus, the description adds little meaning beyond the structured parameter definitions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action: 'Permanently delete a Cloud Functions action.' This uses a precise verb and resource, distinguishing it from sibling tools like ncloud_functions_create_action or ncloud_functions_list_actions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: it is destructive and requires confirm=true to execute. While it doesn't explicitly mention alternatives or exclusions, the purpose is unambiguous for deletion tasks, and the confirm=true instruction provides practical usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_functions_get_activationsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers safety, and the description adds the 1-month retention window, which is valuable behavioral context. It also specifies the 'all actions' scope, which isn't present in the schema or annotation. No contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single clear sentence, front-loaded with the action and resource, and no unnecessary wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list operation with a full input schema and good annotations, the description covers the key aspects: scope, time window, and read-only nature. It doesn't describe output format or pagination behavior, but those are standard for such tools and not essential given the schema and annotation coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers all five parameters with descriptions, so schema coverage is 100%. The description adds meaning by indicating a default time window (last 1 month) that the start/end parameters likely filter around, enriching the parameter context beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's function: retrieving all activation history across all actions, with an explicit time scope of the last month. This distinguishes it from sibling tools like ncloud_functions_get_action_activations which target individual actions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for a broad, cross-action activation log but doesn't explicitly state when to use this tool over sibling alternatives like the action-specific or trigger-specific activation tools. There's no exclusion guidance, but the 'all actions' scope provides a clear implied context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_adjustment_typesA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates this is a safe read operation. The description adds the context that it returns 'codes' rather than detailed objects. It does not disclose any additional behavioral traits such as pagination or authentication requirements, but with a simple zero-parameter list tool, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the action and resource. It contains no filler or redundant information, earning a perfect score for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity—zero parameters, no output schema, and a straightforward list operation—the description is nearly complete. It could have explicitly stated the return format (e.g., an array of code strings), but the purpose is clear enough for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there are no parameter semantics to clarify. Per the baseline for 0-parameter tools, a score of 4 is appropriate. The description correctly omits any parameter details since none exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The verb 'List' and resource 'adjustment type codes' are specific and unambiguous. The phrase 'for Auto Scaling policy configuration' clearly scopes the tool to a particular use case, distinguishing it from related tools like ncloud_get_scaling_process_types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 one needs adjustment type codes to configure Auto Scaling policies. It provides clear contextual guidance, though it does not explicitly mention alternatives or when not to use it. Given the uniqueness of the tool, this is adequate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_contract_demand_cost_listA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, and the description adds useful behavioral context beyond that: it specifies the max 3-month range limitation and what the returned list includes (usage, pricing, discounts). It does not elaborate on pagination defaults or output structure, but the safety profile is covered by annotations, so the extra period/return details are sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the verb and resource, then adds return details and the period limit. No redundancy or filler; each sentence contributes actionable information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with 11 parameters and no output schema, the description gives the essential context: contract-level scoping, period limitation, and output categories. It does not describe pagination defaults or full output structure, but the schema covers parameter details, and the description suffices for understanding the tool's role. Slight gap on differentiating from similar cost-list siblings, but that is not critical for completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters (startMonth, endMonth, pageNo, etc.) have descriptions in the schema. The tool description does not add any additional parameter-specific meaning; it only references the period constraint already present in the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets a 'contract-level billing cost list' with a specific verb and resource scope. It details the return contents (usage quantities, pricing, discount amounts) and period constraint, distinguishing it from generic demand cost lists or product-level lists.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it's for contract-level billing costs within a specified period (max 3 months). It does not explicitly mention alternatives or when-not-to-use, but the contract-level focus is evident, giving implied guidance that this is for contract scoping rather than broader cost queries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_mysql_recovery_timeA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true provided by annotations, the description adds value by disclosing that the tool returns a time range (recoveryStartTime ~ recoveryEndTime). It does not describe edge cases, permissions, or rate limits, but for a simple read operation, the description sufficiently covers what the tool does and returns.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, 16-word sentence that immediately communicates the tool's purpose and output. No redundant or filler content, and the most important information (the data returned) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read tool with two well-documented parameters and no output schema, the description clearly states what is returned (a time range). It does not specify the exact format of the range (e.g., timestamps), but this is likely implied and acceptable for the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the two parameters (regionCode and cloudMysqlInstanceNo), each with basic descriptions. The tool description does not add additional semantic detail about the parameters themselves, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and names the exact resource ('available recovery time range for a Cloud DB for MySQL instance'). It clearly distinguishes this tool from sibling tools like ncloud_create_mysql_recovery and ncloud_get_mysql_instance_detail by specifying the time range output.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is for retrieving the recovery time range for a MySQL instance. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough that an agent would know when to use it. No when-not-to-use guidance exists, but this is a straightforward getter.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_mysql_target_vpcsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description is consistent ('List'). It adds meaningful context beyond annotations by specifying these are VPCs specifically available for MySQL instance creation, implying a filtered subset rather than all VPCs. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that directly states the tool's purpose with no extraneous information. It is front-loaded with the verb and resource, making it instantly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one optional parameter and no output schema, the description adequately explains what it returns. It does not detail the response format or pagination, but that is not critical for this low-complexity operation. The sibling tool context reinforces its role in the MySQL instance creation workflow.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage of the only parameter, regionCode, including its meaning and default behavior. The description adds no additional parameter details, which is acceptable since the schema already carries the full semantic load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('VPCs available for Cloud DB for MySQL instance creation'), clearly distinguishing it from generic VPC listing tools and from target-VPC tools for other database services. It states exactly what the tool returns and in what context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies the tool should be used when creating a Cloud DB for MySQL instance and needing to know which VPCs are eligible. It does not explicitly mention alternatives like ncloud_list_vpcs or sibling tools for other databases, but the context is strong enough for an agent to infer when to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_objectA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds valuable context by specifying that the object content is returned as text, which goes beyond the annotation. It does not contradict annotations and provides useful behavioral detail, though it omits potential concerns like binary content or size limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and efficient—two sentences that cover the action, resource, and return value without any redundancy or filler. It is front-loaded with the most critical information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read operation with two well-documented parameters and a readOnlyHint annotation, the description is largely complete. It specifies the return type ('as text'), which is especially helpful given no output schema. Minor gaps include lack of details about binary objects or error behavior, but these are not critical for a basic get operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters ('key' and 'bucketName'), so the schema fully explains each parameter. The description does not add additional parameter-level meaning, matching the baseline expectation when schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get (download)') and clearly identifies the resource ('object from an Object Storage bucket') and the return behavior ('Returns the object content as text'). It effectively distinguishes this tool from sibling operations like head_object (which retrieves metadata) or put_object (which uploads).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you need to download an object's content. It provides clear context but does not explicitly mention alternatives or exclusions (e.g., 'use head_object for metadata'). However, the purpose is self-evident enough that an agent can infer appropriate usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_postgresql_image_productsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already communicates safety. The description adds value by specifying that it lists 'image product codes (engine versions)', clarifying the exact output scope. No contradiction exists between the description and annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no unnecessary words. It immediately states the verb and resource, making it concise and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only listing tool with one optional parameter and no output schema, the description adequately conveys the tool's purpose and output. It could mention the optional regionCode behavior, but the schema covers that, leaving little else needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (regionCode is described with valid values). The description adds no extra parameter details, but the schema fully documents the only parameter, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (List), the resource (available Cloud DB for PostgreSQL image product codes), and the purpose (engine versions). It distinguishes itself from sibling tools like ncloud_get_postgresql_products and other get_*_image_products tools by specifying the PostgreSQL engine and image product scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it clear this tool lists PostgreSQL image product codes, which implies it is used when you need engine versions for PostgreSQL. It does not explicitly mention alternatives or when not to use it, but the name and description provide sufficient context for an AI agent to select it over other image product tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_postgresql_productsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description aligns with that read-only nature. It adds value by clarifying that the output is the list of server spec product codes and that the query depends on an image product code, which enriches the behavioral context beyond the bare annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is clear and directly states the tool's function. Every word earns its place with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (2 params, 1 required), the readOnlyHint annotation, and full schema coverage, the description is sufficient for an agent to understand the tool's purpose and inputs. It lacks an explicit return-format description, but since it states it returns product codes and the schema covers parameters, it's reasonably complete for a simple listing operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, and both parameters have descriptions. The tool description adds little beyond the schema, only restating that the result is for a given image product code. The schema already names the source tool for the image product code, so the description provides minimal additional semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and clearly identifies the resource: Cloud DB for PostgreSQL server spec product codes. It also specifies the required input (image product code), and the phrasing distinguishes it from sibling tools like ncloud_get_postgresql_image_products or ncloud_get_mysql_products.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it: after obtaining an image product code from ncloud_get_postgresql_image_products. It doesn't explicitly mention alternatives or exclusions, but the 'for a given image product code' dependency provides clear context for when this tool is applicable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_zonesA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, so the description's 'List' operation aligns with that. The description adds the scoping behavior of 'current region' but does not disclose other behavioral aspects like return format, pagination, or authentication. With annotations covering the safety profile, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It conveys the essential information efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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, the description sufficiently states what it returns (zones in current region). However, with no output schema, it doesn't detail the structure of the returned zones, which could be a minor gap for the agent to fully understand the response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema coverage is 100% vacuously. The baseline for zero-parameter tools is 4, and the description doesn't need to add parameter details. The description's mention of 'current region' is not a parameter but contextual context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'List all available zones in the current region' uses a specific verb ('List'), a clear resource ('zones'), and a scope ('current region'). This clearly distinguishes it from sibling tools like ncloud_get_regions or ncloud_get_current_region, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by stating the operation is scoped to the current region, which helps the agent understand when to use it. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a perfect score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_gtm_delete_profileA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description adds valuable context by noting the deletion is permanent and requires an explicit confirm flag. It does not contradict annotations and provides extra safety-relevant behavior beyond the structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no filler, front-loading the destructive warning and clearly stating the required action. Every word contributes to understanding the tool's purpose and safety requirement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with two parameters and strong annotations, the description is largely complete. It covers the destructive nature, permanence, and confirm guard. It could mention any cascading effects or return behavior, but these are not necessary given the low complexity and schema coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters well-documented. The description restates the confirm requirement but adds little beyond the schema. This matches the baseline of 3 when the schema already explains parameters fully.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('delete') and specific resource ('Global Traffic Manager profile (domain)'), clearly distinguishing it from sibling tools like ncloud_gtm_delete_policy or ncloud_gtm_update_profile. The phrase 'Permanently delete' reinforces the exact action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly frames this as a destructive operation and provides a key usage instruction: 'Set confirm=true to execute.' This gives the agent clear context for when to invoke it, though it does not explicitly mention alternatives or when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_hadoop_change_node_specA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations (idempotentHint=true, destructiveHint=false) already disclose the safety profile, so the description doesn't need to restate that. The description adds little behavioral context beyond the action itself; it doesn't mention potential impact on cluster availability, long-running nature, or return behavior. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the verb 'Upgrade', and contains no filler. It communicates the core purpose and a key requirement efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple parameter structure (5 parameters, 1 required, no nested objects) and the presence of annotations covering safety, the description is largely complete. It could elaborate on operational expectations (e.g., whether the change is applied immediately, cluster downtime), but the schema and annotations already cover most of what an agent needs.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers each parameter with a brief description (e.g., 'New edge node server type code'), but the tool description adds the important constraint that at least one node type must be specified, which is not encoded in the schema's required fields. This semantic goes beyond the schema and helps the agent invoke the tool correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('Upgrade') and the resource ('node specs for Cloud Hadoop cluster'). It distinguishes this tool from similar node spec change tools for other services (e.g., ncloud_ses_change_node_spec, ncloud_cdss_change_node_spec) by explicitly mentioning Cloud Hadoop.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this tool is for upgrading node specs in a Cloud Hadoop cluster and includes a prerequisite ('at least one node type required'). However, it does not explicitly mention when to use this tool over alternatives like ncloud_hadoop_change_node_count or exclude scenarios where it should not be used.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_hadoop_list_target_subnetsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers safety. The description adds behavioral context by specifying that returned subnets are filtered by Hadoop compatibility, which is beyond the annotation. It does not disclose pagination or response structure, but for a simple list tool this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no filler. Every word adds value, front-loading the verb and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with three optional filters and no output schema, the description and schema together provide sufficient context to invoke the tool correctly. It lacks details about the response format, but that is not critical for a list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (vpcNo, zoneCode, regionCode) having a clear description. The tool description does not add further parameter details, but the baseline is met because the schema fully documents the parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' with the resource 'subnets' and adds the scope 'available for Cloud Hadoop deployment', clearly distinguishing it from generic subnet tools and the sibling ncloud_hadoop_list_target_vpcs. It precisely answers what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'available for Cloud Hadoop deployment' provides clear context that this tool is for selecting subnets when deploying Hadoop, setting it apart from general subnet listing tools. However, it does not explicitly state alternatives or exclusions, so it stops short of full when-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_head_bucketA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful behavioral detail beyond the readOnlyHint annotation, specifying that this is a HEAD request that returns headers only and that it checks both existence and permission. This informs the agent about the lightweight nature and expected output without contradicting the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that front-loads the primary purpose and appends essential technical detail in parentheses. Every word contributes value, with no redundant phrasing or tangential information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter, read-only tool with no output schema, the description adequately conveys the behavioral contract: it performs a HEAD request, returns headers only, and indicates existence/permission. It doesn't detail specific status codes, but that's not required for such a straightforward check.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents the only parameter, bucketName, as 'Name of the bucket to check,' achieving 100% coverage. The description's reference to 'bucket' adds no additional format, constraints, or semantics 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Check') and resource ('bucket'), clearly stating that it verifies existence and access permissions. The parenthetical '(HEAD request, returns headers only)' further distinguishes it from sibling operations like list_buckets or get_bucket_acl, making its purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you need a lightweight check for bucket existence and permission. While it doesn't explicitly name alternatives, the HEAD request semantics and focus on permission provide clear context, and there are no misleading exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_delete_keyA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds valuable context: it's irreversible, requires the key to be in REVOKE state, and requires a confirm flag. This goes beyond the annotation's simple destructive flag and provides operational detail. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with a warning emoji, and contains no fluff. Every sentence provides necessary safety or usage information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given two parameters, no output schema, and annotations covering destructiveness, the description covers the essential safety preconditions and execution requirement. It could mention what happens if the key is not in REVOKE state, but this is not critical for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already documents both keyTag and confirm thoroughly. The description adds a slight reinforcement that confirm=true actually executes the operation, but this largely mirrors the schema description for confirm. It does not add new meaning for keyTag beyond what's in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Permanently delete a KMS key.' This clearly distinguishes it from sibling tools like ncloud_kms_request_key_deletion (which requests deletion) and ncloud_kms_cancel_key_deletion (which cancels a request).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit context for when to use this tool: 'The key must be in REVOKE state (deletion requested) before it can be permanently deleted.' It also instructs the user to 'Set confirm=true to execute,' which is a clear usage requirement. It doesn't name alternatives explicitly but the state precondition implies the appropriate sequence.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_disable_ip_aclA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare idempotentHint=true and destructiveHint=false. The description adds the behavioral consequence of disabling the ACL (allowing any IP), which is important security context. It does not describe reversibility or what happens to existing rules, but for a simple toggle, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, uses active voice, and front-loads the action. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter toggle operation, the description plus annotations cover the action, its effect, and safety profile. The only minor gap is not explicitly pointing to the enable counterpart for reversibility, but that is implied by sibling tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes keyTag ('Key tag - unique identifier derived from key name'), and the description adds no additional parameter guidance. With 100% schema coverage, the description is not required to elaborate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Disable'), identifies the resource ('IP ACL'), and the target ('KMS key'), and explains the effect ('allowing token requests from any IP'). This clearly distinguishes it from sibling tools like ncloud_kms_enable_ip_acl and other KMS key operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it (when you want to allow all IPs for token requests) and contrasts with the enable operation by the opposite effect. However, it doesn't explicitly mention alternatives or when not to use it, so it misses a formal exclusion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_bucketsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint: true, so the description doesn't need to disclose safety. It adds useful scoping details: it lists ALL buckets and only in the current region, which helps set expectations about scope. However, it does not mention pagination, ordering, or return format, so it doesn't fully disclose all behavioral aspects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence with no filler or redundant information. Every word carries meaning, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter list tool, the description sufficiently states what it lists and the scope. It doesn't specify the return schema, but given the simplicity of the operation, this is an acceptable gap. The read-only annotation and empty schema keep the context small.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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, so the description carries no parameter documentation burden. The baseline score of 4 applies due to the absence of parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'List' with the clear resource 'Object Storage buckets' and scopes it to 'current region', making it easy for an agent to know exactly what this tool does. This distinguishes it from sibling tools like ncloud_list_cache_buckets or ncloud_list_mssql_buckets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly identifies the target resource (Object Storage buckets) and geographic scope, which implies the appropriate use case: enumerating buckets in the current region. It does not explicitly state alternatives or exclusions, but the resource qualifier provides sufficient context for most selection scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_log_serversA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation already declares readOnlyHint=true, covering the safe read-only nature. The description adds value beyond this by revealing that the response includes per-server collection status, which is a behavioral detail not present in the annotation or parameter schema. It does not disclose pagination behavior, but this is a minor gap for a simple list operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 14 words, front-loaded with the action and resource. It delivers the core purpose and a key output detail without any fluff, redundant phrasing, or filler. Every word contributes to understanding the tool's function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides the essential context: what is listed (eligible servers) and a notable output element (collection status). It is sufficient for an agent to select the tool for log-collection server queries. It lacks explicit detail on pagination or return fields, but the parameter schema hints at pagination, and the description is complete enough for a straightforward list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all four parameters with defaults and ranges (100% coverage). The description adds no additional parameter-level information, but this is acceptable because the schema carries the full burden. The baseline of 3 applies as the description does not detract or add meaning beyond the structured schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('List'), the resource ('servers eligible for log collection'), and the context ('Cloud Log Analytics'). The additional 'includes per-server collection status' provides a distinguishing detail that sets it apart from other server list tools, making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use the tool: when you need to see servers that can be used for log collection in Cloud Log Analytics, including their current collection status. It does not explicitly name alternatives or exclusions, but the specificity of 'log collection' makes the use case evident. No misleading or confusing guidance is present.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_maintenancesA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=true annotation, the safety profile is already established. The description adds valuable context: paging, the need for a filter, and the default ±180-day window. However, it does not disclose the exact response format, total count behavior, or any rate-limit considerations, which would further aid an agent. Passes the bar but doesn't exceed it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each with a distinct purpose: purpose statement, filter requirement alternatives, and default fallback. The description is front-loaded and contains zero filler. All critical information is conveyed in under 50 words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list operation with 7 parameters and no output schema, the description covers the essential behavior: listing, paging, and the filter/default semantics. It doesn't describe the response structure, but for a list tool the name and context strongly imply a typical list response. Given the strong parameter guidance and annotations, this is sufficient for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (each parameter has a description), so the baseline is 3. The description goes beyond by explaining the inter-parameter relationships: time range grouping (from/to with timeType) versus resource-based filtering (resourceId+productKey), plus the default window when omitted. This adds semantic clarity that the schema alone does not provide.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource structure: 'Get the list of planned maintenance schedules in Cloud Insight (paged).' It clearly distinguishes this listing tool from sibling tools like get_maintenance_detail, create_maintenance, update_maintenance, and delete_maintenance. The purpose is unambiguous and immediately actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly explains the required filter conditions: 'either a time range (from/to/timeType) OR a resource (resourceId+productKey)' and describes the fallback default. This gives clear context on when to use the tool and how to construct valid requests. It doesn't explicitly name alternative tools for getting a single maintenance or creating/updating, but the listing purpose is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ncr_create_registryA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the destructiveHint=false annotation, the description discloses valuable behavioral constraints: the bucket cannot be reused across registries and dryRun=true provides a preview without creating. It stops short of fully describing return formats or side effects, but the annotation plus these details offer solid transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no filler. It front-loads the primary purpose and immediately follows with crucial usage constraints, making it easy to scan and act on.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a create tool with only three parameters and no output schema, the description covers the key operational details: what to provide, a constraint on bucket reuse, and the dryRun option. It does not describe the response object, but the simple nature of the operation keeps this from being a major gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter already has a clear description. The tool description does not add new semantic meaning 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb (Create), resource (container registry), and linkage (to an existing Object Storage bucket). It is specific and distinguishable from sibling tools like ncloud_ncr_delete_registry or ncloud_ncr_list_registries.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on how to use the tool, including the dryRun preview option and the bucket exclusivity rule. However, it does not explicitly mention when not to use this tool or point to alternative tools for related operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ncr_delete_tagA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds the '⚠️ Destructive' warning, clarifies permanence ('Permanently delete'), and discloses the confirm flag requirement—useful context beyond the annotations. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that is front-loaded with a warning, states the action, and gives the required confirmation instruction. Zero wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple deletion tool with no output schema and rich annotations, the description communicates the essential behavior: permanent deletion and the confirm requirement. It could optionally mention prerequisites (e.g., tag must exist) but the basic context is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters, so the baseline is 3. The description adds meaning only to the 'confirm' parameter ('Set confirm=true to execute'), which is valuable but the other three parameters are left to the schema's descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Permanently delete a tag from a container image.' This is a specific verb-resource pair that distinguishes it from siblings like ncloud_ncr_delete_image (deletes the image) and ncloud_ncr_list_tags (lists tags).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly indicates usage by naming the resource (container image tag) and adds a critical usage guideline: 'Set confirm=true to execute.' It does not explicitly mention alternatives, but the tool's purpose is self-evident within the NCR context, making the lack of exclusions acceptable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_delete_worker_nodeA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description reinforces the destructiveHint annotation with a warning emoji and adds the confirm-gating behavior, which is not fully captured by annotations alone. The idempotentHint is not contradicted or elaborated, but the description adds meaningful safety context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with a concise warning prefix. Every word earns its place—it states the action, the target, and the critical execution requirement without fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive, three-parameter tool with clear annotations and schema, the description covers the essential behavior: destructive action, target, and confirmation gate. It lacks details about prerequisites or post-conditions, but these are not critical given the tool's simplicity and the presence of annotations and schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all three parameters, including the confirm flag's meaning. The description adds no new parameter information but does highlight the confirm=true requirement, which is redundant with the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Delete'), the resource ('specific worker node'), and the context ('from an NKS cluster'). It distinguishes from sibling tools like ncloud_nks_delete_node_pool by specifying 'specific worker node' rather than a node pool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for use (deleting a worker node) and a critical usage requirement ('Set confirm=true to execute'). It does not mention alternatives or exclusions, but the confirm flag is a strong, actionable guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_list_clustersA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the 'current region' scoping constraint, but does not describe return format, pagination, or ordering. With annotations covering the safety profile, this is adequate but not rich in additional behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler or redundant information. It expands the NKS acronym, states the action (list), the resource (clusters), and the scope (current region), all in one concise line.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list operation with clear purpose and scope, the description is sufficient. It does not describe the response contents, but given the simple nature and absence of an output schema, this is acceptable. The description is not severely incomplete and supports correct tool selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so schema coverage is effectively 100%. The description adds contextual meaning by clarifying the 'current region' scope, which is not a parameter but a useful environmental constraint. Baseline for 0 params is 4, and the description does not contradict the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource structure: 'List all NKS (Ncloud Kubernetes Service) clusters' and adds 'in the current region' as scope. This clearly distinguishes it from sibling tools like ncloud_nks_get_cluster (single cluster) and ncloud_nks_list_node_pools (node pools).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool: when you need to enumerate all NKS clusters in the current region. It provides clear context but does not explicitly mention when not to use it or point to alternatives such as ncloud_nks_get_cluster for detailed cluster info. This fits 'clear context, no exclusions'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_update_node_pool_taintA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (idempotentHint=true, destructiveHint=false), the description discloses the PUT semantics that all existing taints are replaced, which is critical to avoid unintended loss. This adds meaningful behavioral context beyond what annotations alone provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that efficiently conveys both the action and the key replacement behavior. No filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a relatively simple three-parameter update tool, the description covers the essential purpose and the critical nuance of full replacement. Without an output schema, return values are not detailed, but the primary behavior is sufficiently explained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all three parameters, achieving 100% coverage. The description does not elaborate on parameter meanings or formats beyond the schema, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Update', the resource 'taints on a node pool in an NKS cluster', and distinguishes from sibling tools like update_node_pool_label or update_node_pool by focusing specifically on taints. The parenthetical 'PUT replaces all taints' adds crucial scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys a clear context: this tool is for updating taints, and the note that it replaces all taints implies the agent must include the full desired list. While it doesn't explicitly name alternatives, the specificity to taints among siblings makes the usage context clear without exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pca_get_sub_csrA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, which aligns with the description's 'Get' action. The description adds the important behavioral constraint that the tool only works for unsigned Sub CAs, which is useful context beyond the annotation. It does not detail response format, but the annotation covers safety expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with no redundant information. It front-loads the primary action and resource, then adds the essential availability constraint. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, read-only annotation, no output schema), the description adequately covers what the tool does and its key constraint. It could mention the output format, but the 'Get' verb implies the CSR is returned. Overall sufficient for effective selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter caTag has a description in the schema ('CA tag value of the Sub CA'), providing 100% schema coverage. The tool description does not add additional parameter-level detail, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Get), the resource (CSR of a Sub CA), and the purpose (for external signing). The additional constraint 'Only available for unsigned Sub CAs' further clarifies scope and distinguishes it from other PCA get operations like ncloud_pca_get_ca_chain or ncloud_pca_get_ca_crl.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 the tool: retrieving a CSR for external signing, and only for unsigned Sub CAs. It does not explicitly name alternative tools, but the 'for external signing' qualifier implicitly connects to the signing workflow, making the usage intent clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pipeline_list_sourcecommit_reposA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that the repos are 'available for pipeline configuration', implying a filtered result set, which is beyond the annotation and useful for understanding behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that efficiently conveys the action, resource, and context. No wasted words or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is low-complexity with a read-only annotation and fully documented parameters. The description provides sufficient context, though the term 'available' could be more explicit about what qualifies a repo as available for pipeline configuration.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all three parameters (pageNo, pageSize, searchWord) having clear descriptions. The tool description adds no parameter-specific details, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and resource ('SourceCommit repositories'), and the qualifier 'for pipeline configuration' clearly distinguishes this from the generic sibling 'ncloud_sourcecommit_list_repos'. It also contrasts with deploy-specific tools like 'ncloud_sourcedeploy_get_sourcecommit_repos'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for pipeline configuration' provides clear context on when to use this tool (when setting up pipeline source repositories). However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_nas_volume_access_controlA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint=true and idempotentHint=true. The description adds valuable behavioral context beyond the annotations: it warns with '⚠️ Destructive' and explicitly states the confirmation requirement ('Set confirm=true to execute'), which is critical for safe usage. This adds meaningful transparency about the destructive nature and the required safety mechanism.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the destructive nature, the specific operation, and the required confirmation, all without wasted words. It is exceptionally concise while retaining all essential information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward destructive operation with three parameters and no output schema, the description covers the core action, the NFS context, and the confirm safety gate. It does not elaborate on the post-removal state (e.g., that listed server instances lose access), but this is largely implied by the tool's purpose and the parameter list. The description is mostly complete for its complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters (confirm, nasVolumeInstanceNo, serverInstanceNoList) are already well-documented in the schema. The description repeats the confirm semantics but does not add additional meaning beyond the schema, such as format expectations or relationships between parameters. This aligns with the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Remove server instance access control from a NAS volume (NFS protocol).' This uses a specific verb and resource, and explicitly mentions NFS protocol, which distinguishes it from sibling tools like add/set access control. The tool's name further reinforces this purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 the tool (when needing to remove server instance access control from a NAS volume) and includes the critical usage requirement 'Set confirm=true to execute.' It does not explicitly name alternatives or exclusions, but the context is unambiguous and the confirmation gate is explicitly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_placement_group_serverA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description reinforces the destructive nature with a warning emoji and adds behavioral context beyond annotations: the operation will not execute unless confirm=true is set. It does not contradict annotations and effectively communicates the safety gate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences: a warning label plus the core action and the mandatory confirmation instruction. It is front-loaded with '⚠️ Destructive', every sentence earns its place, and there is no extraneous text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive mutation with only three parameters, no output schema, and sufficient annotations, the description covers the essential context: what the operation does, that it is destructive, and the confirm gate. It does not explain side effects or mention the inverse operation, but given the schema and annotations, the description is adequately complete for an agent to use the tool safely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter documented (confirm requires true, placementGroupNo is the group number, serverInstanceNo is the server to remove). The description itself only restates the confirm requirement ('Set confirm=true'), which is already in the schema. Baseline 3 is appropriate since the schema carries the parameter meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource: 'Remove a server instance from a placement group.' It clearly identifies the exact operation and distinguishes it from sibling tools like ncloud_add_placement_group_server (adds) and ncloud_delete_placement_group (deletes the entire group).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates the use case ('Remove a server instance from a placement group') and provides a crucial usage requirement ('Set confirm=true to execute'). It implies when to use this tool, though it does not explicitly mention alternatives or exclusion cases. The safety-critical confirmation instruction is strong guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_process_pluginA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint and idempotentHint, but the description adds the explicit warning '⚠️ Destructive' and the requirement 'Set confirm=true to execute', which is essential behavioral context beyond what annotations provide. This helps the agent understand the safety guardrail without relying solely on the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loads the critical destructive warning, and each sentence serves a purpose: stating the action and explaining the prerequisite for execution. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the essential context for this destructive operation: what it does and the required confirm flag. There is no output schema, but this is a simple mutation tool, and the absence of return-value details is not a significant gap given the clear action and parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already described (instanceNo, configList, type, confirm). The description adds no additional parameter-level detail, so it does not exceed the baseline established by the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description provides a specific verb ('Remove') and resource ('process monitoring plugin(s) from a server instance'), clearly distinguishing it from sibling tools like add, set, or list. The action is unambiguous and directly related to the tool name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states the context ('Remove process monitoring plugin(s) from a server instance') and includes a critical usage instruction ('Set confirm=true to execute'). While it doesn't explicitly mention alternatives, the destructive nature and confirmation requirement give clear guidance on when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_targetA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds a prominent destructive warning and specifies the confirm=true safeguard, which goes beyond the annotations' destructiveHint and idempotentHint. This gives the agent actionable knowledge that the operation requires explicit confirmation to execute. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with the critical warning front-loaded. Every word earns its place, and it avoids unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward destructive operation, the description and schema provide enough context to invoke the tool correctly. The absence of an output schema is acceptable, as return values are not critical for a removal action. The description could optionally mention effects on associated resources, but this is not essential for the core task.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for all three parameters (confirm, targetNoList, targetGroupNo) with 100% coverage. The description explicitly mentions confirm=true, which aligns with the schema but doesn't add new semantic detail. Thus 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('Remove targets from a target group') with a specific verb and resource. It distinguishes itself from siblings like ncloud_add_target and ncloud_set_targets by focusing on removal. The scope is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its usage context by naming the exact operation and the confirmation requirement. However, it does not explicitly contrast with alternative tools such as ncloud_set_targets or ncloud_add_target, so it relies on the tool name and sibling list for differentiation. No exclusions or prerequisites are mentioned, making it clear but not fully prescriptive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_resource_detach_tagA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide destructiveHint and idempotentHint; the description adds the confirm=true gate and batch capability ('one or more resources'). It repeats the destructive warning but contributes meaningful safety behavior without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence with a prominent warning icon, front-loaded with the destructive warning and essential confirmation instruction. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tag-removal tool with full schema coverage and strong safety annotations, the description covers the critical execution condition and scope. No output schema is needed, and no complex side effects remain undisclosed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover all four parameters (tagKey, confirm, nrnList, tagValue) at 100%, so the description adds no additional parameter detail. The mention of 'one or more resources' only echoes the nrnList schema description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Remove a tag') and scope ('from one or more resources'), distinguishing it from sibling attach_tag and detach_group operations. The resource type (tag) is explicit and the verb is specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear execution condition ('Set confirm=true to execute') and implies the tool is for removal, but it does not explicitly mention alternatives such as attach_tag. The context is clear enough for proper selection among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_set_member_server_image_sharingA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations provide idempotentHint=true and destructiveHint=false, but the description adds valuable behavior: 'replaces existing permissions', indicating that the entire permission list is overwritten. This is useful context beyond the annotations and does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  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, and includes a parenthetical clarification. There is zero wasted text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only 2 parameters, full schema coverage, and clear annotations, the description covers the essential operation and its replacement behavior. It doesn't mention response format or prerequisites, but for a simple set operation with no output schema, these are less critical. The description is complete enough for most use cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters fully described (memberServerImageInstanceNo, targetLoginIdList). The tool description itself does not add additional parameter semantics; it relies on the schema, which is adequate. Baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('Set sharing permission') and target resource ('member server image'), while adding the key qualifier '(replaces existing permissions)' that distinguishes it from sibling tools like add/remove sharing. This makes the purpose 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'replaces existing permissions' implies this tool is for full replacement rather than incremental add/remove operations, providing clear usage context. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_set_port_pluginsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond annotations by explaining that this is a full replacement operation, which implies existing plugins not in the new list will be removed. This is important behavioral context that the annotations (idempotentHint, destructiveHint) do not fully convey. The description is transparent about the 'replace' semantic.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  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 key detail. It contains no filler and is appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple 3-parameter schema, complete schema coverage, and no output schema, the description adequately explains the tool's purpose and behavior. It covers the essential 'full replace' semantic, which is the crucial context an agent needs. No major gaps identified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with descriptions for all parameters, including the key note that portList 'replaces existing'. The description adds little beyond that, 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Replace' and clearly identifies the resource ('port monitoring plugins') and scope ('for a server instance'). It also clarifies the key behavior ('sends the entire list'), which distinguishes it from sibling tools like add/remove/get port plugins.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly communicates when to use this tool: when you need to replace the entire set of port monitoring plugins rather than add or remove individual ones. It does not explicitly name alternatives, but the context of sibling tools (add/remove) makes the usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_set_process_pluginsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds useful behavioral context beyond the annotations by emphasizing that the entire list must be sent, which signals a full replacement operation with no partial-update capability. The annotations already declare idempotentHint=true and destructiveHint=false, and the description does not contradict them. It could mention consequences of omitting existing plugins, but 'replace' plus 'sends the entire list' covers the core behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence, front-loaded with the key verb 'Replace', and includes just enough detail to clarify the important 'entire list' behavior. No filler or redundancy; every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple set-type operation with good annotations and a schema covering all parameters, the description is reasonably complete. It doesn't explicitly state that plugins not in the list will be removed, but 'Replace' implies that. It also omits any mention of prerequisites or post-conditions, but given the low complexity and no output schema, the description is sufficient for an agent to act correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 parameters, including configList as 'Full list of process names to monitor (replaces existing)'. The description's phrasing 'sends the entire list' merely restates what the schema already conveys. No additional semantic value is added for instanceNo or type beyond their schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Replace') and resource ('full set of process monitoring plugins for a server instance'), clearly distinguishing this from sibling tools like add/remove. The parenthetical '(sends the entire list)' reinforces the full-replacement semantics, leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you want to replace the entire set of process plugins rather than adding or removing individual ones. It does not explicitly name alternative tools (e.g., ncloud_add_process_plugin) or state when not to use it, but the context is clear enough to guide selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_set_targetsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly discloses the key behavioral trait that all existing targets are replaced, which is not covered by the idempotentHint or destructiveHint annotations. This is critical for the agent to understand the full impact of the call.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that clearly communicates the action and its replacement effect. Every word contributes value, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has only two required parameters and a complete schema, the description provides sufficient context for correct invocation. It does not describe return values, but for a set operation this is often implicit and the idempotentHint annotation adds further context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both targetGroupNo and targetNoList are already described in the input schema. The tool description adds no new parameter-level semantics beyond reinforcing the replacement behavior already stated in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Set' and names the resource 'targets for a target group', then clarifies that it replaces all existing targets. This clearly distinguishes it from incremental tools like ncloud_add_target and ncloud_remove_target.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states that the operation replaces all existing targets, implying it should be used when a complete replacement is needed rather than incremental changes. It does not explicitly name alternative tools, but the replacement context provides clear guidance relative to sibling tools like ncloud_add_target and ncloud_remove_target.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcebuild_list_registriesA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already communicates the safe, non-mutating nature. The description adds the scope 'available for SourceBuild', which is useful context, but it does not disclose any other behavioral aspects such as pagination, return format, or the fact that it likely queries the NCR service.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, well-structured sentence that immediately conveys the purpose. No filler, redundant information, or unnecessary details. It earns its place perfectly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless list tool with a read-only annotation and no output schema, the description provides sufficient information. It clearly states what is listed and the filter ('available for SourceBuild'). A minor gap is not explaining the relationship to NCR registries, but the sibling tools and naming conventions make this inferable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is no burden on the description to explain parameter semantics. The description correctly avoids inventing parameters and remains focused on the tool's core function.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and the resource ('Container Registry registries available for SourceBuild'). The 'available for SourceBuild' qualifier distinguishes it from the similar sibling tool ncloud_ncr_list_registries, which lists all registries without that filter.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly conveys the context: it is for listing registries that are available to SourceBuild. However, it does not explicitly mention when not to use it or name alternatives like ncloud_ncr_list_registries. The context is clear enough for an agent to infer the appropriate use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_get_k8s_clustersA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates the safe read-only nature. The description adds the scoping detail that results are limited to clusters available for SourceDeploy stage configuration, which is useful, but it does not describe return format, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. It earns a perfect score for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no parameters and no output schema, the description provides the essential information: it returns a list of Kubernetes clusters available for SourceDeploy stage configuration. It's sufficient for a simple read-only list operation, though it could mention response fields if present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema is trivially 100% covered. Per the baseline for no parameters, the description doesn't need to add parameter semantics; it simply describes the output.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get the list') and the specific resource ('available Kubernetes Service clusters for SourceDeploy stage configuration'). This distinguishes it from sibling tools like ncloud_nks_list_clusters by scoping to SourceDeploy use.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for SourceDeploy stage configuration' provides clear context on when this tool is relevant. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of the full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_get_sourcecommit_reposA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, and the description's 'Get' is consistent. The description adds the useful context that the repos are 'available' for scenario configuration, implying some eligibility filtering. However, it doesn't disclose details like whether the list is paginated, what happens if no repos are available, or whether special permissions are needed beyond what annotations imply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence of 12 words that is direct and free of unnecessary jargon. It front-loads the action and resource, making it immediately scannable by an agent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter read-only tool with good annotations, this description is nearly complete. It names the resource and the context. However, it doesn't clarify what 'available' means (e.g., only repos the user can access or that are eligible for SourceDeploy), which would further aid an agent's expectations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 adds meaning by clarifying the result set is specifically the 'available' repositories for scenario source configuration, which helps the agent understand what the response represents without needing parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and the resource 'list of available SourceCommit repositories', adding the specific purpose 'for scenario source configuration'. This distinguishes it from the more general ncloud_sourcecommit_list_repos sibling by indicating this is the filtered/eligible list for SourceDeploy scenarios.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for scenario source configuration' provides clear context for when to use this tool—when setting up a SourceDeploy scenario that needs a SourceCommit repository. It does not explicitly name alternatives, but the purpose is specific enough to guide selection among sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_terminate_serverA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the critical requirement 'Set confirm=true to execute' and emphasizes 'Permanently', giving the agent essential behavioral context beyond the destructiveHint annotation. It does not contradict annotations and provides useful guardrail information for a destructive operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single well-structured sentence that front-loads the destructive warning and immediately states the execution requirement. Every word adds value, and there is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter destructive tool with annotations covering idempotency and destructiveness, the description provides sufficient context including the confirm flag. It does not explain what happens to associated resources or error behavior, but that is beyond the minimal necessary for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the description does not add significant parameter-level detail beyond what the schema already provides (e.g., serverInstanceNoList and confirm). The phrase 'one or more server instances' aligns with the array type but adds no new semantic meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('terminate') and resource ('server instances'), and explicitly says 'permanently terminate (delete)' to distinguish it from stop/reboot operations. This provides precise purpose clarity that differentiates it from sibling tools like ncloud_stop_server or ncloud_reboot_server.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies this is for permanent deletion via the word 'terminate (delete)' and the destructive warning. It does not explicitly name alternatives like stop or reboot, but the context is clear enough for an agent to infer when to use this tool versus temporary operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_vodstation_delete_channelA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds useful context: 'Permanently' emphasizes irreversibility, the STOPPED status requirement constrains when the operation is valid, and 'Set confirm=true' explains the safety confirmation mechanism. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single compact sentence that front-loads the destructive warning and packs in the status condition and confirmation requirement. Every clause earns its place; no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with two parameters and no output schema, the description covers the core purpose, the status precondition, and the confirm flag requirement. It could mention permissions or error behavior, but the included details are sufficient for safe invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters, with clear schema descriptions for confirm and channelId. The description's 'Set confirm=true to execute' merely repeats what the schema already states, so it adds no new meaning beyond structured data.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the exact action: 'Permanently delete a VOD Station channel.' The verb 'delete' combined with the specific resource 'VOD Station channel' clearly distinguishes it from sibling operations like list, get, create, start, and stop.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an explicit precondition: 'Only channels in STOPPED status can be deleted.' It also instructs the user to 'Set confirm=true to execute,' which acts as a usage requirement. It does not explicitly contrast with alternatives, but the status condition implies you must stop the channel first.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_vodstation_start_channelA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotated with idempotentHint: true and destructiveHint: false, the description adds the key behavioral detail that the target channel must be in STOPPED status, which is not covered by annotations. It does not contradict annotations and provides useful context about the state transition being performed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence of 11 words that front-loads the verb 'Start (resume)'. Every word contributes to understanding the action and its precondition. There is no redundancy or extraneous detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, no output schema, idempotent and non-destructive annotations), the description covers the essential semantics: the action and the required state. It could be more explicit about behavior if the channel is already running, but the idempotent annotation and STOPPED-status condition provide sufficient context for an agent 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with channelId described as 'Channel ID to start'. The tool description adds no further parameter-specific meaning beyond confirming that the channel must be a VOD Station channel, but this is already implied by the tool name and schema. Baseline 3 is appropriate for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Start (resume)') and the resource ('VOD Station channel'), with a specific condition ('that is in STOPPED status'). This distinguishes it from sibling tools like ncloud_vodstation_stop_channel, which performs the opposite action, and ncloud_vodstation_create/delete, which manage channel lifecycle.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: the tool should be used when a VOD Station channel is in STOPPED status to resume it. It implies a prerequisite condition, though it does not explicitly name alternatives or state when not to use it. The 'STOPPED status' qualifier serves as a de facto usage guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_vodstation_stop_channelA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate idempotent and non-destructive behavior. The description adds value by specifying the READY status precondition, which is a behavioral constraint not visible in annotations. It does not describe error handling for non-READY channels, but the key state requirement 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action and resource. It contains no unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of a one-parameter state-change tool with good annotations and schema coverage, the description is nearly complete. It omits what happens if the channel is not in READY status, but this 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes the single parameter (channelId) with 100% coverage. The description adds no additional parameter context, but the schema's description is sufficient, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (stop), the resource (VOD Station channel), and a condition (in READY status). It distinguishes from sibling tools like ncloud_vodstation_start_channel and ncloud_vodstation_delete_channel by specifying the state transition.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'that is in READY status' provides a clear prerequisite for usage, implying it should only be called on channels in that state. However, it does not explicitly mention alternatives like starting or deleting a channel, though sibling names make that context available.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_get_kafka_versionsA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotations already establish this as a safe read operation. The description adds minimal behavioral context beyond stating its purpose and association with cluster creation. It does not describe response format, pagination, or other behavioral details, but given the annotation coverage, a mid-range score is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear, front-loaded sentence that conveys the essential information without any filler. It is appropriately concise for a simple, no-parameter retrieval tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 retrieval tool with good annotations, the description is complete. It states what the tool returns (Kafka version list) and its purpose (CDSS cluster creation), which is sufficient for the agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema coverage is 100% (empty schema). The description correctly implies no inputs are needed. With no params, the baseline is 4, and the description does not need to compensate for missing parameter information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: retrieving available Kafka version lists specifically for CDSS cluster creation. The verb 'Get' and resource 'Kafka version list' are specific, and the context 'for CDSS cluster creation' distinguishes it from other version-related tools in the sibling set.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when creating a CDSS cluster and needing to select a Kafka version. It provides clear context but does not explicitly mention alternatives or exclusions, which would warrant a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_cdss_get_os_productsA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already declares this as a safe read operation. The description adds no behavioral context beyond repeating 'Get', such as return format, pagination, or regional variations. While not contradictory, it enriches the annotation only minimally, warranting a baseline score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with clear verb and resource, containing no filler or redundant text. It efficiently conveys the tool's function in minimal words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only enumeration tool, the description fully captures the tool's role in the CDSS cluster creation flow. It does not need to explain return values in detail since 'available operating system types' implies a list, and the absence of an output schema does not create notable gaps at this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description has no parameter details to provide. Per the rubric, 0 params yields a baseline of 4; the description correctly focuses on the tool's purpose rather than irrelevant parameter guidance.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Get', identifies the resource as 'operating system types', and scopes it to 'CDSS cluster creation'. This clearly distinguishes it from sibling tools like ncloud_cdss_get_cluster_server_images or ncloud_cdss_get_node_products, which target different aspects of cluster creation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states the context of use ('for CDSS cluster creation'), helping the agent know when to call it. It does not explicitly mention alternatives or exclusions, but given the simple read-only nature, the context signal is sufficient for selection among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_objectA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds the critical behavioral detail that deletion is permanent and requires explicit confirmation (confirm=true), which goes beyond the annotation flags by explaining the safety gate and irreversible nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence with a warning emoji up front, followed by the action and execution requirement. Every word contributes value; no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple delete operation with three well-documented parameters and no output schema. The description covers the purpose, permanence, and confirmation requirement, which is sufficient for an agent to select and safely invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for all three parameters (bucketName, key, confirm). The description echoes the confirm parameter behavior but adds no new meaning beyond what the schema already provides. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: 'Permanently delete an object from an Object Storage bucket.' It specifies the verb (delete), the resource (object in a bucket), and the permanence, distinguishing it from sibling tools like ncloud_delete_multiple_objects and ncloud_delete_bucket.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear operational context by warning 'Destructive' and instructing the agent to 'Set confirm=true to execute.' It implies the prerequisite that confirm must be true, but it does not explicitly mention when to use this tool over alternatives (e.g., ncloud_delete_multiple_objects).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_scaling_policyA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the critical behavioral detail of the confirm flag requirement, which is not covered by annotations (only destructiveHint and idempotentHint are present). It reinforces the destructive nature already declared by the annotation, providing useful context without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single focused sentence that front-loads the destructive warning and states the purpose and the key execution requirement. There is zero wasted wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (3 simple parameters, no output schema), the description, combined with the annotations and full schema coverage, provides all necessary context for an AI agent to select and invoke the tool correctly. No additional information is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all three parameters are fully documented in the schema. The description adds no new parameter information beyond echoing the confirm requirement already present in the schema, which meets the baseline but does not go beyond it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (delete) and the target resource (scaling policy from an Auto Scaling Group). It is specific and distinguishes this tool from siblings like ncloud_put_scaling_policy and ncloud_list_scaling_policies.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for deleting scaling policies and explicitly instructs the user to set confirm=true to execute. It does not explicitly name alternatives or exclusion criteria, but for a destructive delete operation, the context is clear and sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_dns_delete_domainA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the destructiveHint annotation by specifying that deletion is permanent, cascades to all records, and requires confirm=true to execute. The warning emoji and explicit consequences provide valuable behavioral disclosure that annotations do not cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, information-dense sentence. It front-loads the destructive warning, clearly states the action, consequence, and required confirmation flag, with no unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive delete tool with annotations covering idempotency and destructiveness, the description effectively conveys the essential context: permanence, cascading deletion, and confirmation requirement. No output schema exists, so no return-value explanation is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the description adds no extra parameter information beyond what the schema already states. The mention of confirm=true is redundant with the schema's confirm description, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Permanently delete a Global DNS domain.' It specifies the resource and distinguishes from record-level operations by noting all records under the domain will be removed, differentiating it from sibling tools like ncloud_dns_delete_records.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (to delete an entire DNS domain) but does not explicitly mention alternatives or when-not to use it. It lacks a direct reference to sibling tools for deleting individual records, leaving the guidance 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.

• ncloud_gtm_get_health_check_regionsA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already establishes that this is a safe read operation. The description adds context about what is returned (health check region codes) but doesn't disclose behavioral traits like pagination, response format, or any rate limits. This is acceptable for such a simple lookup tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, front-loaded with the action and resource. It is concise and contains no extraneous detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only lookup tool, the description fully covers what the agent needs to know: it returns a list of available health check region codes. No output schema exists, so explaining the returned data type is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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, so there is nothing to document. The description adds no parameter information, which is fine because there are none. Per the baseline for 0 params, this is a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Get') and resource ('available health check region codes for Global Traffic Manager'). It distinguishes itself from sibling GTM tools by naming the exact data returned (health check regions) rather than just saying 'get regions'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool: whenever you need health check region codes for GTM. It doesn't explicitly mention alternatives or exclusions, but the purpose is unambiguous enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_cancel_key_deletionA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false. The description adds valuable behavioral context beyond annotations by specifying the REVOKE state requirement and the nature of the operation (cancelling a pending request). This helps the agent understand the key lifecycle implications without contradicting 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long and front-loads the action immediately. Every word earns its place, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple tool with one parameter and no output schema. The annotations cover idempotency and non-destructiveness, and the description covers the key state requirement. Together, this is fully complete for an agent to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for the single parameter keyTag, so the schema already documents it. The description does not add any additional parameter meaning beyond what the schema provides, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Cancel' and the resource 'pending key deletion request', and adds a specific precondition ('Only keys in REVOKE state'). This distinguishes it from siblings like ncloud_kms_request_key_deletion and ncloud_kms_delete_key.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for use: only keys in REVOKE state can be cancelled. This implies the tool should be used when a deletion request is pending and the key is in the REVOKE state. It doesn't explicitly name alternatives, but the state requirement is a strong usage guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_file_pluginsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already marks this as a safe read operation. The description adds behavioral context by specifying 'full list', implying no filtering and complete results. It also identifies the cloud service context ('Cloud Insight'), which is not present in the tool name. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single 12-word sentence that directly states the purpose without superfluous information. It is front-loaded and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only listing tool with a readOnlyHint annotation, the description is complete. It clearly identifies the resource and scope. Without an output schema, the description still conveys that a complete list is returned. No additional context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there are no parameter semantics to explain. The schema coverage is 100% vacuously, and the description's 'full list' reinforces that no filters are needed. Baseline 4 is appropriate for a parameterless tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get'), the resource ('full list of Cloud Insight file monitoring plugins'), and the scope ('full list'). It is specific enough to distinguish from sibling tools like ncloud_list_process_plugins and ncloud_list_port_plugins, which target different plugin categories.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: call this to retrieve all file monitoring plugins. However, it does not explicitly mention when to use this over alternatives (e.g., ncloud_get_file_plugin for a single plugin) or note any exclusions. For a simple list tool this is acceptable, but the guidance is not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_create_clusterA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only state destructiveHint=false, so the description carries the burden of behavioral disclosure. It adds valuable details: missing required params cause 400 without details, G3/KVM requires specific hypervisorCode/softwareCode formats, and dryRun behavior. This is significant added context 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long, but the complex 16-parameter tool justifies the length. It is well-structured with headers and bullet points, front-loading the core purpose and dryRun tip. Every section adds necessary operational detail, though some redundancy exists with schema field descriptions.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers G2 vs G3 differences, required prerequisites, error behavior for missing params, and cross-references to other tools for values. It lacks explicit return value description (no output schema) and permission requirements, but for a create operation with a rich schema, it is remarkably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining G3 vs G2 parameter requirements (clusterType, k8sVersion, hypervisorCode, storageSize) and emphasizing the full softwareCode format. This goes beyond the schema's individual field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Create a new NKS Kubernetes cluster' — a specific verb and resource that immediately distinguishes it from sibling tools like upgrade_cluster or delete_cluster. It also mentions dryRun for preview, adding further clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on when to use dryRun and explicitly references other tools (ncloud_nks_get_server_images, ncloud_nks_get_server_specs) for obtaining required values. It does not explicitly state alternatives/exclusions like 'use list_clusters to view existing clusters', but the usage context is strong.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_delete_access_entryA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructive and idempotent. The description adds the confirm=true safety guard, which is critical behavioral context. It also clarifies the target (IAM access entry) but does not disclose additional consequences beyond deletion.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one concise sentence with a warning icon, a clear verb+object, and a crucial execution requirement. Every word earns its place, and it is front-loaded with the destructive warning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple deletion operation, complete schema, and annotations covering destructive/idempotent behavior, the description is sufficient. It handles the one non-obvious behavior (confirm guard) and does not need to detail return values since there is no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with descriptions for all three parameters, including 'Must be true to execute' for confirm. The description reinforces this but does not add new parameter meaning beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Delete an IAM access entry from an NKS cluster.' It clearly distinguishes from sibling tools like create/update/list access entries and other NKS deletion tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for a deletion operation and explicitly states the precondition 'Set confirm=true to execute.' However, it does not explicitly mention alternatives or when not to use it, though the purpose is self-evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_delete_clusterA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description adds critical behavior: the operation is permanent and requires explicit confirmation via the confirm parameter. This goes beyond the annotation by explaining the execution guard, which is essential for an agent to use the tool safely.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, with the destructive warning first, then the action, then the required confirmation. Every sentence serves a distinct purpose and there is no redundant filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive delete tool with only two parameters, full schema coverage, and annotations providing safety hints, the description is sufficient. It covers the purpose, the confirmation requirement, and the permanence, leaving no critical gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both confirm and clusterUuid clearly described in the input schema. The description's mention of 'Set confirm=true' reinforces the confirm parameter's role but adds no new parameter-specific detail beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Permanently delete') and the resource ('an NKS Kubernetes cluster'), leaving no ambiguity about what the tool does. This distinguishes it from sibling tools like ncloud_nks_list_clusters or ncloud_nks_create_cluster.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear operational guidance by warning that the operation is destructive and requiring 'confirm=true to execute'. It does not explicitly name alternatives or exclusions, but the context of permanent deletion clearly implies this is for removing an entire cluster, not for partial operations like node pool deletion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_get_login_keysA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint: true, and the description adds context about the keys' purpose (SSH access to manager nodes). However, it does not disclose additional behavioral details such as return format, pagination, or authentication requirements. The safety profile is covered by the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that is immediately understandable. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only retrieval tool with an empty schema and no output schema, the description provides sufficient context. It clearly states what is retrieved (authentication key list) and for which resource (SES manager nodes), making it complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 adds no parameter details, but none are needed since the schema is empty. No contradiction or gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get authentication key list') and the specific resource context ('SSH access to Search Engine Service manager nodes'). It distinguishes from generic login key tools by scoping to SES manager nodes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates when to use this tool by specifying the target resource (SES manager nodes), but it does not explicitly mention alternatives or when not to use it. Context is clear, though exclusions are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_get_os_productsA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already flags this as a safe read operation. The description adds no behavioral details beyond the service scope and what is retrieved, such as return format, pagination, or authentication requirements. It is consistent with the annotation, so no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence (8 words) that is front-loaded and contains no filler. Every word adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only tool with no output schema, the description is fully adequate. It states exactly what the tool returns and for which service, allowing an agent to correctly select and invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, and the description correctly adds nothing about parameters. The baseline for a zero-parameter tool is 4, and there is nothing more to explain.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Get'), a specific resource ('available OS types'), and a scope ('Search Engine Service (G2)'). This clearly distinguishes it from sibling tools, including the similar ncloud_cdss_get_os_products for a different service.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: this tool is for retrieving OS types specifically for Search Engine Service G2. It does not explicitly mention alternatives or exclusions, but the service scope makes the use case obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_get_vpc_listA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the domain-specific context ('available for SES cluster creation') but no additional behavioral details such as auth requirements, rate limits, or return format. For a simple no-parameter list operation, this is adequate 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence: 'Get available VPC list for Search Engine Service cluster creation.' Every word contributes meaning, and there is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, no output schema, read-only annotation), the description is complete. It conveys the essential purpose and context. The lack of return format details is acceptable because no output schema is provided and this is a straightforward list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so there is no parameter information to convey. Per the rubric, 0 params earns a baseline of 4. The description doesn't need to add parameter semantics because none exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Get') and resource ('available VPC list') with explicit context ('for Search Engine Service cluster creation'). This distinguishes it from generic VPC listing tools like ncloud_list_vpcs and sibling service-specific variants like ncloud_cdss_get_vpc_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 this tool: during Search Engine Service cluster creation. It does not explicitly exclude alternatives or name them, but the purpose is specific enough that an agent would know to use this when needing VPCs for SES cluster creation rather than general VPC listing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_set_file_pluginsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral context beyond the annotations by emphasizing that the operation replaces the entire set and sends the whole list, clarifying that the provided configList is authoritative. It does not contradict the idempotentHint or destructiveHint, and it gives the agent a clear understanding that this is a bulk overwrite operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that directly states the action and its key nuance. It is front-loaded with the verb 'Replace' and contains no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, the combination of description, schema, and annotations provides all necessary information for correct invocation: purpose, parameter meanings, and safety profile. The absence of an output schema and the clear behavior make this complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all three parameters, including that configList is the full list replacing existing. The description's mention of 'sends the entire list' reinforces but does not add new semantics beyond the schema. With full schema coverage, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: replacing the full set of file monitoring plugins for a server instance. The phrase 'full set' and 'sends the entire list' distinguishes it from incremental add/remove operations among its siblings, making purpose very clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys that this tool is for full replacement of the plugin list, implying it should be used when the goal is to overwrite the entire configuration rather than add or remove individual plugins. However, it doesn't explicitly name alternatives like 'add' or 'remove', so it stops short of explicit 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.

• ncloud_set_protect_terminationA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotentHint=true and destructiveHint=false. The description adds the 'set or unset' behavior, indicating the tool toggles protection both on and off, which is useful beyond the schema's boolean parameter. This aligns with annotations, no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, well-structured sentence that immediately conveys the tool's purpose. No filler, effectively front-loaded, and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with no output schema and supportive annotations, the description is sufficient. It fully explains the operation and resource, and the schema covers the parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%; both parameters have descriptive names and descriptions in the schema. The tool description adds no extra parameter information, so it relies on the schema, which fully documents the two parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Set or unset') and resource ('termination protection on a server instance'), clearly distinguishing it from sibling tools for other resource types (e.g., block storage, NAS). It precisely conveys the tool's function without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use it: to enable or disable termination protection for a server instance. It does not explicitly name alternatives or exclusions, but the resource-specific language makes the context obvious and excludes non-server resources.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcebuild_list_repositoriesA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation readOnlyHint=true already indicates this is a safe read operation. The description adds the useful context that the list is filtered by SourceBuild eligibility, but does not disclose additional behaviors such as pagination, sorting, or permission requirements. Since annotations cover the safety profile, a score of 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence that directly states the action and resource, with no unnecessary words. It is front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, clear list operation, read-only annotation), the description is complete. It conveys the essential purpose and the SourceBuild filter, making it sufficient for an agent to understand what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema coverage is 100%, so there are no parameters to document. The description adds no parameter information, but none is needed; the baseline for 0 params is 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists SourceCommit repositories, specifically those available for SourceBuild. This distinguishes it from sibling tools like ncloud_sourcecommit_list_repos, which lists all SourceCommit repositories without the SourceBuild filter.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'available for SourceBuild' implies the context of use: when configuring or managing SourceBuild projects. It does not explicitly mention alternatives or when not to use this tool, but the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_get_sourcebuild_projectsA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description is consistent with that. It adds context that the list is scoped to projects 'available for scenario source configuration,' but it does not describe response shape, pagination, or other behavioral details. This is adequate but not rich given the simple read-only nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list operation with a clear purpose, the description is complete enough. It states what is returned and why, and the absence of an output schema is not a significant gap for such a simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, and schema description coverage is 100%, so the baseline is 4. The description adds no parameter semantics because there are no parameters to document.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get the list') and clearly identifies the resource ('available SourceBuild projects') and the purpose ('for scenario source configuration'). It distinguishes this tool from generic SourceBuild list tools like ncloud_sourcebuild_list_projects by scoping it to scenario source configuration.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states the context in which the tool is used ('for scenario source configuration'), which is explicit enough to guide basic selection. However, it does not mention when not to use the tool or name alternative tools for similar purposes, leaving some ambiguity among sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_block_storageA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only include destructiveHint: false, so the description carries the burden of behavioral disclosure. It adds valuable context about the XEN/KVM difference in attachment behavior and the dryRun option, which previews without creating. This goes beyond the annotations and helps the agent understand the tool's side effects and constraints. However, it does not mention other potential behaviors like pricing or asynchronous operations, leaving some gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, consisting of three sentences that are front-loaded with the main action. It packs essential information about required parameters, platform-specific behaviors, and a preview option without unnecessary verbosity. Each sentence earns its place, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity and the absence of an output schema, the description covers the most important contextual details: what the tool does, prerequisites, platform variations, and an alternative for attachment. It does not describe the response format, but for a creation tool this is less critical. The description is sufficiently complete for an agent to select and invoke the tool correctly, though mentioning the returned resource or operation status would improve it further.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all parameters, so the description does not need to repeat them. It does add useful guidance on how parameters relate to platform differences (e.g., serverInstanceNo for XEN, not available for KVM). However, the claim 'Requires zoneCode + blockStorageVolumeTypeCode + blockStorageSize' slightly conflicts with the schema, which states zoneCode is only required when serverInstanceNo is not provided. This minor inaccuracy prevents a higher score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'Create a new block storage instance', which is a specific verb and resource. It clearly distinguishes itself from sibling tools by noting that for KVM, attachment must be done separately with ncloud_attach_block_storage, while for XEN, serverInstanceNo can be provided to attach at creation. This makes the tool's purpose unambiguous and differentiates it from related operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states the required parameters and platform-specific instructions. It tells the user that for XEN, serverInstanceNo should be provided to attach at creation, and for KVM, attachment cannot be done at creation and should use ncloud_attach_block_storage instead. It also recommends dryRun=true to preview, providing clear guidance on when and how to use the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_launch_configA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only include destructiveHint: false, leaving the description to disclose behavior. It explains the mutually-exclusive image source requirement, spec pairing rules (XEN/RHV vs KVM), optional minimum spec, and dryRun preview behavior — all beyond annotations. Does not discuss permissions or overwrite semantics, but strong for a create tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four sentences, front-loaded with the primary purpose, then constraints in order of importance. No wasted words; every sentence adds necessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 10 interdependent parameters and minimal annotations, the description covers the critical selection and pairing rules and introduces dryRun for preview. It omits some workflow context (e.g., that the config is later attached to an ASG) and doesn't clarify whether launchConfigurationName is effectively required, but given no output schema, it's reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 100% coverage for all 10 parameters, so baseline is 3. The description adds cross-parameter logic: exactly one image source required, serverImageProductCode pairs with serverProductCode, serverImageNo pairs with serverSpecCode, and spec code optional for minimum spec. This goes beyond individual parameter descriptions and resolves ambiguity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Create a new launch configuration for Auto Scaling', which is a specific verb and resource, and clearly distinguishes from sibling list/get/delete launch config tools. It also adds key constraints (image source selection) that make the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Clearly implies this is the tool for creating launch configurations. It provides how-to guidance (image source exclusivity, spec pairing, dryRun) but does not explicitly state when not to use it or name alternatives like create_asg. Still, given siblings are list/get/delete, context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_create_serverA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare destructiveHint=false, so the description carries the burden of behavioral insight. It adds the dryRun preview behavior and the generation-specific parameter requirements, which are significant beyond the annotation. It does not cover return behavior or async execution, but for a creation tool this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with the main purpose, then compact technical guidance. No redundancy or filler. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 17-parameter creation tool with no output schema, the description covers the core creation behavior, generation-specific parameter selection, and dryRun preview. It does not discuss billing, mutual exclusivity of all parameter combinations, or return values, but the critical invocation guidance is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already has 100% description coverage for parameters, but the description adds crucial relational semantics: which parameter groups are valid together and which generation they apply to. This goes beyond individual field descriptions (e.g., serverImageNo vs serverImageProductCode) and clarifies when to use one set versus another.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Create a new server instance', a specific verb+resource that clearly distinguishes this from sibling tools like ncloud_terminate_server or ncloud_create_server_image. It further clarifies the two supported generation types (KVM/Gen3 and XEN/Gen2), adding precision about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states which parameter combinations to use for KVM vs XEN (serverImageNo+serverSpecCode for KVM; serverImageProductCode+serverProductCode or serverImageNo+serverSpecCode for XEN). It also mentions dryRun=true for previewing without creating. It does not explicitly exclude alternative tools, but the guidance is strong for correct invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_mysql_serverA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the confirm=true requirement and the master/standby restriction, which are not fully covered by the destructiveHint annotation. It also opens with a ⚠️ Destructive warning, reinforcing the safety profile. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short, front-loaded sentences. The warning appears first, followed by the action and the key constraints. Every sentence conveys essential information without unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a delete tool with no output schema, the description covers the critical aspects: what is deleted, what cannot be deleted, and the confirm flag. It missing potential details like cluster impact or error states, but given the simplicity and schema coverage, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents all three parameters with descriptions (100% coverage). The description repeats the confirm=true behavior and the slave/recovery restriction but does not add new meaning beyond the schema, such as regionCode usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Delete), the resource (Slave or Recovery server instance), and the scope (from a Cloud DB for MySQL cluster). It explicitly excludes Master/Standby, which distinguishes it from sibling tools like ncloud_delete_mysql_instance.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use (delete Slave or Recovery) and when-not-to-use (Master/Standby cannot be deleted). It also provides the execution condition 'Set confirm=true to execute', giving clear operational guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_subnetA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses destructive behavior via warning icon and 'Permanently delete', and discloses the confirm guard. This goes beyond annotations by explaining the safety mechanism. No contradiction with idempotentHint/destructiveHint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, front-loaded with a warning, no filler words. Each clause adds essential information (action+permanence, execution condition).

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with full schema coverage and annotations, the description is adequate: it states action, permanence, and execution condition. It omits potential prerequisites like disassociating dependencies, but this is not critical for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema already fully describes both parameters (subnetNo and confirm), including confirm's necessity. The description reinforces 'confirm=true' but adds no extra semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action (delete) and resource (subnet) with the specific verb 'delete' and object 'subnet', distinguishing it from sibling create/list/get tools. The word 'Permanently' reinforces the action's completeness.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  States that confirm=true is required to execute, giving a clear usage condition. However, it does not explicitly mention when not to use or provide alternatives, though the tool's purpose is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_dns_rollback_domainA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the destructiveHint annotation, the description adds concrete behavioral details: it warns '⚠️ Destructive', states 'Pending changes will be discarded', and requires 'Set confirm=true to execute.' This clearly discloses the destructive nature, the specific consequence (discarding pending changes), and the confirmation safeguard.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence. It front-loads the destructive warning, states the action, and gives the key requirement. No redundant or filler words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple rollback tool with two parameters, the description, combined with the schema and annotations, is nearly complete. It covers what the tool does, the side effects, and the confirmation requirement. It could mention prerequisites like the existence of a previously applied state, but this is likely implied by 'previously applied state.' No output schema is needed for a rollback operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 add parameter details. The only parameter-related mention is 'Set confirm=true to execute,' which duplicates the confirm parameter's schema description. No additional semantic value beyond the schema is provided, hence the baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource: 'Rollback a Global DNS domain to the previously applied state' and clearly distinguishes this from sibling tools like ncloud_dns_apply_domain, ncloud_dns_delete_domain, and ncloud_dns_list_domains. It precisely states the action and the target resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use: when you want to revert a domain to its last applied state and discard pending changes. This provides clear context, though it does not explicitly name alternative tools or exclusions. The phrase 'Pending changes will be discarded' clarifies the scenario but could be stronger with an explicit 'use when...' statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_functions_delete_packageA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (destructiveHint=true), the description adds critical behavioral context: the deletion is permanent and requires explicit confirmation (confirm=true). This goes beyond what annotations alone convey, and there is no contradiction with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a clear warning emoji, concise action statement, and explicit execution requirement. Every word earns its place, with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with full schema coverage and annotations, the description covers the essential action and prerequisite. It lacks information about potential side effects (e.g., whether deleting a package also deletes its actions/triggers), but this is not strictly required given the tool's simplicity and available structured metadata.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 mentions 'confirm=true' but this only repeats what the schema already states in the confirm parameter's description. It adds no new semantic information beyond the structured schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the verb 'delete' and resource 'Cloud Functions package', with the clarifying qualifier 'permanently'. It clearly distinguishes this tool from sibling delete tools by specifying the target resource (package vs. action, trigger, etc.).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for use: it is a destructive operation requiring confirm=true to execute. It does not explicitly name alternatives or when-not-to-use, but the specific resource and confirmation requirement give sufficient usage guidance for this simple deletion tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_decryptA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already indicates a non-destructive read operation. The description adds valuable behavioral context by specifying the supported key algorithms and the mandatory KMS prefix, which are not disclosed in annotations. No contradictions exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action, and contains no filler. Every sentence provides operational constraints that are useful for correct invocation. Excellent conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the essential invocation details: supported key types, ciphertext prefix requirement. It does not explicitly state the return value, but the output (decrypted plaintext) is implied by 'decrypt'. Since no output schema exists, a brief note on return format would improve completeness, but the core usage is sufficiently covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% parameter descriptions, so the baseline is 3. The description adds extra meaning by highlighting key type restrictions relevant to keyTag and reiterating the ciphertext prefix format, which reinforces the schema's ciphertext description. This modest addition warrants a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Decrypt ciphertext using a KMS key.' It also specifies supported key types (AES256 or RSA2048) and the required ciphertext prefix format, distinguishing this tool from sibling KMS operations like encrypt, sign, or verify.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by stating which key types are supported and the required ciphertext format, giving the agent enough information to decide when this tool is appropriate. It does not explicitly exclude alternatives, but the constraints effectively guide selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_nks_delete_node_poolA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint and idempotentHint, but the description adds valuable behavioral context: the deletion is permanent and requires confirm=true to execute. This goes beyond the structured annotations by explaining irreversibility and the safety guard, which is critical for a destructive operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a warning symbol, clearly stating the destructive action and the confirmation requirement. Every word contributes meaning; there is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive delete operation with comprehensive schema and annotations, the description adequately covers the operation's purpose, the permanence, and the confirmation gate. It does not explain return values, but no output schema exists, and the annotation set covers idempotency and destructiveness sufficiently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage, describing all three parameters including the confirm requirement. The description's mention of confirm=true merely restates the schema's own description ('Must be true to execute'), adding no new semantic insight beyond what structured fields already convey.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('delete'), a specific resource ('node pool'), and a clear scope ('from an NKS cluster'). It clearly distinguishes this tool from similar siblings like ncloud_nks_delete_worker_node and ncloud_nks_delete_cluster by naming the exact resource being deleted.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly conveys the operation's context: permanently deleting a node pool from an NKS cluster, with a mandatory confirmation flag. It does not explicitly name alternatives or when-not-to-use scenarios, but the resource-specific wording makes the intended use unambiguous among sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_network_acl_outboundA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds the confirmation gate (confirm=true) beyond the destructiveHint annotation, warning that removal only executes with this flag. The destructive nature is reaffirmed with the warning emoji.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence with warning, front-loaded, every word serves a purpose. No fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description plus rich schema and annotations cover the action, confirmation requirement, and parameter details. No output schema exists, but for a simple removal operation this is sufficient. Could optionally mention post-condition or reversibility but not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover all 8 parameters, and the description does not add semantic detail beyond the confirm=true mention already present in the schema. Baseline 3 applies due to 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Remove' and resource 'outbound rule from a Network ACL', clearly distinguishing from the inbound sibling by direction. The warning icon and confirm instruction add operational clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context that this targets outbound rules and requires confirm=true, but does not explicitly name the inbound alternative or specify when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_remove_route_table_subnetA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructiveHint and idempotentHint, so the description's destructive warning initially seems redundant. However, the description adds valuable context by explicitly telling the agent to set confirm=true to execute, which is an essential safety behavior not fully explained in the annotations alone.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that wastes no words. It packs the operation, the destructive warning, and the execution requirement into a compact, scannable format.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple removal tool with full schema coverage, no output schema, and safety annotations, the description sufficiently covers the operation, destruction risk, and confirmation requirement. It doesn't elaborate on preconditions or response details, but the tool's simplicity and schema completeness make that acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all parameters, so the baseline is 3. The description adds extra semantic value by highlighting the confirm parameter's gatekeeping role ('Set confirm=true to execute'), which reinforces what the schema states but also frames it as the critical execution guard for a destructive operation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific verb 'Remove' and resource 'subnet association from a route table', making the tool's purpose immediately apparent. It distinguishes itself from sibling tools like ncloud_remove_route and ncloud_add_route_table_subnet by explicitly naming the association removal operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly conveys the operation and provides a critical usage instruction ('Set confirm=true to execute'). While it doesn't explicitly mention when to choose this over alternatives, the narrowed scope ('subnet association from a route table') makes the usage context clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_resource_detach_groupA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the behavioral nuance that the operation is destructive and requires a confirmation flag (confirm=true) to actually execute, which is not fully captured by the destructiveHint annotation alone. It also clarifies that the effect is removing resources from a group, not deleting them. This is valuable context 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a clear warning symbol and the essential instruction. Every word contributes to understanding the tool's purpose and the critical confirm requirement, with no wasted text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive operation with three parameters and no output schema, the description covers the core action, the confirmation requirement, and the destructive nature. It lacks details about return values or potential side effects, but given the tool's simplicity and the annotations covering idempotency/destructiveness, it is sufficiently complete for an agent to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for all three parameters (confirm, groupId, nrnList) with 100% coverage. The description's mention of 'Set confirm=true' reinforces the confirm parameter's purpose but doesn't add new meaning beyond the schema's existing description. Therefore, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Remove' and clearly identifies the resource being acted upon: 'resources from a resource group.' This distinguishes it from sibling tools like ncloud_resource_attach_group and ncloud_resource_detach_tag, which involve adding to a group or removing tags.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly tells when to use: when you need to detach resources from a group. It provides a critical usage guideline with 'Set confirm=true to execute,' indicating the required confirmation step. However, it doesn't explicitly name alternatives or state when not to use this tool, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcebuild_list_bucketsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, and the description confirms this with 'List'. Additional context is added by specifying that the buckets are those 'available for SourceBuild artifact storage', indicating a filtered view. This is a useful behavioral detail 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that immediately conveys the action, resource, and context. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list operation with no parameters and no output schema, the description is sufficient. It identifies the resource and its purpose. It could mention response format or pagination, but the simplicity of the tool reduces the need for that detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline of 4 applies. The schema is empty and the description adds meaning by clarifying the purpose and scope of the listing, but there are no parameter semantics to expound upon.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List'), the resource ('Object Storage buckets'), and the specific context ('available for SourceBuild artifact storage'). This distinguishes it from other bucket-listing tools like ncloud_list_buckets and ncloud_sourcedeploy_get_objectstorage_buckets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'available for SourceBuild artifact storage' provides clear context for when this tool should be used (when dealing with SourceBuild). It does not explicitly exclude alternatives or name other tools, but the SourceBuild-specific scope is a strong signal.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_change_block_storage_sizeA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark idempotentHint=true and destructiveHint=false. The description adds context that only size increase is supported, and the attached-volume/stopped-server requirement. This covers the main behavioral traits beyond annotations, though no return format or auth info is mentioned.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise, information-dense sentences. Every sentence adds critical value: what the tool does, when to use an alternative, and a necessary precondition. No filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple resize operation with clear annotations and full schema coverage, this description is complete. It covers the operation type, scope constraint, platform distinction, and a critical prerequisite. No output schema exists, so return values are not expected to be documented.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no additional parameter meaning beyond what is in the schema; it reinforces the 'increase only' constraint which the schema already captures.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Resize a block storage volume (increase capacity only)', which is a specific verb+resource with a critical constraint. It also explicitly distinguishes itself from sibling tool ncloud_change_block_storage, clarifying the Gen2 vs KVM split.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: 'Dedicated volume-size endpoint for Gen2 (XEN) storage. KVM-based block storage is NOT supported here — use ncloud_change_block_storage for KVM.' It also states a key prerequisite: server must be stopped if volume is attached.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_drm_delete_policyA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (destructiveHint=true), the description discloses that deletion is permanent, that sites using the policy must be disabled first, and that confirm=true is required. These behavioral details materially inform the agent about safety requirements and consequences, going beyond what the structured annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short sentences deliver a warning, the action, a prerequisite, and the confirmation requirement. Every sentence earns its place; there is no filler or redundant phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive two-parameter tool with safety annotations, the description covers the action, irreversibility, prerequisite, and execution gate. The absence of an output schema does not create a gap for this simple delete operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already documents policyId and confirm. The description restates the confirm requirement but adds no deeper semantic detail, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Permanently delete a DRM policy,' using a specific verb and resource with a permanence qualifier. This clearly distinguishes the tool from DRM get/update/disable operations, and no sibling tool competes for the same delete-policy action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an explicit prerequisite ('Disable any site using this policy first') and an execution gate ('Set confirm=true to execute'). It doesn't explicitly name alternatives such as update_policy or disable_site, but the context is sufficient for an agent to know when this destructive action is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_get_product_listA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, and the description aligns with a read-only operation. Beyond annotations, it discloses important behavior: pagination details (default 50/page, sorted by productCode, response fields totalRows/returnedRows/hasMore/nextPageNo, and instruction to follow nextPageNo). This adds significant context for handling results correctly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: first sentence states purpose, second lists return content, third gives usage and pagination. Every sentence contributes value; no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no output schema, the description adequately covers return values (product codes, names, descriptions, categories) and pagination mechanics. The schema covers parameter details, and annotations cover safety, leaving no major context gaps for an agent to invoke this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with each of the 8 parameters fully described (e.g., regionCode 'KR, KRS', productName substring matching). The description only repeats the high-level 'use regionCode and optional filters' without adding parameter-level meaning, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it 'Get product (service) list for billing,' using a specific verb ('Get') and resource ('product list'), and distinguishes it from sibling product-list tools by scoping it to billing. It also enumerates returned fields (codes, names, descriptions, categories), leaving no ambiguity about its core function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage guidance: 'Use regionCode and optional filters to narrow results' and mentions pagination behavior. It establishes the billing context but does not explicitly name alternatives or exclusions (e.g., when to use ncloud_get_product_category_list instead), so it falls short of full differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_kms_delete_token_generatorA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds significant behavioral context beyond the annotations: 'All existing tokens will be invalidated' and 'Set confirm=true to execute.' It explains the side effect and the confirmation mechanism, which are critical for a destructive operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences front-load the destructive warning and provide essential usage information without extraneous detail. The structure is efficient and clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter destructive operation, the description covers purpose, effect, and required confirmation. The annotations already declare destructiveHint, so the safety profile is complete without needing an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes both parameters with 100% coverage. The description's instruction to 'Set confirm=true' reinforces the confirm parameter's purpose but adds little new information beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action 'Delete (deactivate)' and the target 'token generator for a KMS key', which distinguishes it from sibling tools like create/update/get token generator. The verb and resource are 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the usage context clear: deleting/deactivating a token generator, and it warns about token invalidation. It doesn't explicitly mention alternatives or when not to use, but the lifecycle context is clear enough for an agent to select this over create/update.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_list_process_pluginsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description aligns with the readOnlyHint annotation and adds useful context by specifying the product domain 'Cloud Insight' and the scope 'full list.' It does not mention pagination or return format, but for such a simple no-parameter list operation, the description provides adequate transparency beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear, and information-dense sentence. It states exactly what the tool does without any fluff, making it optimally concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that there are no parameters, no output schema, and a straightforward listing operation, the description fully covers what an agent needs to know: the resource type, scope, and result. Nothing is missing for correct tool selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters in the schema, so the baseline is 4. The description correctly indicates that the tool requires no inputs and directly returns the full list. No parameter explanations are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Get' and identifies the exact resource: 'full list of Cloud Insight process monitoring plugins.' It clearly distinguishes from sibling tools like ncloud_get_process_plugin (singular) and ncloud_list_port_plugins (different plugin type).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'full list' implies this is the tool to use when you need a comprehensive enumeration of process monitoring plugins, as opposed to fetching a specific plugin. It doesn't explicitly name alternatives, but for a zero-parameter list tool the intended usage is clear and no exclusions are needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ncr_delete_imageA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotation destructiveHint already flags destructiveness, but the description adds valuable behavioral context: the operation is permanent and removes all associated tags. This goes beyond the raw annotation and clarifies exactly what will be destroyed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, information-dense sentence with a warning emoji, followed by a short instruction. Every word earns its place—no fluff, front-loaded with the destructive warning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive delete tool, the description covers the operation, prerequisites (confirm), and consequences (tags removed). Annotations cover idempotency and destructiveness; the schema covers parameters. No output schema is needed, and the description is sufficient for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the effect of deleting the image (all tags removed), which is not in the schema. It also reiterates confirm=true, which is already in the schema, but the overall effect enriches the imageName semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Permanently delete a container image from a registry' with the specific effect 'All associated tags will be removed.' This distinguishes it from sibling tools like ncloud_ncr_delete_tag (which deletes a single tag) and ncloud_ncr_delete_registry (which deletes a registry).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: it is destructive, permanent, and requires confirm=true to execute. However, it does not explicitly state when not to use it or mention alternatives (e.g., delete_tag instead of delete_image if only a tag should be removed).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pca_delete_caA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the destructiveHint annotation by detailing the irreversibility ('private key will be permanently destroyed and cannot be recovered') and the requirement for confirm=true. This adds significant behavioral context about the consequences and execution guardrail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (two sentences) and front-loaded with a clear destructive warning. Every sentence adds critical information without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive delete operation, the description covers the essential context: what it deletes, the status prerequisite, the irreversible consequence, and the confirmation requirement. No additional critical information appears missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters, so the schema already documents caTag and confirm precisely. The description reinforces 'Set confirm=true to execute' but does not add substantial new meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Permanently delete a Private CA', identifying the specific action and resource. It also distinguishes from sibling PCA operations by noting the status requirement and the confirm flag, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear precondition: 'Only CAs in DESTROYING status can be deleted.' It also instructs to set confirm=true to execute. However, it does not explicitly mention when not to use or discuss alternatives, so it stops short of full usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_pca_delete_ocspA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds significant behavioral context beyond the annotations: it discloses that the OCSP URL is removed from all certificates issued by the CA, which is a critical side effect. It also reinforces the confirm=true safeguard, making the destructive nature explicit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with a warning emoji and clear instruction. Every word earns its place, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (2 params, no output schema), the description is complete: it covers purpose, destructive side effect, and the confirm requirement. The annotations cover idempotency, so no gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the confirm parameter is already fully described in the schema. The description adds a minor reinforcement ('Set confirm=true to execute') but does not provide additional meaning for caTag beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (Delete), the resource (OCSP configuration), and the scope (removes the OCSP URL from all certificates issued by this CA). This is specific and distinguishes it from sibling tools like ncloud_pca_create_ocsp.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this is a destructive operation and instructs the agent to set confirm=true to execute. It does not explicitly name alternatives or exclusions, but the context is sufficient for when to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_restore_nas_volume_with_snapshotA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  While destructiveHint annotation already marks it destructive, the description adds critical context: 'Current data will be overwritten with the snapshot data' and the confirm=true safeguard. This goes beyond the annotation by specifying the exact data-loss behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence with a clear warning, the action, and the confirmation requirement. No filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 3-param destructive restore tool, the description plus schema fully cover the prerequisites, the destructive behavior, and the confirm safety mechanism. Output schema absence is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and the description mostly restates the confirm parameter's purpose from the schema. It doesn't add new semantics for nasVolumeInstanceNo or nasVolumeSnapshotNo beyond their names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Restore a NAS volume to a previous snapshot state' with a specific resource (NAS volume) and the effect (overwrite). This distinguishes it from sibling tools like create_nas_snapshot or delete_nas_snapshot.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides the key usage requirement 'Set confirm=true to execute' and the context of restoring a volume, but doesn't explicitly name alternative tools or state when-not-to-use. The destructive warning implicitly signals caution.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_ses_delete_clusterA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructiveHint=true, but the description adds critical behavioral context: permanent deletion, total data/index loss, and the requirement to set confirm=true for execution. This goes beyond the annotation to disclose consequences and the safety mechanism, with no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short, front-loaded sentences with a warning icon and 'Destructive' label. Every word earns its place, conveying purpose, consequences, and execution requirement without waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter destructive operation with annotations, the description fully covers purpose, consequences, and execution requirement. No output schema exists, and return values are not needed for this tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters (serviceGroupInstanceNo and confirm). The description reiterates the confirm=true requirement but adds no new parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'Permanently delete a Search Engine Service cluster.' It clearly identifies the resource type (SES cluster) and distinguishes it from sibling delete cluster tools like ncloud_cdss_delete_cluster and ncloud_nks_delete_cluster by naming the service.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: use this tool to permanently delete an SES cluster. The service-specific naming and destructive warning make the usage obvious, though it does not explicitly mention alternatives or state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcebuild_cancel_buildA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, and the description reinforces this with the ⚠️ warning and the 'Destructive' label. It adds critical context about the confirm parameter ('Set confirm=true to execute'), which is not in the annotations and is essential for safe invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that includes a warning, the action, and the confirmation requirement. There is zero wasted text, and it is highly scannable for an agent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple cancel operation with all parameters documented in the schema, the description covers the essential behavioral aspects: destructive nature and confirmation requirement. The idempotentHint annotation covers repeatability. No output schema is needed for cancellation, and no further context is necessary.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining the confirm parameter's role ('Set confirm=true to execute'), which goes beyond the schema's default value description. The other parameters (projectId, buildId) are straightforward and well-documented in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Cancel a running SourceBuild build') with a specific verb and resource, distinguishing it from sibling tools like start_build and get_project. The destructive warning adds further clarity about its nature.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use the tool: when a SourceBuild build is running and needs cancellation. It does not explicitly mention alternatives or exclusions, but the context is clear given the sibling set includes build management tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcebuild_delete_projectA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that deletion is permanent and includes all build history, going beyond the destructiveHint annotation. It also reveals the requirement to 'Set confirm=true to execute,' which is essential behavioral information not present in 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no wasted words. It includes a warning emoji, the action, the affected resource, and the critical confirm requirement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with two parameters and no output schema, the description fully covers the essential context: what is deleted, permanence, and the safety gate. It does not need to explain return values or alternative tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the confirm parameter's role, but it largely echoes the schema's own description ('Must be true to execute the destructive operation'), providing no new semantic detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: 'Permanently delete a SourceBuild project and all its build history.' It uses a specific verb and resource, distinguishing it from sibling tools like ncloud_sourcebuild_list_projects and ncloud_sourcebuild_get_project.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the usage context clear—delete a project when you no longer need it—and emphasizes the destructive, permanent nature. It does not explicitly name alternatives or exclusions, but the context is unambiguous for a delete operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_sourcedeploy_delete_projectA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the destructiveHint annotation by explicitly listing what will be removed ('All stages, scenarios, and history') and adding the safety mechanism 'Set confirm=true to execute.' This provides specific behavioral context about consequences and execution requirements that the annotations alone do not convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with a clear warning, then states the action, its consequences, and the required execution flag. Every word earns its place with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (2 parameters, no output schema), the description fully covers what the tool does, what it destroys, and how to execute it. The destructive and idempotent annotations complement the description, and the safety flag is clearly documented. No significant gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both projectId and confirm already described in the schema. The description reinforces that confirm must be true to execute, but this duplicates the schema's own description and adds no new semantic information beyond what the structured fields provide.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Permanently delete a SourceDeploy project.' It specifies the resource and the verb, and distinguishes from sibling tools like delete_stage or delete_scenario by noting the project-level scope and that all stages, scenarios, and history will be removed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this is a project-level destructive operation, implying it should be used when deleting the entire project rather than individual stages or scenarios. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncloud_delete_sub_accountA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the destructiveHint annotation by detailing consequences: 'All associated permissions and access will be revoked.' It also discloses the confirmation requirement ('Set confirm=true to execute'), which is not present in annotations. This provides valuable safety context for an irreversible operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise with two sentences. The destructive warning is front-loaded with an emoji, and every phrase ('permanently delete', 'permissions revoked', 'confirm=true') conveys essential information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete operation with strong annotations, the description is sufficient. It covers the action, consequences, and the required confirmation flag. It does not describe return values or error scenarios, but these are less critical for a straightforward destructive tool without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so both parameters are already documented. The description adds a behavioral note about confirm=true, connecting the parameter semantics to the destructive action. This reinforces the confirmation requirement beyond the schema's default-value description, adding value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Permanently delete a sub account'. It uses a specific verb ('delete') and resource ('sub account'), and the warning emoji emphasizes destructive intent. This distinguishes it from sibling tools like ncloud_list_sub_accounts and ncloud_create_sub_account.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a key usage guideline: 'Set confirm=true to execute.' This tells the agent the prerequisite for execution. While it doesn't explicitly mention alternatives or exclusions, the confirm-flag requirement is a clear condition for safe usage, which is sufficient for a destructive operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.