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 mentions the CNAME prerequisite and failure condition, which is useful. However, it doesn't describe what happens on success (e.g., what gets created, response format), whether this is idempotent, what permissions are required, rate limits, or other operational characteristics. For a creation tool with complex nested parameters, this leaves significant behavioral gaps.

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

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

The description is concise - just two sentences in Chinese. The first sentence states the purpose, and the second provides the critical prerequisite. There's no wasted text or redundancy. However, given the tool's complexity, this brevity comes at the cost of completeness.

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

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

Given the tool's complexity (creation operation with 2 parameters, complex nested objects, no annotations, no output schema), the description is inadequate. It covers the basic purpose and one prerequisite but misses: parameter explanations, success behavior, error conditions beyond the CNAME check, relationship to sibling tools, and what the created configuration enables. For a tool that creates domain routing configurations with multiple sub-configurations, this leaves too much unexplained.

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

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

Schema description coverage is 50%, so the description needs to compensate but doesn't. It mentions nothing about the parameters themselves - not even the existence of 'region' or 'createCustomDomainConfig' object. The description focuses only on a prerequisite (CNAME configuration) rather than explaining what parameters mean or how they interact. With 2 parameters and complex nested objects, this leaves significant gaps in understanding parameter purpose and usage.

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

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

The description clearly states the tool's purpose: '创建函数计算的域名路由配置' (create domain routing configuration for function compute). It specifies the verb ('创建' - create) and resource ('域名路由配置' - domain routing configuration), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'update-custom-domain-config' or 'get-custom-domain-config'.

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

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

The description provides some usage context by stating a prerequisite: '域名必须已经CNAME到函数计算的公网域名...否则会创建失败' (the domain must already be CNAME'd to the function compute public domain, otherwise creation will fail). This is helpful guidance about when the tool will work. However, it doesn't specify when to use this tool versus alternatives like 'update-custom-domain-config' or provide explicit exclusions.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool deletes domain routing configurations and that CNAME records are not deleted automatically (requiring manual deletion), which adds important behavioral context beyond the basic delete operation. However, it does not mention potential side effects, permissions needed, 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.

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

The description is a single, efficient sentence that directly states the tool's action and a key behavioral note about CNAME records. It is front-loaded with the main purpose and avoids unnecessary words, 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.

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

For a deletion tool with no annotations and no output schema, the description is adequate but has gaps. It covers the main action and a critical side effect (CNAME records not deleted), but lacks details on prerequisites, error handling, or what happens after deletion. Given the complexity and lack of structured data, it could be more complete.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('region' and 'domain') thoroughly. The description does not add any parameter-specific information beyond what the schema provides, such as examples or constraints not in the schema. 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.

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

The description clearly states the specific action ('删除' meaning delete) and resource ('函数计算的域名路由配置' meaning function compute domain routing configuration). It distinguishes from siblings by focusing on domain configuration deletion rather than function deletion or other operations, 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.

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

The description implies usage for deleting domain routing configurations in function compute, but does not explicitly state when to use this tool versus alternatives like 'update-custom-domain-config' or 'delete-function'. It mentions that CNAME records are not deleted automatically, which provides some context but not explicit guidance on tool selection.

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

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

No annotations are provided, so the description carries full burden. It states the destructive action ('delete') but lacks critical behavioral details: whether deletion is permanent, if it requires specific permissions, what happens to associated resources (e.g., versions, triggers), error conditions, or response format. For a destructive tool with zero annotation coverage, this is a significant gap.

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

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

The description is a single, efficient sentence in Chinese with zero waste. It's front-loaded with the core action and resource, making it immediately understandable. No extraneous information or redundancy.

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

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

For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context (permanence, side effects), usage guidelines, and output expectations. Given the complexity of deletion operations and the absence of structured safety hints, the description should provide more guidance to ensure safe and correct use.

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

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

Schema description coverage is 100%, with both parameters ('functionName', 'region') well-documented in the schema. The description adds no parameter semantics beyond what's in the schema (e.g., doesn't explain relationships between parameters or usage nuances). Baseline 3 is appropriate 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.

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

The description '删除函数计算的函数' (delete function compute function) clearly states the action (delete) and target resource (function compute function). It's specific about what gets deleted, though it doesn't explicitly distinguish from sibling tools like 'delete-function-version' or 'delete-custom-domain-config' beyond 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.

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 prerequisites (e.g., function must exist), when not to use it (e.g., if versions exist), or refer to related tools like 'delete-function-version' or 'list-functions' for verification. The agent must 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.

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

No annotations are provided, so the description carries full burden. It states the action is 'delete' which implies a destructive mutation, but doesn't disclose critical behavioral traits: whether deletion is permanent/reversible, if it affects associated resources (e.g., aliases, triggers), required permissions, or error conditions (e.g., cannot delete active versions).

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

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.

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

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

For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context: behavioral implications (permanence, side effects), prerequisites, error handling, and what happens post-deletion (e.g., confirmation, returned data). The high schema coverage doesn't compensate for these gaps in operational guidance.

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

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

Schema description coverage is 100%, with each parameter well-documented in the schema (functionName uniqueness, region enum with default, versionId). The description adds no additional parameter semantics beyond what's already in 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.

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

The description '删除函数计算的函数版本' clearly states the action (delete) and resource (function version in function computing). It's specific about what gets deleted, though it doesn't explicitly differentiate from sibling tools like 'delete-function' which deletes the entire function rather than a specific version.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., whether the function version must be inactive), nor does it reference sibling tools like 'delete-function' (for entire functions) or 'list-function-versions' (to see available versions).

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states '查询' (query), implying a read-only operation, but doesn't clarify if this requires authentication, what happens on errors, or the format of returned data. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior and constraints.

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

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

The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. There's no wasted verbiage, and it fits well within a concise format.

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

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

Given the complexity of a domain configuration query tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the query returns (e.g., routing rules, status), potential errors, or how it interacts with sibling tools. For a tool that likely returns structured data, more context is needed to guide effective use.

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

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

Schema description coverage is 100%, with both parameters ('region' and 'domain') well-documented in the schema, including enum values and format rules. The description adds no additional meaning beyond what the schema provides, such as explaining the relationship between parameters. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter semantics adequately.

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

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

The description '查询函数计算的域名路由配置' (Query function computing domain routing configuration) states the action (query) and resource (domain routing configuration for function computing), which provides a basic purpose. However, it doesn't distinguish this read operation from its siblings like 'get-function' or 'list-functions', nor does it specify what exactly is being queried (e.g., all configurations vs. a specific one). It's clear but vague on scope.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'create-custom-domain-config' or 'update-custom-domain-config', nor does it specify prerequisites (e.g., needing an existing domain). Without any context on usage scenarios or exclusions, the agent lacks direction.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it retrieves information, implying a read-only operation, but doesn't specify whether it requires authentication, rate limits, error conditions, or what information is returned. For a tool with zero annotation coverage, 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.

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

The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste, making it easy for an AI agent to parse quickly.

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

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

Given the tool's complexity (a read operation with 2 parameters), 100% schema coverage, and no output schema, the description is minimally adequate. It states what the tool does but lacks details on behavioral aspects (e.g., authentication, error handling) and doesn't guide usage relative to siblings. Without annotations or output schema, more context would be helpful for completeness.

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

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

Schema description coverage is 100%, with both parameters ('functionName' and 'region') well-documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain parameter interactions or usage nuances). Baseline 3 is appropriate 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.

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

The description '获取创建的函数计算的函数信息' clearly states the purpose: retrieving information about a created function in function computing. It specifies the verb '获取' (get/retrieve) and the resource '函数计算的函数信息' (function computing function information). However, it doesn't explicitly differentiate from sibling tools like 'list-functions' or 'get-custom-domain-config', which would require a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'list-functions' (for listing multiple functions) or 'get-custom-domain-config' (for different resource types), nor does it specify prerequisites such as needing an existing function. Usage is implied by the action but not explicitly defined.

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

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

With no annotations provided, the description carries full burden. It describes the limited return scope ('只返回函数名称与部分函数信息' - returns only names and partial info) which is valuable behavioral context. However, it doesn't mention pagination behavior (implied by nextToken parameter), rate limits, authentication requirements, 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.

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

The description is perfectly concise with two sentences that each earn their place. The first sentence states the purpose and scope, the second provides clear usage guidance. No wasted words or redundant information.

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

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

For a list operation with no annotations and no output schema, the description provides good context about what information is returned and when to use it versus alternatives. However, it doesn't describe the output format or structure, which would be helpful given the absence of an output schema. The parameter documentation is complete in the schema.

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

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

Schema description coverage is 100%, so the schema already fully documents all 6 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.

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

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

The description clearly states the action ('获取函数计算的函数列表' - get function list), resource ('函数计算' - function compute), and scope ('只返回函数名称与部分函数信息' - returns only function names and partial information). It distinguishes from sibling 'get-function' by specifying this tool returns limited information while get-function returns all information.

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

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

The description explicitly provides when to use this tool ('获取函数计算的函数列表' - for listing functions) and when to use an alternative ('如果需要获取所有函数信息，请使用get-function工具' - use get-function for complete function information). This gives clear guidance on tool selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure but provides minimal information. It states it retrieves a list but doesn't describe pagination behavior (implied by 'nextToken' parameter but not explained), rate limits, authentication requirements, error conditions, or what the output looks like. For a list operation with 5 parameters and no annotations, this leaves significant behavioral gaps.

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

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

The description is a single, efficient Chinese sentence that states exactly what the tool does without any unnecessary words. It's front-loaded with the core purpose and wastes no space on redundant information. This is an excellent example of conciseness.

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

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

For a tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the relationship between parameters, pagination behavior, typical response structure, or error handling. While the schema documents parameters well, the description fails to provide the contextual understanding needed for effective tool use, especially given the absence of annotations and output schema.

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

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

The schema description coverage is 100%, with all parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema descriptions. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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

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

The description '获取函数计算的函数版本列表' clearly states the action ('获取' - get/retrieve) and resource ('函数版本列表' - function version list), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list-functions' or 'get-function', but the focus on versions is clear. This is specific enough to understand what the tool does without being tautological.

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

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

The description provides no guidance on when to use this tool versus alternatives. There's no mention of when to use 'list-function-versions' versus 'list-functions' or 'get-function', nor any context about prerequisites or typical use cases. The agent must infer usage from the tool name and parameters alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool publishes a new version but doesn't explain what 'publish' entails (e.g., whether it deploys to production, requires specific permissions, affects existing versions, or has rate limits). This is a significant gap for a mutation tool with zero 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.

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

The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to clarity.

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

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral details (e.g., what 'publish' means operationally, error conditions, or response format) and usage context, leaving significant gaps for an AI agent to understand how to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any meaning beyond what the schema provides about 'functionName', 'region', or 'description'. Baseline 3 is appropriate 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.

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

The description clearly states the action ('发布' meaning 'publish') and resource ('函数的最新代码' meaning 'function's latest code') to create a new version. It's specific about what the tool does but doesn't differentiate from siblings like 'update-custom-runtime-function' or 'put-custom-runtime-function' which might have overlapping purposes.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing function code), exclusions, or comparisons to sibling tools like 'update-custom-runtime-function' or 'delete-function-version' that might be relevant in a versioning workflow.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool '尝试覆盖并更新目标函数' (attempts to overwrite and update) which implies mutation, and notes automatic packaging. However, it lacks critical behavioral details: required permissions, whether deployment is idempotent, error handling for conflicts, rate limits, or what happens to existing function configurations during update. For a complex deployment tool with 18 parameters, this 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.

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

The description is appropriately concise with two sentences. The first sentence states the core purpose and key behavior (automatic packaging). The second provides important usage note about update behavior and pre-check recommendation. Both sentences earn their place without redundancy.

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

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

Given the tool's complexity (18 parameters, mutation operation, no output schema, no annotations), the description is inadequate. It doesn't explain what happens on success/failure, return values, error conditions, or operational constraints. While the schema provides parameter documentation, the description fails to provide the holistic context needed for a deployment tool of this complexity.

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

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

Schema description coverage is 100%, so the schema already documents all 18 parameters thoroughly. The description adds minimal parameter semantics: it mentions '代码工程不需要手动打包，会自动处理' (code project doesn't need manual packaging, handled automatically) which relates to the 'location' parameter, and implies update behavior for 'functionName'. However, it doesn't provide additional context beyond what's in the schema descriptions. Baseline 3 is appropriate when schema does heavy lifting.

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

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

The description clearly states the tool's purpose: '将构建完成的匹配阿里云自定义运行时的工程，部署到函数计算' (deploy a built project matching Alibaba Cloud custom runtime to Function Compute). It specifies the verb ('部署' - deploy) and resource ('函数计算' - Function Compute), and mentions automatic packaging. However, it doesn't explicitly differentiate from sibling tools like 'update-custom-runtime-function' beyond mentioning update behavior.

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

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

The description provides some usage context: '如果函数已存在，则尝试覆盖并更新目标函数' (if the function already exists, it attempts to overwrite and update) and '建议使用该方法前先确认函数是否存在' (suggest confirming if the function exists before using this method). This implies when to use it (for deployment with update capability) but doesn't explicitly contrast with alternatives like 'create' vs 'update' tools or provide clear exclusion criteria.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. The description only states that it 'updates' and 'modifies' configuration, implying a mutation operation. However, it doesn't disclose important behavioral traits: whether this requires specific permissions, whether the update is idempotent, what happens to existing traffic during the update, whether there are rate limits, or what the response format looks like. For a complex configuration update tool with no annotation coverage, this is a significant gap.

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

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

The description is extremely concise - just two Chinese phrases that essentially say the same thing. While this avoids verbosity, it's arguably under-specified rather than appropriately concise. The two phrases '更新函数计算的域名路由配置' and '修改域名路由配置' are redundant, with the second adding no new information. However, it does front-load the core purpose without unnecessary elaboration.

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

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

Given the tool's complexity (3 parameters with nested objects, no annotations, no output schema), the description is woefully incomplete. A tool that updates custom domain configurations for function computing should explain the scope of changes, potential impacts, required permissions, and response expectations. The description provides none of this context, leaving the agent with insufficient information to understand when and how to use this tool effectively.

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

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

The description provides no parameter information beyond what's in the schema. With 67% schema description coverage (2 of 3 parameters have descriptions), the schema does substantial documentation work. The description doesn't add any semantic context about parameter relationships, dependencies, or usage patterns. It doesn't explain that 'updateCustomDomainConfig' is a complex object containing protocol, routing, authentication, certificate, TLS, and WAF configurations. The baseline 3 is appropriate given the schema's documentation coverage.

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

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

The description '更新函数计算的域名路由配置，修改域名路由配置' is tautological - it essentially restates the tool name 'update-custom-domain-config' in Chinese. While it mentions 'function computing' and 'domain routing configuration', it doesn't provide a clear, specific verb+resource combination that distinguishes it from sibling tools like 'create-custom-domain-config' or 'get-custom-domain-config'. The description lacks specificity about what aspect of the configuration is being updated.

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

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

The description provides no guidance on when to use this tool versus alternatives. There are clear sibling tools for creating, deleting, and getting custom domain configurations, but the description offers no indication of prerequisites, when this update operation is appropriate versus creating a new configuration, or what state the domain must be in for this operation to succeed. This leaves the agent with no usage context.

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

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

No annotations are provided, so the description carries full burden. It mentions that the tool '更新并部署' (updates and deploys), implying a mutation operation, but doesn't disclose critical behavioral traits: whether this requires specific permissions, if it's idempotent, what happens on failure (e.g., partial updates), rate limits, or deployment time. For a complex mutation tool with 18 parameters and no annotations, this is a significant gap in 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.

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

The description is concise (two sentences) and front-loaded with the core purpose. Every sentence adds value: the first states what the tool does, the second provides usage guidance. There's no redundant information or unnecessary elaboration, making it appropriately sized for its purpose.

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

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

Given the tool's complexity (18 parameters, mutation operation, no output schema, no annotations), the description is insufficient. It doesn't explain what 'deploy' entails (e.g., deployment time, rollback options), doesn't mention error handling or response format, and lacks context about when this tool should be used versus sibling tools like 'put-custom-runtime-function'. For a mutation tool with this level of complexity, more comprehensive guidance is needed.

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

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

Schema description coverage is 100%, so the schema already documents all 18 parameters thoroughly. The description adds minimal value beyond the schema: it mentions that unspecified parameters remain unchanged during configuration updates, which is useful context for partial updates. However, it doesn't explain parameter interactions or provide additional semantics beyond what's in the schema descriptions, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: '更新并部署custom runtime函数' (update and deploy custom runtime function). It specifies the verb ('更新并部署' - update and deploy) and resource ('custom runtime函数' - custom runtime function). However, it doesn't explicitly differentiate from sibling tools like 'put-custom-runtime-function' or 'update-custom-domain-config', which would be needed for a score of 5.

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

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

The description provides some usage context: '如果需要修改代码，必须先完成构建。如果需要更新函数配置，需要提供更新的参数，未提供的参数将保持不变' (If code modification is needed, building must be completed first. If updating function configuration, provide updated parameters; unspecified parameters remain unchanged). This implies when to use it (for updating code or configuration) and mentions prerequisites (building before code updates). However, it doesn't explicitly state when NOT to use it or name alternatives like 'put-custom-runtime-function' for creation vs. update scenarios.

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