DataWorks MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources and actions, such as CreateDataQualityRule vs. GetDataQualityRule, which are clearly differentiated by their CRUD operations. However, some tools like CreateDIJob and CreateDISyncTask appear to have overlapping purposes (both creating data integration sync tasks), which could cause minor confusion for an agent.
Naming Consistency5/5
The tool names follow a highly consistent verb_noun pattern throughout, such as CreateDataSource, GetDataSource, UpdateDataSource, and ListDataSources. This consistency makes the tool set predictable and easy to navigate, with no mixing of naming conventions like camelCase or snake_case deviations.
Tool Count2/5
With 186 tools, the count is excessively high for a single server, making it overwhelming and difficult for an agent to manage effectively. This large number suggests poor scoping, as many tools could likely be consolidated or grouped, leading to inefficiency and potential confusion in tool selection.
Completeness5/5
The tool set provides comprehensive coverage across multiple domains like data quality, data integration, data services, and workflow management, with full CRUD operations (e.g., Create, Get, Update, Delete, List) for most resources. There are no obvious gaps, and the tools support end-to-end workflows, ensuring agents can perform complex tasks without dead ends.
Average 2.5/5 across 186 of 186 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 5 community issues answered or closed in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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 but offers none. It doesn't indicate whether this tool performs read or write operations, what permissions are required, whether it's destructive, what rate limits apply, or what the expected behavior is. The vague description fails to provide any behavioral context 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one phrase, this is a case of under-specification rather than effective conciseness. The single Chinese phrase doesn't earn its place by providing meaningful information. It's front-loaded with essentially no content, failing to communicate purpose or usage.
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?
For a tool with 6 parameters, no annotations, and no output schema, the description is completely inadequate. It provides no information about what the tool does, when to use it, what behavior to expect, or what results it returns. The description fails to compensate for the lack of structured metadata, leaving the agent with insufficient 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 description coverage is 100%, so all 6 parameters are documented in the schema itself. The description adds no additional meaning about parameters beyond what's already in the structured schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '测试数据服务API' is a tautology that merely restates the tool name 'TestDataServiceApi' in Chinese. It provides no specific verb or resource information, fails to distinguish from sibling tools like 'CreateDataServiceApi' or 'GetDataServiceApi', and offers no clarity about what this tool actually does.
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?
The description provides absolutely no guidance about when to use this tool versus alternatives. With many sibling tools like 'CreateDataServiceApi', 'GetDataServiceApi', 'UpdateDataServiceApi', and 'DeleteDataServiceApi', there's no indication whether this is for testing, executing, or managing APIs. No context, 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.
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. The description reveals nothing about whether this is a read or write operation (though 'Create' implies mutation), what permissions are required, whether it's idempotent, what happens on failure, or any side effects. For a complex creation tool with 10 parameters, this complete lack of behavioral context is inadequate.
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 extremely brief with just two lines, but this brevity comes at the cost of being under-specified rather than efficiently informative. The first line is a tautology, and the second line is a meta-instruction about tool invocation format. While structurally simple, it fails to convey essential information that would help an AI agent use the tool effectively.
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?
For a complex creation tool with 10 parameters, nested objects, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what a 'data quality rule' is in this context, what system it operates on, what happens after creation, or any behavioral characteristics. The agent would have to rely entirely on the parameter names and schema descriptions without any 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?
The schema description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds zero information about any parameters, their relationships, or usage patterns. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建质量规则' (Create quality rule) is a tautology that merely restates the tool name 'CreateDataQualityRule' in Chinese. It provides no additional specificity about what kind of quality rule, for what system, or what resources it affects. While the name itself suggests creating a data quality rule, the description adds no value beyond 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, dependencies, or any context about when this creation operation is appropriate. The note about the 'MCP Resource' is a meta-instruction about tool usage format, not guidance about when to invoke this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states 'creates' but doesn't clarify if this is a write operation, what permissions are required, whether it's idempotent, what happens on failure, or what the output looks like (no output schema). For a complex creation tool with 19 parameters, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('创建数据服务API') which is overly concise to the point of under-specification. For a tool with 19 parameters and no annotations, this brevity fails to provide necessary context. It's not structured or front-loaded with key information.
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?
Given the tool's complexity (19 parameters, no annotations, no output schema), the description is completely inadequate. It doesn't explain the tool's behavior, output, error handling, or usage context. Sibling tools like 'PublishDataServiceApi' and 'UpdateDataServiceApi' suggest a workflow that isn't addressed, leaving the agent with insufficient guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 itself. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples, no clarification of dependencies between parameters like 'ApiMode' and 'RequestMethod'). 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建数据服务API' is a tautology that simply restates the tool name in Chinese ('Create Data Service API'). It doesn't specify what 'creating' entails, what a 'Data Service API' is, or how this differs from similar tools like 'PublishDataServiceApi' or 'UpdateDataServiceApi'. The purpose is stated but not clarified beyond the obvious.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a project or group), when to choose this over 'PublishDataServiceApi' or 'UpdateDataServiceApi', or any constraints on usage. With 19 parameters including complex ones like 'ApiMode', this lack of context is problematic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. The description only states '创建数据源' (Create data source), which implies a write/mutation operation but reveals nothing about permissions required, side effects, rate limits, error conditions, or what happens upon success (e.g., whether a new data source ID is returned). This is critically insufficient for a creation 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just three Chinese characters—but this brevity results in severe under-specification rather than effective conciseness. While it has no wasted words, it fails to convey necessary information, making it inefficient for its purpose. A score of 3 reflects that it is short but not helpfully structured.
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?
Given the complexity (a creation tool with 6 parameters, 4 required), lack of annotations, and no output schema, the description is completely inadequate. It does not explain what the tool does beyond the name, when to use it, behavioral implications, or expected outcomes. For a mutation tool in a rich sibling ecosystem, this leaves the agent with insufficient context to operate 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, thoroughly documenting all 6 parameters (e.g., Name constraints, Type references, ConnectionProperties details). The description adds no parameter information beyond what the schema already provides. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建数据源' (Create data source) is a tautology that merely restates the tool name 'CreateDataSource' in Chinese. It provides no specific information about what 'data source' means in this context, what resources are involved, or how this creation differs from similar operations like 'CloneDataSource' or 'UpdateDataSource' among the 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 Guidelines1/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. It does not mention prerequisites (e.g., needing a ProjectId), scenarios where creation is appropriate, or when to choose other tools like 'CloneDataSource' or 'UpdateDataSource'. Without any usage context, the agent has no basis for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool creates something, with no disclosure of behavioral traits like whether this is a configuration operation vs. immediate execution, permission requirements, rate limits, side effects, or what happens on failure. For a complex creation tool with 14 parameters, this is severely inadequate.
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 brief (two sentences) but under-specified rather than concise. The first sentence is a tautology, and the second is a meta-instruction about MCP Resources that doesn't describe the tool itself. While short, it fails to convey essential information efficiently.
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?
For a complex creation tool with 14 parameters, nested objects, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool actually does beyond the tautological name restatement, provides no behavioral context, and offers no guidance on usage. The comprehensive schema partially compensates but the description fails to add 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?
Schema description coverage is 100%, providing detailed documentation for all 14 parameters including enumerations and examples. The description adds no parameter information beyond the schema, so it doesn't compensate but doesn't need to given the comprehensive schema. Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建数据集成同步任务' (Create data integration synchronization task) is a tautology that essentially restates the tool name 'CreateDIJob' in Chinese. While it indicates the tool creates something related to data integration, it lacks specificity about what exactly is being created (e.g., a job configuration, a running instance) and doesn't differentiate from potential siblings like 'CreateDISyncTask' which appears 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 Guidelines1/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 prerequisites, appropriate contexts, or distinguish it from other creation tools in the sibling list (e.g., 'CreateDISyncTask', 'CreateDataQualityEvaluationTask'). The second sentence about MCP Resource is a meta-instruction for tool usage examples, not a usage guideline for 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.
Behavior1/5
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 states '创建' (create) which implies a write/mutation operation, but provides no information about permissions required, whether the creation is reversible, what happens on failure, rate limits, or what the response contains. For a complex creation tool with 4 parameters and nested specifications, this is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (two sentences), the description is under-specified rather than efficiently informative. The first sentence is a tautology that adds no value, and the second sentence is procedural metadata about MCP Resources rather than explanatory content. Neither sentence helps an AI agent understand what the tool actually does or how to use it effectively.
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?
For a complex creation tool with 4 parameters (including a deeply nested Spec object), no annotations, and no output schema, the description is completely inadequate. It provides no information about what gets created, the creation context, behavioral characteristics, or expected outcomes. The agent would need to rely entirely on the input schema, which documents parameters but not the tool's purpose or 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 the schema already documents all parameters thoroughly. The description adds no parameter information whatsoever - it doesn't mention ProjectId, Scene, Spec, or ContainerId. However, since the schema provides complete descriptions, the baseline score of 3 is appropriate as the description doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建数据开发节点' (Create data development node) is a tautology that essentially restates the tool name 'CreateNode' in Chinese. It provides no specific verb or resource details beyond the name, and doesn't distinguish this tool from its many siblings (like CreateWorkflowDefinition, CreateTask, etc.). The English note about MCP Resource is procedural rather than explanatory.
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?
The description provides absolutely no guidance on when to use this tool versus alternatives. There are many sibling tools for creating various resources (workflows, tasks, APIs, etc.), but the description offers no context about when this specific node creation tool is appropriate. The MCP Resource note is about how to use the tool, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to do so: it does not indicate whether this is a read or write operation (implied write from 'create'), what permissions are required, if it's idempotent, rate limits, or what happens on success/failure. The MCP Resource note adds no behavioral context, leaving the agent with no safety or operational insights.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified, not concise. The first line is a tautology, and the second line about the 'MCP Resource' is vague and does not earn its place by adding value. It lacks front-loaded clarity and wastes space on unhelpful content, failing to be efficiently informative.
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?
Given the complexity (11 parameters, nested objects, no output schema, and no annotations), the description is severely incomplete. It does not explain what a 'workflow instance' is, how creation works, return values, or error handling. The schema handles param documentation, but the description fails to provide the necessary contextual overview for a mutation tool with significant operational 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 description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds no parameter information beyond what's in the schema, not even summarizing key fields like 'Type' or 'ProjectId'. However, with high schema coverage, the baseline score is 3, as the schema compensates for the description's lack of param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建工作流实例' (Create workflow instances) is a tautology that restates the tool name in Chinese, providing no additional specificity about what 'creating workflow instances' entails. It fails to distinguish this tool from siblings like 'CreateWorkflowDefinition' or 'ExecuteAdhocWorkflowInstance', leaving the purpose vague beyond the literal name.
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?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions, and the note about an 'MCP Resource' is generic and unhelpful for decision-making. With many sibling tools like 'CreateWorkflowDefinition' or 'StartWorkflowInstances', the lack of comparative guidance 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.
Behavior1/5
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. The description only states '删除质量规则' (Delete quality rule), which implies a destructive operation but provides no information about permissions required, whether deletion is permanent or reversible, what side effects occur, rate limits, or error conditions. For a destructive tool with zero annotation coverage, this is critically insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three Chinese characters, this is under-specification rather than effective conciseness. The description fails to provide necessary information about a destructive operation, making it inefficient rather than appropriately brief. Every sentence should earn its place, but here the single phrase doesn't earn its place by providing adequate guidance.
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?
Given this is a destructive operation with no annotations and no output schema, the description is completely inadequate. It doesn't explain what happens after deletion, what permissions are required, whether the action is reversible, or what the response looks like. For a tool that permanently removes data quality rules, this minimal description creates significant risk of misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 (Id and ProjectId) documented in the schema. The description adds no parameter information beyond what the schema already provides. According to scoring 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除质量规则' (Delete quality rule) is a tautology that restates the tool name in Chinese without adding specificity. It doesn't clarify what type of quality rule, what system it operates in, or what distinguishes it from similar deletion tools like DeleteAlertRule or DeleteDataQualityEvaluationTask. The description merely translates the name without providing meaningful context about the action's scope or target.
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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple deletion tools in the sibling list (e.g., DeleteAlertRule, DeleteDataQualityEvaluationTask, DeleteDataServiceApi), but the description doesn't indicate when this specific deletion is appropriate, what prerequisites exist, or what happens after deletion. No contextual usage information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The single phrase '删除数据服务API' only indicates a destructive delete operation but provides no information about permissions required, whether deletion is reversible, what happens to dependent resources, rate limits, or expected response format. For a destructive mutation tool with zero annotation coverage, this is critically insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three Chinese characters, this represents under-specification rather than effective conciseness. The description fails to provide necessary context for a destructive operation. Every sentence should earn its place, but here the single phrase fails to earn its place by being insufficiently informative for the tool's complexity.
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?
For a destructive deletion tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what gets deleted, under what conditions, what the consequences are, or what the agent can expect as a result. The combination of a mutation operation with zero behavioral transparency and no output information creates significant risk 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%, with all three parameters (ProjectId, ApiId, TenantId) having clear descriptions in the schema. The tool description adds no parameter information beyond what the schema already provides. According to scoring 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除数据服务API' is a tautology that merely restates the tool name 'DeleteDataServiceApi' in Chinese. It provides the verb 'delete' and resource 'data service API' but lacks specificity about what deletion entails or any differentiation from sibling tools like 'DeleteDataSource' or 'DeleteDataQualityRule'. The purpose is clear at a basic level but fails to distinguish this specific deletion operation from others.
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?
The description provides absolutely no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, conditions for deletion, or what happens after deletion. With sibling tools like 'AbolishDataServiceApi' and 'DeleteDataServiceApi' both present, the lack of differentiation is particularly problematic. The agent receives no help in choosing between these similar-sounding operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. '删除任务' only indicates a deletion action without any information about permissions required, whether the deletion is permanent or reversible, what happens to dependent resources, rate limits, or error conditions. This is completely inadequate for a destructive operation 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two Chinese characters, this is a case of under-specification rather than effective conciseness. The description fails to provide necessary information about a destructive operation. Every sentence should earn its place, but here the single phrase fails to earn its place by being insufficiently informative.
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 destructive deletion tool with no annotations, no output schema, and a minimal description. Given the complexity of a deletion operation and the complete lack of structured behavioral information, the description is woefully incomplete. It doesn't explain what gets deleted, under what conditions, what the consequences are, or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 (Id and ProjectEnv) having descriptions in Chinese ('任务ID' and '项目环境'). The tool description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除任务' (Delete task) is a tautology that merely restates the tool name 'DeleteTask' without providing additional context. It doesn't specify what type of task is being deleted, what system it operates in, or how it differs from other deletion tools like DeleteWorkflow or DeleteTaskInstance. While the verb+resource structure is present, it lacks specificity and 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple deletion tools in the sibling list (DeleteAlertRule, DeleteDataQualityEvaluationTask, DeleteWorkflow, etc.), but the description offers no context about which deletion operation this performs, what prerequisites exist, or when other deletion tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action '删除工作流' (Delete workflow) without any details on permissions required, whether deletion is permanent or reversible, side effects, error conditions, or response format. For a destructive operation with zero annotation coverage, this is critically insufficient and fails to inform the agent about the tool's behavior 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '删除工作流' (Delete workflow), which is overly concise to the point of under-specification. While it avoids unnecessary words, it lacks any structuring or front-loading of critical information, making it inefficient for the agent to understand the tool's purpose and use. Every sentence should earn its place, but here the minimal content fails to provide adequate context.
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?
Given the tool's complexity as a destructive deletion operation, the absence of annotations, and no output schema, the description is severely incomplete. It does not address behavioral aspects like safety, permissions, or outcomes, nor does it clarify the resource being deleted. For a tool with significant implications and no structured support, the description fails to provide the necessary context for effective 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 has 100% description coverage, with clear documentation for Id, ClientUniqueCode, and EnvType parameters. The description adds no additional meaning beyond what the schema provides, such as explaining parameter interactions or usage examples. However, since the schema is comprehensive, the baseline score of 3 is appropriate, as the description does not need to compensate for gaps but also adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除工作流' (Delete workflow) is a tautology that merely restates the tool name 'DeleteWorkflow' in Chinese. It provides no additional specificity about what constitutes a 'workflow' in this context or how the deletion operates. While it correctly identifies the verb and resource, it fails to distinguish this tool from other deletion tools like DeleteWorkflowDefinition or DeleteResource, leaving the purpose vague.
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?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions for use, or compare it to sibling tools such as DeleteWorkflowDefinition or DeleteWorkflowInstances. Without any context or exclusions, the agent lacks essential information to make an informed selection among deletion-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description '获取任务列表' reveals nothing about whether this is a read-only operation, whether it requires authentication, what the return format looks like, pagination behavior, rate limits, or error conditions. For a tool with 13 parameters and no annotation coverage, this is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely concise with just three Chinese characters, this is under-specification rather than effective conciseness. The description fails to provide any meaningful information that would help an AI agent understand or use the tool correctly. Every sentence should earn its place, but this has no sentences to evaluate.
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?
Given the complexity (13 parameters, no annotations, no output schema), the description is completely inadequate. It doesn't explain what the tool returns, how results are structured, pagination behavior, or any behavioral traits. For a list tool with many filtering options, this minimal description leaves critical gaps in 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?
Schema description coverage is 100%, so the schema already documents all 13 parameters thoroughly with descriptions and examples (e.g., SortBy with format details, TaskType with enum-like values). The description adds zero parameter information beyond what's in the schema, meeting the baseline of 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取任务列表' (Get task list) is a tautology that restates the tool name 'ListTasks' in Chinese. It provides no additional specificity about what kind of tasks, what scope, or what distinguishes this from other list tools like ListTaskInstances or ListTaskOperationLogs. The purpose is minimally stated but lacks differentiation.
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?
The description offers no guidance on when to use this tool versus alternatives. With sibling tools like GetTask (singular), ListTaskInstances, and ListTaskOperationLogs, there's no indication of when this list tool is appropriate versus those other task-related tools. No context 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states the action 'publish' without explaining what publishing does (e.g., makes API publicly accessible, triggers deployment, requires specific permissions). It doesn't mention side effects, success/failure conditions, or what happens to the API state. This is inadequate 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one phrase, this is under-specification rather than effective conciseness. The single phrase '发布数据服务API' doesn't provide enough information to be helpful. It's front-loaded but lacks substance, failing to earn its place as a useful description.
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 mutation tool (publishing implies changing state) with no annotations, no output schema, and a minimal description. The description doesn't explain what publishing means, what the expected outcome is, or any behavioral characteristics. Given the complexity of publishing an API and the lack of structured metadata, the description is completely 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 all three parameters (ProjectId, ApiId, TenantId) are documented in the schema with clear descriptions. The tool description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '发布数据服务API' (Publish data service API) is a tautology that essentially restates the tool name 'PublishDataServiceApi'. It provides the verb 'publish' and resource 'data service API', but doesn't specify what publishing entails (making it live, deploying it, activating it) or what happens when published. It doesn't distinguish from sibling tools like 'CreateDataServiceApi' or 'SubmitDataServiceApi'.
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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing a created API first), sequencing (e.g., use after creation/testing), or distinctions from similar tools like 'SubmitDataServiceApi' or 'AbolishDataServiceApi'. The agent receives no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but fails completely. '置成功任务实例' doesn't indicate whether this is a read or write operation (though 'Set' implies mutation), what permissions are required, whether the operation is reversible, what side effects might occur, or how the system responds. For a tool that appears to modify task instance states, this lack of behavioral information is critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just four Chinese characters, this is a case of severe under-specification rather than effective conciseness. The description is so brief that it fails to communicate essential information. Every word should earn its place, but here the words don't provide meaningful guidance beyond restating the tool name.
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?
For a tool that appears to modify task instance states (a potentially significant operation), the description is completely inadequate. With no annotations, no output schema, and a minimal description that adds no value beyond the tool name, this leaves the agent with insufficient information to understand when and how to use this tool safely and effectively. The description fails to compensate for the lack of 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?
The input schema has 100% description coverage, with both parameters ('Ids' and 'Comment') clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema description coverage is high (>80%), the baseline score is 3 even with no parameter information in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '置成功任务实例' is a tautology that restates the tool name 'SetSuccessTaskInstances' in Chinese. It provides no additional information about what the tool actually does, what 'success' means in this context, or what resource is being modified. While it implies setting task instances to a success state, this is merely restating the name without clarifying the specific action or purpose.
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?
The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple sibling tools that manipulate task instances (e.g., RerunTaskInstances, ResumeTaskInstances, StopTaskInstances, UpdateTaskInstances), but the description offers no differentiation. It doesn't specify prerequisites, appropriate contexts, or when this operation should be preferred over other task instance management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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. The description only states 'submit' without explaining what this action does (e.g., changes API state, triggers a process, requires approval), whether it's idempotent, what permissions are needed, or what the expected outcome is. For a mutation 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('提交数据服务API' - 6 Chinese characters) but this represents under-specification rather than effective conciseness. It's front-loaded by default due to its brevity, but fails to provide any meaningful information that would help an agent understand or use the tool correctly.
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?
Given this is a mutation tool (implied by 'submit') with no annotations, no output schema, and a vague description, the description is completely inadequate. It doesn't explain what the tool does, when to use it, what behavior to expect, or what the result will be. The 100% schema coverage for parameters is insufficient compensation for the lack of functional 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 has 100% description coverage, with all three parameters (ProjectId, ApiId, TenantId) clearly documented in the schema itself. The description adds no additional information about parameter meanings, constraints, or relationships. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '提交数据服务API' is a tautology that essentially restates the tool name 'SubmitDataServiceApi' in Chinese. It doesn't specify what 'submit' means in this context (e.g., submit for approval, submit for execution, submit for publication) or what resource is being acted upon beyond the generic 'data service API'. While it indicates a verb ('submit'), the purpose remains vague without clarifying what submission entails or what happens to the API.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the API must be created first), what state the API should be in, or how it differs from sibling tools like 'PublishDataServiceApi' or 'TestDataServiceApi'. Without any context, an agent cannot determine appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but fails completely. It doesn't indicate whether this is a destructive operation, what permissions are required, whether suspension is reversible, what happens to dependent tasks, or any side effects. The single phrase provides no behavioral context beyond the basic action name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three Chinese characters, this represents under-specification rather than effective conciseness. The description is so minimal that it fails to provide necessary context. A truly concise description would still include essential information about the tool's purpose and usage in a compact form.
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?
For a mutation tool (suspend implies state change) with no annotations, no output schema, and multiple sibling tools that perform similar operations on task instances, this description is completely inadequate. It doesn't explain what suspension means, how it differs from stopping, what the expected outcome is, or any prerequisites. The description fails to provide the minimal context needed for an agent to use this tool 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 description coverage is 100%, with both parameters (Ids and Comment) clearly documented in the schema. The description adds no parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '暂停任务实例' (Suspend task instances) is a tautology that essentially restates the tool name 'SuspendTaskInstances' in Chinese. While it clearly indicates the action (suspend) and target (task instances), it doesn't provide any additional specificity about what 'suspend' means operationally or how it differs from related tools like 'StopTaskInstances' or 'ResumeTaskInstances' 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There are several related tools in the sibling list (StopTaskInstances, ResumeTaskInstances, RerunTaskInstances, SetSuccessTaskInstances) that appear to operate on task instances, but the description offers no differentiation or context about when suspension is appropriate versus stopping, resuming, or other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 '更新' (update) implying a mutation, but fails to describe any behavioral traits: it doesn't specify required permissions, whether updates are partial or full replacements, side effects (e.g., on running tasks), error handling, or response format. For a complex mutation tool with 11 parameters and nested objects, this is critically inadequate.
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 concise (one Chinese sentence plus an MCP Resource note) but under-specified rather than efficiently informative. The first sentence is too vague to be helpful, and the second is procedural boilerplate not directly about the tool's function. While brief, it fails to front-load essential context about the tool's purpose or usage.
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?
Given the tool's high complexity (11 parameters, nested objects, no output schema, no annotations), the description is severely incomplete. It doesn't explain what an 'update' entails, the scope of changes, expected outcomes, or error conditions. The MCP Resource note doesn't compensate for these gaps. For a mutation tool in a data quality system, this leaves the agent guessing about critical 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 detailed parameter descriptions in Chinese (e.g., '项目空间Id' for ProjectId, '数据质量监控对象' for Target). The tool description adds no parameter-specific information beyond what the schema already provides. According to the rules, when schema coverage is high (>80%), the baseline score 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新数据质量监控' (Update data quality monitoring) is a tautology that essentially restates the tool name 'UpdateDataQualityEvaluationTask' in Chinese. It lacks specificity about what aspects of data quality monitoring are being updated (e.g., rules, triggers, notifications) and doesn't distinguish this tool from its sibling 'UpdateDataQualityRule' or 'CreateDataQualityEvaluationTask'. The mention of an MCP Resource is procedural guidance, not purpose clarification.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing evaluation task ID), differentiate from sibling tools like 'UpdateDataQualityRule' (which updates individual rules) or 'CreateDataQualityEvaluationTask', or specify scenarios where updating is appropriate (e.g., modifying triggers vs. rules). The MCP Resource note is about tool invocation, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. '修改数据源' (Modify data source) implies a mutation operation but provides no information about permissions required, whether changes are destructive or reversible, rate limits, error conditions, or what happens when the operation completes. This is completely inadequate 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three Chinese characters, this is a case of severe under-specification rather than effective brevity. The description fails to provide any meaningful information that would help an AI agent understand or use the tool correctly, making it inefficient despite its short length.
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?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is completely inadequate. It provides no information about what the tool actually does, when to use it, what behaviors to expect, or what results are returned. The agent would be operating almost blindly with only the parameter schema as guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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%, meaning all 5 parameters are documented in the input schema itself. The description adds no parameter information beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting. However, it doesn't compensate with any additional context about parameter relationships or usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '修改数据源' (Modify data source) is a tautology that essentially restates the tool name 'UpdateDataSource' without providing any meaningful elaboration. It doesn't specify what aspects of a data source are modified, what resources are involved, or how this differs from sibling tools like 'CreateDataSource' or 'CloneDataSource'.
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?
The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or distinctions from similar tools like 'CreateDataSource' (for initial creation) or 'CloneDataSource' (for duplication). The agent receives zero usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states '更新任务' (Update task), which implies a mutation but gives no details on permissions required, side effects (e.g., if updates affect running instances), rate limits, or response format. This is inadequate for a complex update tool with 19 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified with only '更新任务' (Update task), which is not conciseness but a lack of content. The additional note about an 'MCP Resource' is irrelevant to tool understanding and adds clutter without value, failing to front-load useful information.
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?
Given the tool's complexity (19 parameters, nested objects, no output schema, and no annotations), the description is completely inadequate. It does not explain the scope of updates, behavioral implications, or usage context, leaving the agent with insufficient information to invoke the tool correctly beyond 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 schema already documents all parameters thoroughly (e.g., 'Id' as task ID, 'Trigger' with detailed subproperties). The description adds no parameter information beyond what the schema provides, meeting 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新任务' (Update task) is a tautology that merely restates the tool name 'UpdateTask' in Chinese. It does not specify what resource is being updated (e.g., a task in a workflow system) or distinguish it from sibling tools like 'BatchUpdateTasks' or 'UpdateTaskInstances', leaving the purpose vague and undifferentiated.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a task ID), exclusions, or compare it to sibling tools like 'BatchUpdateTasks' for multiple updates or 'UpdateTaskInstances' for instance-level modifications, offering no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description fails to mention that this is a mutation operation, what permissions are required, whether updates are partial or complete, how conflicts are handled, or what the response looks like. For a complex update tool with 12 parameters, this lack of behavioral information is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While brief, the description is under-specified rather than concise. The first part '更新工作流' is a tautology, and the second part about the MCP Resource doesn't help the agent understand the tool's purpose or usage. The structure doesn't front-load essential information, and the sentences don't earn their place by adding value.
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?
Given the tool's complexity (12 parameters, nested objects, no annotations, no output schema), the description is completely inadequate. It doesn't explain what a workflow is in this context, what fields can be updated, whether updates are partial or complete, what happens to existing workflow instances, or what the tool returns. The description fails to compensate for the lack of annotations and 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 schema already documents all parameters thoroughly. The description adds no parameter information beyond what's in the schema. According to the guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新工作流' (Update workflow) is a tautology that restates the tool name 'UpdateWorkflow' without adding any meaningful context. It doesn't specify what aspects of a workflow are updated, what resources are involved, or how this differs from other workflow-related tools like 'UpdateWorkflowDefinition' or 'UpdateTask'.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, distinguish from sibling tools like 'UpdateWorkflowDefinition' or 'UpdateTask', or indicate appropriate contexts. The only additional text references an MCP Resource for examples, which doesn't constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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. '克隆' (clone) implies a write operation that creates a copy, but the description doesn't specify whether this requires special permissions, what happens to the original data source, if there are rate limits, or what the output looks like (since no output schema exists). For a mutation tool with zero annotation coverage, this lack of behavioral details is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with just two Chinese characters, the description is under-specified rather than efficiently informative. It fails to front-load essential context and doesn't earn its place by adding value beyond the tool name. True conciseness balances brevity with usefulness, which this lacks.
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 (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't explain what cloning entails, what gets copied (e.g., configurations, connections), or what the result looks like. For a tool that likely creates a new resource, more context is needed to guide the agent 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?
Schema description coverage is 100%, with clear documentation for both parameters ('Id' and 'CloneDataSourceName') in the input schema. The description adds no parameter-specific information beyond what the schema already provides. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even without param details in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '克隆数据源' (Clone data source) is a tautology that merely restates the tool name 'CloneDataSource' in Chinese. It provides no additional specificity about what cloning entails, what resources are involved, or how it differs from sibling tools like 'CreateDataSource' or 'UpdateDataSource'. The purpose is stated but lacks distinguishing details.
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?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing data source), compare it to 'CreateDataSource' for new data sources, or specify scenarios where cloning is appropriate (e.g., duplicating configurations). Without any usage context, the agent must infer everything 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.
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. '删除数据源' only indicates a deletion action without specifying whether this is reversible, what permissions are required, whether it cascades to dependent resources, or what the response looks like. For a destructive operation with zero annotation coverage, this is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three Chinese characters, this is under-specification rather than effective conciseness. The description fails to provide necessary context for a destructive operation. Every sentence should earn its place, but here the single phrase doesn't provide enough value to justify its existence as a helpful description.
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?
For a destructive deletion tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what a data source is in this system, what the deletion entails, whether there are dependencies or cascading effects, what permissions are required, or what confirmation/response to expect. Given the complexity and risk of a deletion operation, this description fails to provide necessary 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 description has 0 parameters mentioned, but the input schema has 1 parameter with 100% description coverage ('数据源ID，数据源的唯一标识符' - Data source ID, unique identifier of the data source). Since schema coverage is high and no parameters are described in the tool description, the baseline score of 4 is appropriate as the schema adequately documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除数据源' (Delete data source) is a tautology that restates the tool name 'DeleteDataSource' in Chinese. It provides the basic verb+resource but lacks specificity about what constitutes a data source in this context or how this deletion differs from other deletion tools like DeleteDataServiceApi or DeleteDIJob. It doesn't distinguish itself from siblings beyond the literal translation.
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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple deletion tools in the sibling list (DeleteAlertRule, DeleteDataServiceApi, DeleteDIJob, etc.), but the description offers no context about prerequisites, when this specific deletion is appropriate, or what happens after deletion. It's completely lacking usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to indicate whether this is a read-only query, an asynchronous poll, or has side effects. It doesn't describe error conditions, rate limits, authentication needs, or what happens if the operation is incomplete. The description is too vague to inform the agent about 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase that is under-specified rather than concise. It lacks structure and fails to front-load critical information. While brief, it doesn't earn its place by adding value beyond the tool name, making it inefficient for agent comprehension.
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 querying asynchronous operation results and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the result contains, how to interpret it, or handle edge cases. For a tool that likely returns status or outcome data, this minimal 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?
Schema description coverage is 100%, with the single parameter 'OperationId' fully documented in the schema. The description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取创建工作流实例结果' (Get create workflow instance result) is a tautology that restates the tool name in Chinese. It doesn't specify what action is performed (e.g., 'retrieve', 'fetch', 'query') or clarify what type of result is obtained. While it mentions 'workflow instance', it doesn't distinguish this from sibling tools like 'GetWorkflowInstance' or 'ListWorkflowInstances'.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an OperationId from CreateWorkflowInstances), appropriate contexts, or exclusions. The agent must infer usage from the parameter description alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does at a basic level ('get upstream task list') without mentioning any behavioral traits like pagination behavior, permissions required, rate limits, or what constitutes an 'upstream task'. This leaves significant gaps for a tool with 4 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single phrase, this is under-specification rather than effective conciseness. The description doesn't provide enough information to be useful, failing to earn its place as an adequate 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 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'upstream tasks' means in this context, how results are structured, or any behavioral aspects. For a list operation with filtering parameters, more context 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 description coverage is 100%, so the schema already documents all 4 parameters (Id, ProjectEnv, PageSize, PageNumber) with descriptions. The tool description adds no additional parameter information beyond what's in the schema, meeting the baseline of 3 when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取上游任务列表' (Get upstream task list) is a tautology that essentially restates the tool name 'ListUpstreamTasks' in Chinese. While it indicates the tool lists something (upstream tasks), it doesn't specify what resource or scope it operates on, nor does it differentiate from sibling tools like 'ListDownstreamTasks' or 'ListTasks'.
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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of context, prerequisites, or comparison to sibling tools like 'ListDownstreamTasks' or 'ListTasks' that might serve similar purposes. The agent receives no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but offers none. It doesn't indicate whether this is a read-only operation, what permissions might be required, whether it supports pagination (though parameters suggest it does), what the return format looks like, or any rate limits. The description is completely silent on behavioral traits 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (one short phrase), this is under-specification rather than effective conciseness. The description fails to provide any meaningful context that would help an AI agent understand when and how to use this tool. Every sentence should earn its place, but this single phrase doesn't provide enough value.
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 10 parameters, no annotations, and no output schema, the description is severely inadequate. It doesn't explain the tool's purpose beyond the obvious, provides no usage context, and offers no behavioral information. While the schema covers parameter documentation well, the description fails to compensate for the lack of annotations and output schema 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%, with all 10 parameters well-documented in the input schema. The description adds no additional parameter information beyond what's already in the schema. According to the rules, when schema coverage is high (>80%), the baseline score 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取工作流实例列表' (Get workflow instance list) is a tautology that essentially restates the tool name 'ListWorkflowInstances' in Chinese. While it correctly identifies the verb ('get/list') and resource ('workflow instances'), it doesn't differentiate from sibling tools like 'ListWorkflowDefinitions' or 'GetWorkflowInstance', nor does it specify scope or filtering capabilities beyond what the name implies.
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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple related tools in the sibling list (e.g., 'GetWorkflowInstance', 'ListWorkflowDefinitions', 'ListTaskInstances'), but the description offers no context about when this specific list operation is appropriate versus single-instance retrieval or other list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only states the action ('get workflow list') without any information about permissions required, rate limits, pagination behavior (implied by parameters but not described), or what the output contains. This is inadequate for a tool with 9 parameters and 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '获取工作流列表', which is overly concise to the point of under-specification. While it's not verbose, it fails to provide necessary context and structure, making it inefficient for an AI agent to understand the tool's purpose and usage beyond the 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?
Given the complexity (9 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's behavior, output format, or differentiation from siblings. The high schema coverage helps with parameters, but the overall context for effective tool selection and invocation is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 fully documents all 9 parameters. The description adds no additional parameter semantics beyond what's in the schema. According to the rubric, with high schema coverage (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取工作流列表' (Get workflow list) is a tautology that restates the tool name 'ListWorkflows' without adding specificity. It doesn't distinguish this tool from sibling list tools like ListWorkflowDefinitions or ListWorkflowInstances, nor does it specify what kind of workflows or what scope is involved. It's minimally functional but lacks differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like ListWorkflowDefinitions and ListWorkflowInstances, there's no indication of how this tool differs in purpose or context. No prerequisites, exclusions, or comparative usage hints are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states the action ('创建' - create) without any behavioral context: it doesn't mention permissions required, whether this is a mutating operation (implied but not stated), what happens on success/failure, rate limits, or side effects. For a creation tool with complex parameters, this lack of transparency is a critical gap.
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 brief (one sentence plus a meta-note) but not optimally structured. The core purpose is stated upfront, but the MCP Resource note is extraneous to the agent's understanding and disrupts flow. While concise, it lacks the density of information needed for a complex tool, making it under-specified rather than efficiently informative.
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 (5 parameters with nested objects, no output schema, no annotations), the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral expectations. The schema handles parameter details, but the description fails to provide the necessary context for a creation operation in a monitoring system, leaving significant gaps in understanding how to use it 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?
Schema description coverage is 100%, providing detailed documentation for all parameters. The description adds no parameter information beyond the schema. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description. The description doesn't compensate or add value, but the schema adequately covers parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建自定义监控告警规则' (Create custom monitoring alert rule) states the basic verb and resource but is vague about scope and lacks sibling differentiation. It doesn't specify what kind of monitoring (e.g., data pipeline, task instances) or how it differs from other alert-related tools like CreateDIAlarmRule, UpdateAlertRule, or DeleteAlertRule. The purpose is clear at a high level but insufficiently specific for an AI agent to distinguish 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 Guidelines1/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 prerequisites (e.g., existing monitoring targets), when to choose CreateAlertRule over UpdateAlertRule, or how it relates to sibling tools like CreateDIAlarmRule. The note about MCP Resource is a meta-instruction for tool usage, not contextual guidance for the agent. 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.
Behavior1/5
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 but fails completely. It doesn't indicate whether this is a read or write operation (though 'Create' implies mutation), what permissions are required, whether it's idempotent, what happens on failure, or any rate limits. The description provides zero behavioral context beyond the basic action implied by 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (two sentences) but under-specified rather than appropriately concise. The first sentence is a tautology that adds no value, and the second sentence is meta-instruction about MCP Resources rather than tool functionality. While it's not verbose, it fails to use its limited space effectively to convey meaningful information about the 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?
Given the tool's complexity (10 parameters with nested objects, no annotations, no output schema), the description is severely inadequate. It doesn't explain what a 'data quality evaluation task' entails, what happens after creation, how it relates to other data quality tools, or what the expected outcomes are. For a creation tool with significant parameter complexity and no structured behavioral hints, the description provides almost no contextual 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 10 parameters thoroughly. The description adds no parameter information whatsoever - it doesn't mention any parameters, their purposes, or relationships. However, with complete schema coverage, the baseline score is 3 even without parameter details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建数据质量监控' (Create data quality monitoring) is a tautology that restates the tool name 'CreateDataQualityEvaluationTask' in Chinese. It lacks specificity about what resource is being created (a task for evaluating data quality) and doesn't distinguish it from sibling tools like 'CreateDataQualityEvaluationTaskInstance' or 'CreateDataQualityRule'. The description provides no meaningful verb+resource combination beyond the 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 Guidelines1/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. It doesn't mention sibling tools like 'CreateDataQualityRule' or 'CreateDataQualityEvaluationTaskInstance', nor does it provide any context about prerequisites, appropriate scenarios, or exclusions. The second sentence is purely meta-instruction about MCP Resources, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description reveals nothing about whether this is a read-only operation, whether it requires specific permissions, what format the output takes, or any side effects. For a tool with no annotation coverage, this complete lack of behavioral information is inadequate.
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 extremely concise (one Chinese phrase) but under-specified rather than efficiently informative. While it doesn't waste words, it fails to provide the minimal necessary information about what the tool actually does. Conciseness without substance doesn't earn 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 complexity of data management systems implied by sibling tools, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'collection information' includes, what the return format is, or how this differs from related collection operations. For a tool in this context with rich sibling functionality, the description should provide more orientation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 single parameter 'Id' is documented as '集合对象Id' - collection object ID), so the schema does the heavy lifting. The description adds no additional parameter context beyond what's in the schema, such as where to find this ID or format requirements. With 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取数据地图集合信息' (Get data map collection information) is a tautology that essentially restates the tool name 'GetMetaCollection' in Chinese. It doesn't specify what action is performed (retrieve details? list contents? get metadata?) or what resource is targeted beyond the vague 'collection information'. It fails to distinguish this from sibling tools like 'ListMetaCollections' or 'GetMetaCollection' (if there were multiple get operations).
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?
The description provides absolutely no guidance on when to use this tool versus alternatives. With sibling tools like 'ListMetaCollections' (likely for listing all collections) and 'GetMetaCollection' requiring a specific ID, there's no indication whether this tool retrieves metadata, contents, or something else about a single collection. No prerequisites, context, 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.
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. '移动' (move) implies a mutation operation, but the description doesn't specify whether this requires special permissions, whether the move is reversible, what happens to dependencies, or what the expected outcome is. It provides minimal behavioral context beyond the basic action implied by 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is technically concise (only 7 Chinese characters), it's under-specified rather than efficiently informative. A single phrase doesn't provide enough context for the tool's purpose or usage. The description fails to earn its place by providing meaningful guidance to an AI agent.
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, the description is inadequate. It doesn't explain what 'moving a function' entails operationally, what the expected outcome is, or how this differs from other move operations. Given the complexity of moving development functions and the lack of structured behavioral information, the description should provide more 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 schema description coverage is 100%, with all three parameters clearly documented in the input schema. The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '移动数据开发函数路径' (Move data development function path) is a tautology that essentially restates the tool name 'MoveFunction' in Chinese. It doesn't specify what type of function is being moved (UDF function), what resource it operates on, or how it differs from sibling tools like MoveNode, MoveResource, or MoveWorkflowDefinition. The purpose is vague and doesn't provide meaningful differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple 'Move' sibling tools (MoveNode, MoveResource, MoveWorkflowDefinition), but the description doesn't explain when to choose MoveFunction over these other options, nor does it mention any prerequisites or constraints for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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. '重跑任务实例' implies a mutation (rerunning tasks), but it doesn't describe what 'rerun' entails—whether it restarts failed instances, resets state, requires specific permissions, has side effects on dependencies, or affects workflow execution. The description lacks any behavioral details beyond the basic action, leaving critical operational traits unspecified.
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—a single phrase in Chinese—and front-loaded with the core action. There is no wasted verbiage or unnecessary elaboration. However, this conciseness borders on under-specification, as it omits useful context that could aid understanding, slightly reducing its effectiveness despite efficient 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?
Given the tool's complexity (a mutation operation with potential side effects), lack of annotations, and absence of an output schema, the description is incomplete. It doesn't explain what 'rerun' means operationally, what states task instances must be in, how dependencies are handled, or what the tool returns. For a mutation tool with no structured behavioral hints, the description fails to provide sufficient context for safe and effective 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 has 100% description coverage, with clear documentation for 'Ids' (task instance ID list) and 'Comment' (remark information). The description adds no parameter semantics beyond what the schema provides, such as explaining ID formats, comment purposes, or usage constraints. Since schema coverage is high, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation without needing description supplementation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '重跑任务实例' (Rerun task instances) is a tautology that essentially restates the tool name 'RerunTaskInstances' in Chinese. It doesn't specify what 'rerun' entails operationally, what types of task instances are affected, or how this differs from similar tools like 'ResumeTaskInstances' or 'SetSuccessTaskInstances' in the sibling list. While it indicates the action and target, it lacks specificity about the operation's scope or mechanism.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., task instances must be in a failed or stopped state), exclusions, or comparisons to sibling tools like 'ResumeTaskInstances', 'StopTaskInstances', or 'UpdateTaskInstances'. Without such context, an AI agent cannot determine appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but offers none. It doesn't indicate whether this is a read or write operation (though 'resume' implies mutation), what permissions are required, whether it's idempotent, what happens to task state, or what the expected outcome is. For a tool that presumably changes system state, this is critically 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 extremely concise - just three Chinese characters that directly convey the core action. There's no wasted verbiage or unnecessary elaboration. While this conciseness comes at the cost of completeness, as a standalone attribute, it's maximally efficient.
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?
For a tool with 2 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what 'resuming' entails, when to use it, what behavioral characteristics it has, or what to expect as a result. Given the complexity of task instance management and the lack of structured metadata, this description fails to provide the necessary context for effective tool 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 ('Ids' and 'Comment') having clear descriptions in Chinese. The tool description adds no additional parameter information beyond what the schema already provides. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description contributes zero value regarding parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '恢复任务实例' (Resume task instances) is a tautology that essentially restates the tool name 'ResumeTaskInstances' in Chinese. While it indicates the action (resume) and resource (task instances), it lacks specificity about what 'resume' means in this context and doesn't differentiate from sibling tools like 'RerunTaskInstances', 'StartWorkflowInstances', or 'StopTaskInstances' that also manipulate task/workflow instances.
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?
The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple sibling tools that manipulate task instances (RerunTaskInstances, StopTaskInstances, SuspendTaskInstances, SetSuccessTaskInstances), but the description offers no context about when resuming is appropriate versus rerunning, stopping, or other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states '更新质量规则' (Update quality rule) which implies a mutation operation but provides no information about permissions required, whether the update is partial or complete, what happens to existing configurations, error handling, rate limits, or what the response looks like. For a complex mutation tool with 10 parameters and nested objects, this complete lack of behavioral context is inadequate.
Agents need to know what a tool does to the world before calling it. 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 phrase '更新质量规则' (Update quality rule) which is extremely concise with zero wasted words. While this under-specifies the tool's functionality, it's not verbose or poorly structured. Every word earns its place, though more content would be needed for adequacy.
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?
Given the tool's complexity (10 parameters with nested objects, mutation operation, no annotations, no output schema), the description is completely inadequate. It doesn't explain what a 'quality rule' is in the DataWorks context, what fields can be updated, what the typical update workflow looks like, or what happens after invocation. For such a complex tool, the single-phrase description fails to provide the necessary context for an AI agent to use it 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 schema description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds no parameter information beyond what's already in the schema - it doesn't explain relationships between parameters, provide examples of common configurations, or clarify which parameters are most important. With complete schema coverage, the baseline score of 3 is appropriate since the description doesn't add value but also doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新质量规则' (Update quality rule) is a tautology that restates the tool name 'UpdateDataQualityRule' without providing any meaningful elaboration. It doesn't specify what resource is being updated (DataWorks quality rules), what fields can be modified, or how this differs from sibling tools like 'CreateDataQualityRule' or 'DeleteDataQualityRule'. The purpose is stated but lacks specificity and differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. There are sibling tools like 'CreateDataQualityRule', 'DeleteDataQualityRule', 'GetDataQualityRule', and 'ListDataQualityRules', but the description offers no comparison or context about when updating is appropriate versus creating new rules or using read operations. No prerequisites, constraints, or typical use cases are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 '更新' (update), implying a mutation, but fails to describe critical behaviors: whether this requires specific permissions, if it's idempotent, what happens on partial updates, error conditions, or side effects (e.g., stopping/restarting jobs). For a complex update tool with 8 parameters, this lack of behavioral context is a major 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 concise with two sentences, but the second sentence ('*This Tool has a 'MCP Resource'...') is meta-commentary that doesn't help the agent understand the tool's purpose or usage. The first sentence is direct, but overall structure could be improved by front-loading more useful information instead of the MCP note.
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 (8 parameters with nested objects, no annotations, no output schema), the description is inadequate. It doesn't explain what a 'data integration sync job' entails, what fields are updatable, or what the update operation returns. The schema handles parameter documentation, but the description fails to provide the necessary contextual framing for this 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 documents all 8 parameters thoroughly with examples and enum values. The description adds no parameter-specific information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新数据集成同步任务' (Update data integration sync job) is a tautology that essentially restates the tool name 'UpdateDIJob' in Chinese. It lacks specificity about what aspects of the job are updated (e.g., settings, mappings, resources) and doesn't distinguish this update tool from other DI-related tools like CreateDIJob or StartDIJob in the sibling list. The purpose is stated but overly vague.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing DI job ID), exclusions, or compare it to sibling tools like CreateDIJob (for creation) or UpdateTask (for general task updates). The second sentence is a meta-instruction about MCP Resources, not usage guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 but offers none. It doesn't indicate whether this is a mutating operation (implied by 'update' but not explicit), what permissions are required, whether changes are reversible, or what happens on success/failure. For a tool that modifies data development nodes, this lack of behavioral context 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 extremely concise - a single Chinese phrase. While this represents under-specification rather than ideal conciseness, according to the scoring framework, conciseness evaluates whether every sentence earns its place. Here, the single phrase doesn't waste words, so it scores high on this dimension despite being inadequate overall.
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?
Given the tool's complexity (updating nodes with a detailed Spec schema), absence of annotations, and no output schema, the description is completely inadequate. It doesn't explain what 'updating' entails, what fields can be modified, what the response looks like, or any behavioral aspects. For a mutation tool with rich parameter schema but no other structured guidance, this minimal description fails to provide 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?
Schema description coverage is 100%, so the schema already documents all three parameters (ProjectId, Id, Spec) thoroughly. The description adds no additional meaning about parameters beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新数据开发节点信息' (Update data development node information) is a tautology that essentially restates the tool name 'UpdateNode' in Chinese. It doesn't specify what 'update' means operationally or what aspects of the node are being updated. While it mentions the resource ('data development node'), it lacks a specific verb or scope that distinguishes it from sibling tools like 'UpdateTask' or 'UpdateWorkflowDefinition'.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing node), exclusions, or compare it to similar tools like 'CreateNode', 'DeleteNode', or 'RenameNode'. The agent receives no contextual cues about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. '批量更新任务' implies a batch mutation operation, but it does not specify whether this is idempotent, requires specific permissions, has rate limits, or what happens on partial failures. The mention of 'MCP Resource' for examples hints at additional context but does not itself disclose 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 brief ('批量更新任务') but under-specified, not truly concise. The additional sentence about 'MCP Resource' adds meta-instruction without enhancing tool understanding, making it somewhat inefficient. It is front-loaded but lacks substance.
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 (batch update tool with no annotations and no output schema), the description is inadequate. It does not explain what 'batch' entails (e.g., atomicity, error handling), the expected return values, or how it differs from single-update tools. The schema covers parameters well, but the description fails to provide necessary 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 has 100% description coverage, with detailed documentation for all parameters (e.g., 'Tasks' array with nested objects like 'EnvType', 'Trigger', 'RuntimeResource'). The description adds no parameter semantics beyond the schema, so it meets 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '批量更新任务' (Batch update tasks) is a tautology that restates the tool name in Chinese without adding specificity. It mentions a 'MCP Resource' for examples, but this is meta-instruction rather than clarifying the tool's purpose. It does not distinguish this tool from sibling tools like 'UpdateTask' or 'UpdateTaskInstances', leaving the scope and differentiation unclear.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions, and the reference to 'MCP Resource' for examples is not actionable usage advice. With many sibling tools (e.g., 'UpdateTask', 'UpdateTaskInstances'), this lack of differentiation 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action ('register') without disclosing behavioral traits like whether this is a write operation, what permissions are required, what happens on success/failure, or if there are side effects. For a creation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 phrase with zero wasted words. It's appropriately sized for what it conveys, though what it conveys is minimal. Every word earns its place in this brief statement.
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 creation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what a lineage relationship is, what format the parameters should be in, what the expected outcome is, or how this differs from related operations. The context demands more guidance for proper tool 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%, with all three parameters (SrcEntity, DstEntity, Task) having Chinese descriptions in the schema. The tool description adds no parameter information beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '注册数据地图血缘关系' (Register data map lineage relationship) restates the tool name 'CreateLineageRelationship' in Chinese without adding specificity. It doesn't clarify what 'register' entails operationally or distinguish this from sibling tools like GetLineageRelationship or DeleteLineageRelationship. This is essentially a tautology in another language.
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 versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or exclusions. Given sibling tools like GetLineageRelationship and DeleteLineageRelationship exist, the absence of differentiation 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. '创建权限申请单' implies a write operation (creating an application), but it doesn't specify whether this submits for approval, requires admin review, has side effects (e.g., pending state), or what happens on failure. It mentions an MCP Resource for examples, but this doesn't clarify behavioral traits like permissions needed, rate limits, or idempotency. The description is minimal and lacks critical context 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief with two sentences, but the second sentence is a meta-comment about MCP Resources that doesn't contribute to tool understanding. The first sentence is under-specified rather than concise. While not verbose, it fails to front-load essential information, making it inefficient for its 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?
Given a mutation tool with 10 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the tool's behavior, output, error conditions, or dependencies (e.g., project settings). The high schema coverage helps, but for a complex write operation, more context is needed about how the creation process works and what to expect after 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 80%, so the schema already documents most parameters well (e.g., ApplyUserIds, ApplyReason, ApplyObject). The description adds no additional meaning about parameters beyond what's in the schema. With high coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract from the schema's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建权限申请单' (Create permission application order) is a tautology that restates the tool name in Chinese. It doesn't specify what resource the permission applies to (MaxCompute tables), what actions are involved (Select, Describe, etc.), or how it differs from sibling tools like 'ApprovePermissionApplyOrder' or 'ListPermissionApplyOrders'. The purpose is vague beyond the literal translation of 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 Guidelines1/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 prerequisites (e.g., needing specific project settings like labelSecurity), exclusions, or relationships to sibling tools such as 'ApprovePermissionApplyOrder' for approval or 'GetPermissionApplyOrderDetail' for details. The second sentence is a meta-instruction about MCP Resources, not usage guidance for the tool itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does at a surface level ('get list'), without mentioning any behavioral traits: no indication of whether this is a read-only operation, potential side effects, authentication requirements, rate limits, pagination behavior (despite pagination parameters), error conditions, or output format. This leaves critical operational context completely undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions 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 - a single phrase in Chinese that directly states the tool's function. There's no wasted language, repetition, or unnecessary elaboration. While it's under-informative, it's not verbose or poorly 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 tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'downstream' means operationally, doesn't describe the return format or structure, and provides no behavioral context. For a listing tool with pagination parameters, the description should at minimum clarify the listing scope and output expectations, which it fails to do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 in the schema itself (Id, ProjectEnv, PageSize, PageNumber). The description adds no additional parameter semantics beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取下游任务列表' (Get downstream task list) is a tautology that essentially restates the tool name 'ListDownstreamTasks' in Chinese. While it indicates the tool lists something (tasks), it doesn't specify what distinguishes 'downstream' tasks from other task types or clarify the exact resource scope. Compared to sibling tools like 'ListTasks' or 'ListUpstreamTasks', the differentiation is minimal beyond the directional qualifier.
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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing a task ID), appropriate contexts, or comparisons to similar tools like 'ListTasks', 'ListUpstreamTasks', or 'ListDownstreamTaskInstances'. The agent receives zero directional information about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. The description only states it queries details but doesn't reveal whether this is a read-only operation, what format/details are returned, whether authentication is required, or any error conditions. For a tool with zero annotation coverage, this minimal description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase. While this is efficient, it's arguably under-specified rather than appropriately concise. However, it does front-load the core purpose without unnecessary elaboration, earning a 4 rather than a 5 due to the borderline under-specification.
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 no annotations, no output schema, and a single parameter, the description is inadequate. It doesn't explain what 'details' are returned, what format they're in, or any behavioral characteristics. While the parameter is well-documented in the schema, the overall context for using this tool effectively 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 description coverage is 100% with the single parameter 'Code' documented as '规则模版Code' (rule template Code). The description doesn't add any parameter information beyond what's in the schema. With high schema coverage, the baseline score of 3 is appropriate since the schema already provides adequate parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询质量规则模版详情' (Query quality rule template details) is a tautology that essentially restates the tool name 'GetDataQualityRuleTemplate' in Chinese. It provides a verb ('查询' - query) and resource ('质量规则模版' - quality rule template), but lacks specificity about what 'details' means and doesn't distinguish this tool from its sibling 'ListDataQualityRuleTemplates' which presumably lists templates rather than getting details of a specific one.
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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate versus 'ListDataQualityRuleTemplates', or any context about required permissions or system state. The agent must infer usage purely from the name and parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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. The description '获取API测试结果' only states the action without revealing any behavioral traits: it doesn't indicate if this is a read-only operation, what permissions are required, whether it returns synchronous or asynchronous results, error handling, or rate limits. For a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '获取API测试结果', which is extremely concise and front-loaded with the core action. There is no wasted text, but it may be overly terse given the lack of context. It earns a high score for efficiency, though it borders on under-specification.
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 (a tool for retrieving API test results), no annotations, and no output schema, the description is incomplete. It doesn't explain what the results contain, how they are formatted, or any behavioral aspects like error cases. The schema covers the parameter well, but the description fails to provide necessary context for effective use, especially for a tool that likely returns structured 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?
The input schema has 1 parameter with 100% description coverage, detailing that 'TestId' comes from 'TestDataServiceApi' or 'ListDataServiceApiTest'. The description adds no additional parameter information beyond what the schema provides. With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't detract from the well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取API测试结果' (Get API test results) is a tautology that essentially restates the tool name 'GetDataServiceApiTest' in Chinese. It specifies the verb '获取' (get) and resource 'API测试结果' (API test results), but doesn't distinguish this from sibling tools like 'TestDataServiceApi' or 'SaveDataServiceApiTestResult' beyond the basic action. The purpose is clear at a surface level but lacks specificity about what kind of results or 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. The description doesn't mention prerequisites (e.g., needing a TestId from 'TestDataServiceApi' or 'ListDataServiceApiTest'), exclusions, or comparisons to sibling tools like 'GetDataServiceApi' or 'GetDataServicePublishedApi'. Usage is implied through the parameter description in the schema, but the description itself offers no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states it's a query/list operation, but doesn't disclose whether this is paginated (though parameters suggest it is), what permissions are required, rate limits, what format results are returned in, or whether this is a read-only operation. For a tool with 10 parameters and no annotations, this is a significant gap in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase. While this might seem efficient, it's actually under-specified rather than appropriately concise. However, it doesn't waste words or have unnecessary structure. Given the scoring framework, this earns a 4 for being front-loaded and not verbose, though it borders on being too 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 10 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what 'quality results' are, what the tool returns, how results are structured, or when to use it versus similar sibling tools. The minimal description fails to provide the necessary context for an AI agent 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.
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 all 10 parameters well-documented in Chinese. The tool description adds no parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询质量结果列表' (Query quality results list) is a tautology that essentially restates the tool name 'ListDataQualityResults' in Chinese. It doesn't specify what 'quality results' refer to (data quality evaluation results), what resource is being listed, or how this differs from sibling tools like ListDataQualityEvaluationTasks or ListDataQualityRules. The purpose is vague and lacks specific verb+resource differentiation.
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?
The description provides absolutely no guidance on when to use this tool versus alternatives. With many sibling tools related to data quality (ListDataQualityEvaluationTasks, ListDataQualityRules, ListDataQualityEvaluationTaskInstances, GetDataQualityEvaluationTaskInstance), there's no indication of when this specific listing tool is appropriate versus those other options. No context, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states it's a query/list operation, implying read-only behavior, but doesn't disclose pagination behavior (implied by PageSize/PageNumber parameters), rate limits, authentication needs, or what the output format looks like (no output schema). This is inadequate for an 8-parameter tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese. It's front-loaded with the core action ('查询' - query) and resource ('数据地图血缘关系列表' - data map lineage relationship list), though it lacks depth. No wasted words, but it's overly terse given the tool's complexity.
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, no annotations, and no output schema, the description is insufficient. It doesn't explain the purpose of lineage relationships, how filtering works (e.g., with SrcEntityId/DstEntityId), pagination behavior, or what the output contains. This leaves significant gaps for an AI agent to understand and use the tool 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?
Schema description coverage is 100%, with all parameters documented in Chinese (e.g., '源实体ID' for SrcEntityId). The description adds no additional parameter semantics beyond what the schema provides, such as explaining relationships between SrcEntityId/DstEntityId or how fuzzy matching works for SrcEntityName/DstEntityName. 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询数据地图血缘关系列表' (Query data map lineage relationship list) restates the tool name 'ListLineageRelationships' in Chinese, making it essentially a tautology. It doesn't specify what 'lineage relationships' are, what 'data map' refers to, or how this differs from sibling tools like 'GetLineageRelationship' or 'ListLineages'.
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 on when to use this tool versus alternatives. The description doesn't mention any context, prerequisites, or comparisons to sibling tools like 'GetLineageRelationship' (which likely retrieves a single relationship) or 'ListLineages' (which might list lineage entities rather than relationships).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. '保存' (save) implies a write/mutation operation, but the description doesn't disclose whether this requires specific permissions, whether it overwrites existing test results, what happens on success/failure, or any rate limits. For a mutation tool with zero annotation coverage, this represents a significant gap in behavioral transparency. The description doesn't contradict annotations (none exist), but provides 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase in Chinese. While this represents under-specification rather than ideal conciseness, the description itself contains no wasted words or redundant information. It's front-loaded with the core action, though it lacks any supporting context. The extreme brevity prevents structural issues but comes at the cost of completeness.
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 this is a mutation tool (implied by 'save') with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after saving, what format the saved results take, whether the operation is idempotent, or how it relates to the testing workflow. The 100% schema coverage helps with parameters, but the overall context for using this tool remains incomplete. For a write operation in what appears to be a data service API testing system, more guidance 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 description coverage is 100%, meaning all 5 parameters have descriptions in the schema itself. The tool description adds no additional parameter information beyond what's already documented in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no parameter information in the description. The description doesn't compensate for any gaps because there are none in the schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '保存API测试结果' (Save API test results) is a tautology that essentially restates the tool name 'SaveDataServiceApiTestResult' in Chinese. It provides a basic verb+resource combination but lacks specificity about what kind of API test results are being saved, for what purpose, or how this differs from related tools like 'TestDataServiceApi' or 'GetDataServiceApiTest'. The purpose is minimally stated without meaningful differentiation 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or relationship to other tools like 'TestDataServiceApi' (which likely generates test results) or 'GetDataServiceApiTest' (which might retrieve test results). The agent receives no help in determining when this save operation is appropriate versus other data service API operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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. The description only states what the tool does ('执行临时工作流实例') without any information about permissions required, whether it's a read or write operation, what happens upon execution (e.g., does it trigger immediate runs, create instances, or modify state?), error handling, or rate limits. For a complex execution tool with 6 parameters and no annotations, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence in Chinese, but it's under-specified rather than efficiently informative. The second sentence about the 'MCP Resource' adds clutter without clarifying the tool's purpose or usage—it's meta-commentary about examples rather than helpful description. While brief, it fails to front-load critical information and includes a sentence that doesn't earn its place in the core 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's complexity (6 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't address what the tool returns, how errors are handled, or the implications of executing an 'adhoc' workflow (e.g., is it ephemeral, does it persist results?). The description lacks context about workflow systems, making it inadequate for an agent to understand the full scope of this execution 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 parameters are documented in the input schema with descriptions. The tool description adds no parameter information beyond what's in the schema—it doesn't explain relationships between parameters (e.g., how Tasks array relates to Name and Owner), provide examples, or clarify semantics like what '临时' (adhoc) means for parameter values. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 '执行临时工作流实例' (Execute ad-hoc workflow instance) provides a basic verb+resource combination, indicating it runs workflow instances. However, it's vague about what constitutes an 'ad-hoc' workflow versus regular workflows, and doesn't distinguish this tool from sibling tools like 'CreateWorkflowInstances' or 'StartWorkflowInstances' that also handle workflow execution. The purpose is understandable but lacks 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?
The description offers no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to workflow execution (e.g., 'CreateWorkflowInstances', 'StartWorkflowInstances', 'StopWorkflowInstances'), but the description doesn't explain when 'adhoc' execution is appropriate or what differentiates it from other workflow tools. Usage is implied only by the name 'Adhoc', but no explicit context 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.
Behavior2/5
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 implies a read operation ('获取' meaning 'get'), but doesn't specify whether it requires authentication, returns structured data, has rate limits, or what happens if the workflow doesn't exist. For a tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 Chinese phrase that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the core action. Every word earns its place in conveying the basic intent.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what 'workflow details' include, how results are structured, or any behavioral constraints. While the schema covers parameters well, the description fails to provide necessary context about the operation's scope, output, or 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%, with both parameters ('Id' and 'EnvType') clearly documented in the schema. The description adds no parameter-specific information beyond what the schema already provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取工作流的详情' (Get workflow details) is a tautology that essentially restates the tool name 'GetWorkflow' in Chinese. It doesn't specify what 'details' include or differentiate this tool from similar siblings like 'GetWorkflowDefinition' or 'GetWorkflowInstance'. While it indicates a read operation, it lacks specificity about the resource scope or content.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a workflow ID), differentiate from sibling tools like 'ListWorkflows' or 'GetWorkflowDefinition', or specify appropriate contexts. The agent must infer usage solely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. The description only states it's a list operation, which implies it's likely read-only, but doesn't confirm this or provide any other behavioral context. There's no information about pagination behavior (though parameters suggest it), rate limits, authentication requirements, error conditions, or what the return format looks like. For a listing 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase that directly states the tool's purpose. There's zero wasted verbiage or unnecessary elaboration. While this conciseness comes at the cost of completeness, from a pure conciseness perspective, every word 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 that this is a listing tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. The agent needs to understand what 'downstream' means in this context, how results are structured, whether there are pagination considerations beyond the parameters, and how this differs from other listing tools. The single-phrase description fails to provide this necessary context for proper tool 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, with all three parameters clearly documented in Chinese. The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取下游任务实例列表' (Get downstream task instances list) is a tautology that essentially restates the tool name 'ListDownstreamTaskInstances' in Chinese. It doesn't provide any additional specificity about what constitutes 'downstream' or what kind of task instances are being listed. While it's clear this is a list operation, it doesn't distinguish itself from sibling tools like ListTaskInstances or ListUpstreamTaskInstances beyond the directional qualifier.
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?
The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate versus other listing tools, or any contextual constraints. The agent would have to infer usage from the tool name alone, which is insufficient for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. '获取资源组列表' implies a read-only listing operation, but it doesn't disclose any behavioral traits like pagination behavior (implied by PageSize/PageNumber parameters), authentication requirements, rate limits, error conditions, or what happens when filters return no results. For a tool with 10 parameters and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. While this conciseness comes at the cost of completeness, the description itself is perfectly structured 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 tool with 10 parameters, no annotations, and no output schema, the single-phrase description is completely inadequate. The agent needs to understand not just what the tool does, but how to use it effectively - what filters are available, how pagination works, what the response format looks like, and when to choose this over other listing tools. The description fails to provide this 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 description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取资源组列表' (Get resource group list) is a tautology that essentially restates the tool name 'ListResourceGroups' in Chinese. It specifies the verb 'get/list' and resource 'resource groups', but lacks any differentiation from sibling tools or specific context about what makes this listing operation unique. While it states a basic purpose, it doesn't provide meaningful distinction.
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?
The description provides absolutely no guidance on when to use this tool versus alternatives. There are many other 'List*' sibling tools (like ListProjects, ListResources, ListWorkflows), but no indication of when this specific resource group listing is appropriate, what prerequisites exist, or what scenarios it's designed for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states it 'queries' schemas without indicating whether this is a read-only operation, if it requires authentication, what the output format might be, or if there are rate limits. For a tool with 8 parameters including pagination, this lack of behavioral context 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase. While this is technically efficient, it's under-specified rather than appropriately concise. The single sentence doesn't waste words but also doesn't provide meaningful guidance. It's front-loaded by default since there's only one phrase, but the brevity comes at the cost of usefulness.
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, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'schemas' mean in this context, what the tool returns, or how results are structured. The agent would need to infer behavior from the parameter names alone, which is insufficient for proper tool 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%, meaning all parameters are documented in the input schema with detailed descriptions. The tool description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询数据地图数据库模式列表' (Query data map database schema list) is a tautology that essentially restates the tool name 'ListSchemas' in Chinese. It provides a generic verb 'query' without specifying what kind of schemas are being listed or distinguishing this tool from other list tools like ListTables, ListDatabases, or ListFunctions. The purpose is vague and lacks specific 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 doesn't mention prerequisites, context for filtering schemas, or relationships to other tools like GetSchema (which likely retrieves a single schema). With many sibling list tools available, the absence of usage differentiation leaves the agent guessing about appropriate application scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states that it updates meta collection objects, without mentioning required permissions, whether the operation is idempotent, what happens to unspecified fields, error conditions, or response format. For a mutation tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase that directly states the tool's action. There's no wasted language or unnecessary elaboration. While it's arguably too brief for a mutation tool, it earns full marks for conciseness as every word serves a 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 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'updating' entails, what fields can be modified, whether there are constraints on updates, or what the tool returns. The description fails to compensate for the lack of structured metadata, leaving significant gaps in understanding 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.
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 all 4 parameters clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新数据地图集合对象' is a tautology that essentially restates the tool name 'UpdateMetaCollection' in Chinese. It provides the verb '更新' (update) and resource '数据地图集合对象' (meta collection object), but doesn't specify what aspects can be updated or distinguish this from sibling tools like 'CreateMetaCollection' or 'DeleteMetaCollection'. The purpose is minimally stated but lacks specificity.
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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to meta collections (CreateMetaCollection, DeleteMetaCollection, AddEntityIntoMetaCollection, RemoveEntityFromMetaCollection, ListMetaCollections, GetMetaCollection, ListEntitiesInMetaCollection), but the description offers no context about when this update operation is appropriate versus creating new collections or modifying entities within collections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states it modifies properties, implying a mutation operation, but doesn't disclose critical behavioral traits: whether this requires specific permissions, if changes are reversible, what happens to existing properties not mentioned, rate limits, or what the response looks like. For a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase ('修改任务实例属性'), which is front-loaded and wastes no words. While this conciseness comes at the cost of detail, it efficiently communicates the core action without unnecessary elaboration.
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 (mutation operation with nested parameters in 'TaskInstances'), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects, usage context, or output expectations, leaving significant gaps for an AI agent to understand how to invoke it correctly in relation to 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?
Schema description coverage is 100%, so the schema already documents both parameters ('Comment' and 'TaskInstances') and their nested properties thoroughly. The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter relationships, constraints, or usage examples. With 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '修改任务实例属性' (Modify task instance properties) is a tautology that essentially restates the tool name 'UpdateTaskInstances' in Chinese. While it indicates the tool updates task instances, it doesn't specify what properties can be modified or distinguish it from sibling tools like 'UpdateTask' or 'BatchUpdateTasks'. The purpose is vague beyond the basic verb-noun pairing.
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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools that modify tasks or task instances (e.g., 'UpdateTask', 'BatchUpdateTasks', 'RerunTaskInstances'), but the description offers no context about when this specific tool is appropriate, what prerequisites might exist, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. '创建' (create) implies a write/mutation operation, but the description fails to disclose critical traits: whether this requires specific permissions, if it's idempotent (despite ClientToken hinting at it), what happens on success/failure, rate limits, or side effects. For a creation tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase in Chinese ('创建数据集成同步任务') that directly states the action. It is appropriately sized and front-loaded with no redundant information. However, it lacks structural elements like separating purpose from context, which slightly limits clarity but doesn't waste space.
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 (creation operation with 6 parameters, no annotations, no output schema), the description is incomplete. It fails to explain what the tool returns, error conditions, or how it integrates with the broader system (e.g., DataWorks workspace context). For a mutation tool with rich parameters but no structured behavioral hints, the description should provide more context 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?
Schema description coverage is 100%, so the input schema already documents all 6 parameters thoroughly. The description adds no parameter semantics beyond what the schema provides—it doesn't explain relationships between parameters (e.g., how TaskType influences TaskContent), usage examples, or constraints. Baseline 3 is appropriate as the schema does the heavy lifting, but the description contributes no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建数据集成同步任务' is a direct translation of the tool name 'CreateDISyncTask' (Create Data Integration Sync Task) with no additional specificity. It restates the name/title without distinguishing what makes this tool unique among sibling tools like CreateDIJob, CreateDataQualityEvaluationTask, or CreateWorkflowDefinition. No verb+resource combination or scope details are provided beyond the tautological restatement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 (e.g., needing a ProjectId), exclusions, or comparisons with sibling tools like CreateDIJob or CreateWorkflowDefinition. The agent must infer usage solely from the tool name and parameters 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. '创建发布流程' implies a write/mutation operation, but it doesn't specify whether this is destructive (e.g., affects existing pipeline runs), requires specific permissions, has side effects (like triggering executions), or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits 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 extremely concise—a single phrase in Chinese—with zero wasted words. It's front-loaded and appropriately sized for what it conveys, though it's under-specified rather than truly concise. Every word earns its place, but there are too few words to be helpful.
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 (a mutation tool for pipeline runs with 4 parameters) and lack of annotations or output schema, the description is incomplete. It doesn't explain what a 'pipeline run' or 'release process' entails in this system, what the tool returns, or behavioral expectations. The agent must rely entirely on the input schema, which is insufficient for safe and effective 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%, so the schema fully documents all four parameters (ProjectId, Type, ObjectIds, Description) with details like enums for Type and constraints for ObjectIds. The description adds no parameter information beyond what's in the schema, meeting 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建发布流程' (Create release process) is a tautology that essentially restates the tool name 'CreatePipelineRun' in Chinese. It doesn't specify what resource is being created (pipeline run for what system?), what 'release process' means in this context, or how it differs from sibling tools like 'ExecPipelineRunStage' or 'GetPipelineRun'. The purpose is vague and lacks 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 about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a project or existing entities), when this is appropriate versus other creation tools (like 'CreateWorkflowInstances'), or any constraints beyond what's implied by parameters. The agent must infer usage solely from the input schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. '删除' (delete) implies a destructive mutation, but the description doesn't specify whether deletion is permanent/reversible, what permissions are required, whether it affects dependent resources, or what happens on success/failure. For a destructive operation with zero annotation coverage, this is a significant gap in safety and operational context.
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 - a single Chinese phrase that directly states the action. There's no wasted verbiage or unnecessary elaboration. However, this conciseness comes at the cost of completeness, as it provides minimal contextual information beyond the basic 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 destructive deletion tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'data development function' means in this context, what the deletion consequences are, or what the agent should expect as a result. The description fails to provide the necessary context for safe and informed tool invocation, especially given the tool's destructive 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?
Schema description coverage is 100%, with both parameters clearly documented: ProjectId (DataWorks workspace ID) and Id (UDF function unique identifier). The description adds no parameter information beyond what the schema provides. Since the schema does the heavy lifting, the baseline score of 3 is appropriate - the description neither compensates for gaps nor adds meaningful context about parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除数据开发函数' (Delete data development function) is a tautology that restates the tool name 'DeleteFunction' in Chinese. It specifies the verb (delete) and resource (data development function) but doesn't distinguish this from sibling tools like DeleteNode, DeleteResource, or DeleteWorkflowDefinition that also delete different resources. The purpose is clear at a basic level but lacks differentiation from similar deletion 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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing to identify the function first), consequences of deletion, or when other deletion tools might be more appropriate. The agent must infer usage purely from the tool name and parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states it retrieves role details without specifying whether this is a read-only operation (likely, but not confirmed), what authentication or permissions are required, whether there are rate limits, or what format the return data takes. For a tool with no annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase that directly states the tool's purpose. While it lacks detail, it's not verbose or poorly structured. Every word contributes to the core meaning, though more content would be needed for completeness.
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 no annotations, no output schema, and a minimal description, the contextual information is inadequate. The description doesn't explain what 'role details' include, how the result is structured, or any behavioral constraints. For a tool that presumably returns structured role information, more context about the return format and usage constraints would be 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?
The schema description coverage is 100%, with both parameters clearly documented in the input schema. The description adds no additional parameter information beyond what the schema already provides. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取工作空间角色详情' (Get workspace role details) is a tautology that essentially restates the tool name 'GetProjectRole' in Chinese. While it indicates the tool retrieves information about roles, it doesn't specify what kind of details are retrieved or distinguish this from sibling tools like 'ListProjectRoles' or 'GetProjectMember' that also deal with project roles and members. The purpose is vague beyond the basic retrieval concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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's no mention of when this specific 'get details' operation is appropriate compared to 'ListProjectRoles' (which likely lists multiple roles) or 'GetProjectMember' (which deals with individual members rather than role definitions). The agent receives no contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. '查询标签列表' only indicates a query operation but doesn't disclose whether this is read-only, paginated behavior (though schema hints at pagination), authentication requirements, rate limits, or what happens when no tags exist. For a list tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just four Chinese characters. While this could be considered under-specified rather than optimally concise, it's front-loaded with the core action and contains no redundant information. Every character earns its place, though more content would be beneficial.
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 moderate complexity (4 parameters, list operation) and the absence of both annotations and output schema, the description is inadequate. It doesn't explain what the tool returns, how results are structured, or provide context about data asset tags. For a list tool with no output schema, the description should at minimum indicate the nature of 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 schema already documents all 4 parameters (Category, PageSize, PageNumber, Key) with their descriptions. The tool description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询标签列表' (query tag list) is a tautology that essentially restates the tool name 'ListDataAssetTags' in Chinese. While it indicates a listing/querying action on tags, it doesn't specify what kind of tags (data asset tags) or differentiate this tool from other list tools in the sibling set like ListDataQualityRules or ListDataSources. The purpose is vague and lacks 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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context for tag listing, or comparison with other list tools. The agent must infer usage from the name alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states it's a query/list operation, but doesn't mention pagination behavior (though parameters suggest it), authentication requirements, rate limits, whether results are filtered or complete, or what the output format looks like. For a tool with 7 parameters and no output schema, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase. While this is efficient, it's arguably under-specified rather than appropriately concise. However, it doesn't waste words or have structural issues. Given the schema does heavy lifting, the brevity isn't necessarily problematic for conciseness alone.
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 7 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'data map databases' are, how results are structured, what authentication is needed, or typical usage patterns. The schema covers parameter mechanics but the description fails to provide necessary context for an agent 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.
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 itself. The description adds no additional parameter information beyond what's already in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone, though the description contributes nothing extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询数据地图数据库列表' (Query data map database list) is a tautology that essentially restates the tool name 'ListDatabases' in Chinese. It doesn't specify what kind of databases (metadata databases, data catalogs, etc.) or provide any distinguishing context from sibling tools like ListCatalogs, ListSchemas, or ListTables. The purpose is vague beyond the obvious 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?
No guidance is provided about when to use this tool versus alternatives. With many sibling list tools (ListCatalogs, ListSchemas, ListTables, etc.), the description doesn't indicate whether this is for listing databases within a specific parent entity, for general database discovery, or how it relates to other listing tools. There's no mention of prerequisites, exclusions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states it's a query/list operation, which implies read-only behavior, but doesn't disclose any behavioral traits like pagination behavior (implied by parameters but not stated), rate limits, authentication requirements, or what happens when no rules match. For a list tool with 6 parameters and no annotations, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions 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 - a single 4-character phrase. While it's under-specified in terms of content, it's not verbose or poorly structured. Every character serves the purpose of stating the basic operation, making it maximally efficient in terms of word count.
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, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (quality rule objects with what fields?), doesn't mention the pagination behavior that's implied by PageNumber/PageSize parameters, and doesn't provide context about the data quality system. For a list tool in a complex data management system, this minimal description leaves too many 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 already documents all 6 parameters thoroughly with Chinese descriptions. The tool description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询质量规则列表' (Query quality rule list) is a tautology that essentially restates the tool name 'ListDataQualityRules' in Chinese. It provides a basic verb+resource but lacks specificity about what kind of quality rules or what system they belong to. It doesn't distinguish this tool from sibling list tools like ListDataQualityRuleTemplates or ListDataQualityEvaluationTasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 are multiple sibling tools related to data quality (ListDataQualityRuleTemplates, ListDataQualityEvaluationTasks, ListDataQualityResults), but the description doesn't help differentiate them. No context about prerequisites, typical use cases, or when this specific listing is appropriate is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. '获取数据源列表' implies a read-only list operation, but it doesn't specify whether this is paginated, what the return format is, or any rate limits or authentication requirements. For a tool with 9 parameters and no output schema, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase ('获取数据源列表'), which is appropriately sized for a simple list operation. It's front-loaded with the core purpose, though this brevity comes at the cost of completeness. Every word earns its place by stating the basic 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 tool's complexity (9 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, pagination behavior, or how filtering works with multiple parameters. For a list tool with rich filtering options, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 9 parameters well-documented in the input schema (e.g., ProjectId, Order, Types). The description adds no additional parameter semantics beyond what's already in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取数据源列表' (Get data source list) is a tautology that essentially restates the tool name 'ListDataSources' in Chinese. It specifies the verb ('获取' - get) and resource ('数据源列表' - data source list), but doesn't differentiate from sibling tools like 'ListDataServiceApis' or 'ListDataQualityRules' beyond the resource type. The purpose is clear but lacks specificity about scope or 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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling list tools (e.g., ListDataServiceApis, ListDataQualityRules), there's no indication of context, prerequisites, or exclusions. The agent must infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states it 'gets a list' without explaining whether this is a read-only operation, if it requires specific permissions, how results are paginated (though parameters suggest pagination), or what the output format looks like. For a tool with 10 parameters and no annotation coverage, this leaves critical behavioral traits undocumented.
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, efficient sentence in Chinese ('获取工作空间详情列表') that is front-loaded and wastes no words. However, it's overly concise to the point of under-specification, lacking necessary detail for a tool with 10 parameters. While structurally sound, it fails to provide adequate context.
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 (10 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's behavior, output format, or usage context. The schema handles parameter documentation well, but the description fails to provide the broader context needed for an AI agent 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are well-documented in the input schema itself. The description adds no additional meaning about parameters beyond what's already in the schema (e.g., it doesn't clarify relationships between parameters like Names and Ids). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取工作空间详情列表' (Get workspace details list) is a tautology that essentially restates the tool name 'ListProjects' in Chinese. It specifies the resource ('workspace details') but lacks a clear verb beyond 'get' and doesn't distinguish this tool from other list operations in the sibling tools (e.g., ListDataSources, ListFunctions, ListWorkflows). The purpose is vague about what kind of listing this performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With many sibling tools that also list resources (e.g., ListDataSources, ListFunctions), there's no indication of what makes this tool unique or when it should be selected. No prerequisites, exclusions, or comparative context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states it queries a list, implying a read-only operation, but doesn't mention any behavioral traits such as pagination behavior (implied by parameters but not described), rate limits, authentication needs, or what the output looks like. It lacks details on what 'data map' means or any constraints on the query.
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 in Chinese with no wasted words. It's front-loaded and to the point, though it could be more informative. The brevity is appropriate but borders on under-specification.
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 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the purpose beyond the name, lacks usage context, and fails to describe behavioral aspects or output format. For a list tool with multiple filtering and pagination parameters, 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.
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 8 parameters thoroughly with descriptions, examples, and constraints. The description adds no additional meaning beyond the schema, as it doesn't reference any parameters or provide context for their use. Baseline is 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询数据地图数据表列表' (Query data map table list) is a tautology that essentially restates the tool name 'ListTables' in Chinese. It provides the basic verb 'query' and resource 'table list', but lacks specificity about what kind of tables or context. It doesn't distinguish this tool from other list tools like ListDatabases, ListSchemas, or ListTasks in the 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 is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, context, or exclusions. Given the sibling tools include other list operations (e.g., ListDatabases, ListSchemas), there's no indication of how this tool fits into a hierarchy or when it should be selected over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions '获取或搜索' (get or search), implying a read-only operation, but doesn't clarify if it's safe, idempotent, or has side effects. It omits details like pagination behavior (implied by parameters but not described), rate limits, authentication needs, or what happens on errors, leaving significant gaps 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, efficient sentence in Chinese, making it appropriately concise. However, it lacks front-loading of critical information—it doesn't immediately clarify what 'topics' are or the tool's scope, which slightly reduces effectiveness despite the brevity.
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 (9 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain the return values, error handling, or the nature of 'topics' (e.g., whether they are data events, incidents). With no annotations to cover behavioral aspects, the description fails to provide sufficient context for safe and effective 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%, so the input schema fully documents all 9 parameters with details like formats, constraints, and mutual exclusivity (e.g., InstanceId vs. NodeId). The description adds no additional meaning beyond the schema, such as explaining the relationship between 'topics' and parameters like 'TopicStatuses' or 'TopicTypes'. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取或搜索事件列表' (Get or search event list) is vague and tautological—it essentially restates the tool name 'ListTopics' in Chinese. It doesn't specify what 'topics' or 'events' refer to (e.g., data quality events, workflow events), nor does it differentiate from siblings like 'ListAlertMessages' or 'ListWorkflowInstances', leaving the purpose unclear beyond a generic listing 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. With siblings such as 'ListAlertMessages' and 'ListWorkflowInstances', the description fails to indicate whether this tool is for a specific type of events (e.g., data topics, incidents) or under what conditions it should be preferred, offering 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action ('test connectivity') without disclosing behavioral traits such as whether it's read-only or mutative, what permissions are required, what the output includes (e.g., success/failure details, latency), or any side effects (e.g., logging, triggering alerts). For a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('测试数据源的连通性') with no wasted words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details if expanded.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'testing connectivity' means operationally, what the return values or error conditions are, or how it differs from other data source tools. For a tool with three parameters and potential complexity in testing scenarios, this is 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 schema already documents all three parameters (ResourceGroupId, DataSourceId, ProjectId) with descriptions. The tool description adds no additional meaning about parameters, such as how they interact or format specifics. 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '测试数据源的连通性' (Test data source connectivity) states the general purpose but is vague. It doesn't specify what 'testing connectivity' entails (e.g., network check, authentication verification, or performance test) or what resource it operates on beyond 'data source'. Compared to siblings like 'GetDataSource' or 'CreateDataSource', it doesn't clearly differentiate its 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 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 prerequisites (e.g., after creating a data source), exclusions, or related tools like 'GetDataSource' for status checks. The description alone offers no context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states the purpose without any behavioral traits: it doesn't indicate if this is a read-only operation, what permissions are required, whether it's idempotent, what happens on invalid input, or the format of the output. This is a significant gap for a tool with no 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, efficient phrase in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste, making it highly concise and well-structured for its minimal 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?
Given the complexity of lineage relationships and the lack of annotations and output schema, the description is incomplete. It doesn't explain what a lineage relationship entails, what data is returned, or any behavioral aspects. For a tool with no structured support, the description should provide more context to be useful, but it falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 the single parameter 'Id' documented as '血缘关系ID' (lineage relationship ID). The description adds no additional meaning beyond this schema, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 '获取数据地图血缘关系' (Get data map lineage relationship) states a general purpose but lacks specificity. It identifies the resource (lineage relationship) and implies retrieval (get), but doesn't specify what aspect of lineage relationships is obtained (e.g., details, structure, or metadata) or how it differs from sibling tools like ListLineageRelationships or GetLineage. It's vague but not tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 prerequisites, context, or exclusions, and fails to differentiate from sibling tools such as ListLineageRelationships (which likely lists multiple) or GetLineage (which might retrieve lineage for a different entity). No explicit or implied usage instructions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. '审批' (approve) implies a write/mutation operation that likely changes the state of a permission application, but the description doesn't specify behavioral traits such as required permissions, whether the action is reversible, potential side effects, or error conditions. For a mutation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '审批权限申请单', which is extremely concise and front-loaded with the core action. However, it might be overly terse, potentially sacrificing clarity for brevity. It earns a high score for efficiency but loses a point because it could benefit from slightly more elaboration to enhance understanding 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?
Given the tool's complexity as a mutation operation (approving permissions) with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after approval (e.g., state changes, notifications, return values), error handling, or dependencies. For a tool that modifies system state, more contextual information 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.
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 documented in the input schema: 'FlowId' (application order ID), 'ApproveComment' (approval comment), and 'ApproveAction' (approval action with values 1 for agree and 2 for refuse). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '审批权限申请单' (Approve permission application order) states the action ('approve') and the target resource ('permission application order'), which gives a basic understanding of purpose. However, it doesn't specify what 'approve' entails operationally or distinguish this from other permission-related tools like 'CreatePermissionApplyOrder' or 'GetPermissionApplyOrderDetail' in the sibling list. The purpose is clear but lacks specificity about the approval process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 prerequisites (e.g., needing an existing permission application order), exclusions, or comparisons to other tools like 'CreatePermissionApplyOrder' or 'ListPermissionApplyOrders'. Without such context, an agent might struggle to determine the appropriate scenario 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a mutation ('associate'), but doesn't disclose behavioral traits such as required permissions, whether the association is reversible, error handling, or side effects. For a tool that likely modifies configurations, this lack of transparency 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, efficient sentence with no wasted words. It's front-loaded with the core action, though it could be more specific. The structure is straightforward, but the brevity contributes to vagueness rather than clarity.
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 (3 parameters, mutation implied, no output schema), the description is incomplete. It lacks details on behavior, output, error cases, and how it fits with siblings like CreateDataQualityEvaluationTask. Without annotations or output schema, the description should provide more context to guide effective 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 clear parameter descriptions in Chinese. The tool description adds no additional meaning beyond the schema, such as explaining relationships between parameters or usage examples. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 '关联数据质量规则与数据质量监控' translates to 'Associate data quality rules with data quality monitoring', which states the tool's purpose but is vague. It doesn't specify what 'associate' means (e.g., attach, link, configure) or clarify the relationship between rules and monitoring tasks. Compared to siblings like CreateDataQualityEvaluationTask or CreateDataQualityRule, it lacks differentiation in action 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing rules or tasks), exclusions, or related tools like UpdateDataQualityEvaluationTask. Without context, an 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.
Behavior2/5
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 '创建' (create) implying a write/mutation operation, but doesn't disclose behavioral traits like permissions needed, whether this triggers immediate execution, if it's idempotent, or what happens on failure. For a creation tool with zero annotation coverage, this leaves critical gaps in understanding its 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 Chinese phrase that's front-loaded and wastes no words. However, it's overly terse for a tool with 4 parameters and no annotations, potentially sacrificing clarity for brevity. Every word earns its place, but more context might be needed.
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 (4 parameters including nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what the created instance represents, how it relates to the task ID, what the expected outcome is, or any error conditions. For a creation tool in a data quality system, this leaves too much 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 adds no additional parameter semantics beyond what's in the schema (e.g., no explanation of how Parameters JSON interacts with the task, or what ProjectId context is needed). With high schema coverage, baseline 3 is appropriate as the description doesn't enhance parameter understanding.
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 '创建数据质量校验监控实例' (Create data quality evaluation monitoring instance) states the action and resource but is vague about what this actually does. It doesn't specify whether this instantiates a monitoring job, schedules an evaluation, or creates a configuration. Compared to sibling tools like 'CreateDataQualityEvaluationTask' and 'GetDataQualityEvaluationTaskInstance', the distinction is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With siblings like 'CreateDataQualityEvaluationTask' (likely for creating the task definition) and 'ListDataQualityEvaluationTaskInstances' (for listing instances), there's no indication of the relationship or when this specific creation tool is appropriate. 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.
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. While '创建' (create) implies a write/mutation operation, the description doesn't disclose any behavioral traits: no information about permissions required, whether this is idempotent (despite ClientToken parameter suggesting it might be), rate limits, side effects, or what happens on success/failure. The MCP Resource mention doesn't add 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just one Chinese sentence stating the purpose, followed by an English note about the MCP Resource. While the MCP Resource note adds some length, the core description is front-loaded and wastes no words. However, the bilingual nature creates minor structural awkwardness.
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 creation tool with 8 parameters (4 required), nested objects, no annotations, and no output schema, the description is inadequate. It doesn't explain what gets created, the response format, error conditions, or system implications. The schema handles parameter documentation, but the description fails to provide the contextual completeness needed for a mutation operation 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?
The input schema has 100% description coverage with detailed parameter documentation in Chinese. The tool description adds no parameter information beyond what's already in the schema. With complete schema coverage, the baseline is 3 - the schema does all the work, and the description doesn't compensate or add additional semantic context about parameter relationships or usage patterns.
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 '创建数据集成同步任务告警规则' (Create data integration sync task alarm rule), which clearly indicates the verb (create) and resource (alarm rule for data integration sync tasks). However, it doesn't differentiate from sibling tools like 'CreateAlertRule' or 'UpdateDIAlarmRule' - it's unclear how this specific alarm rule creation differs from general alert rule creation or updating existing DI alarm rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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's no mention of prerequisites, when this should be used instead of 'CreateAlertRule' or 'UpdateDIAlarmRule', or any context about required permissions or system state. The only additional text references an MCP Resource for examples, which doesn't constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. '创建' (create) implies a write operation, but the description doesn't disclose behavioral traits like permissions required, whether it's idempotent, error handling, or what happens on success/failure. For a mutation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('创建数据开发函数'), which is appropriately sized and front-loaded. There's no wasted text, though it could be more informative. It earns its place but lacks depth.
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 function (a mutation with 2 parameters) and has no annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects, usage context, or what to expect after invocation. For a creation tool in a data development environment, more context is needed to guide the agent 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?
Schema description coverage is 100%, with both parameters (ProjectId and Spec) documented in the schema. The description doesn't add any meaning beyond the schema—it doesn't explain parameter relationships, provide examples, or clarify the Spec format. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建数据开发函数' (Create data development function) states the action (create) and resource (data development function), which is clear. However, it doesn't specify what type of function (UDF) or distinguish it from sibling tools like CreateNode or CreateResource, which also create resources. The purpose is understandable but lacks 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 doesn't mention prerequisites (e.g., needing a ProjectId), exclusions, or related tools like UpdateFunction or DeleteFunction. 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.
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 states '创建' (create), implying a write operation, but doesn't mention permissions, side effects, or response format. This is inadequate for a mutation tool, as it misses critical details like whether changes are reversible or what the tool returns.
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, efficient sentence in Chinese, '创建数据地图集合对象', which is front-loaded and wastes no words. It's appropriately sized for its purpose, though it could be more informative 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?
Given the tool is a mutation (create) with no annotations and no output schema, the description is incomplete. It doesn't explain behavioral traits, return values, or usage context. For a 4-parameter tool that creates objects, this leaves significant gaps in understanding how 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 schema description coverage is 100%, so the schema already documents all parameters (Name, Type, ParentId, Description) with descriptions. The tool description adds no additional meaning beyond the schema, such as examples or constraints. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
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 '创建数据地图集合对象' (Create data map collection object) states the action (create) and resource (data map collection object), which is clear. However, it doesn't differentiate from sibling tools like 'CreateMetaCollection' vs 'CreateNode' or 'CreateResource', leaving the specific purpose vague regarding what makes a 'data map collection object' unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 lacks context about prerequisites, such as when a data map collection is needed, or exclusions, like not using it for other types of objects. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'delete,' implying a destructive mutation, but doesn't specify whether this is permanent, requires specific permissions, has side effects (e.g., cascading deletions), or provides confirmation. For a destructive 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the action. It's appropriately sized for a simple delete operation, with no wasted words. However, it could be more front-loaded with critical details (e.g., 'Permanently delete a meta-collection by its ID'), but as-is, it's concise 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?
Given the tool's complexity (a destructive delete operation), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permanence, permissions, or error handling, nor does it explain return values. For a mutation tool with no structured support, the description should do more to fill these 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, with the parameter 'Id' documented as '集合对象Id' (collection object Id). The description doesn't add any meaning beyond this, such as format examples or where to find the ID. With high schema coverage, the baseline is 3, as the schema does the heavy lifting, and the description doesn't compensate with extra details.
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 '删除数据地图集合对象' (Delete data map collection object) states the action (delete) and target (data map collection object), providing a basic purpose. However, it's vague about what a 'data map collection object' entails and doesn't differentiate from sibling tools like DeleteMetaCollection vs. DeleteDataServiceApi or DeleteDataSource, which might delete different resource types. It avoids tautology by not just restating 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 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 are many sibling deletion tools (e.g., DeleteDataServiceApi, DeleteDataSource), but it doesn't specify that this is for meta-collections specifically or mention prerequisites like needing the collection ID. Usage is implied only by the tool name and description, with 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.
Behavior2/5
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. While '删除' (delete) implies a destructive mutation, the description doesn't specify whether this deletion is permanent, reversible, requires specific permissions, affects dependent resources, or has confirmation prompts. For a destructive operation with zero annotation coverage, this is a significant gap in safety and operational context.
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, efficient phrase in Chinese that directly states the action. There's no wasted language or unnecessary elaboration. However, it could be slightly more front-loaded with critical context given the destructive nature 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?
Given this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical behavioral aspects (permanence, dependencies, permissions) or provide usage guidance relative to similar tools. The 100% schema coverage helps with parameters, but the overall context for safe and correct use is 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?
The schema description coverage is 100%, with both parameters (ProjectId and Id) clearly documented in the input schema. The description adds no additional parameter information beyond what's already in the schema. According to the rules, when schema coverage is high (>80%), the baseline score 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除数据开发工作流' (Delete data development workflow) clearly states the verb (delete) and resource (data development workflow), which is specific enough to understand the basic action. However, it doesn't distinguish this tool from other deletion tools in the sibling list (like DeleteWorkflow, DeleteTask, DeleteResource, etc.), leaving ambiguity about what specifically is 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 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. With multiple deletion tools available (DeleteWorkflow, DeleteTask, DeleteResource, etc.), there's no indication of what makes a 'workflow definition' different from a 'workflow' or when this specific deletion is appropriate. The description lacks any context about prerequisites, dependencies, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. '执行' (execute) implies a mutation action, but the description does not specify whether this is a read-only operation, what side effects occur (e.g., state changes, resource consumption), or any error conditions. For a mutation 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.
Conciseness4/5
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 action. It is front-loaded with no unnecessary words, making it appropriately concise for its 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?
Given the complexity of executing a pipeline stage (a mutation operation), the lack of annotations, and no output schema, the description is incomplete. It does not cover behavioral aspects like side effects, permissions, or response format, which are critical for an agent to use this tool correctly. The description should provide more context to compensate for missing structured 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 input schema already documents all three parameters (ProjectId, Id, Code) with descriptions. The description does not add any meaning beyond what the schema provides, such as explaining the relationship between parameters or usage examples. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '执行发布流程的指定阶段' (Execute a specified stage of a release pipeline) states a clear verb ('执行' - execute) and resource ('发布流程的指定阶段' - specified stage of a release pipeline). However, it does not distinguish this tool from sibling tools like 'CreatePipelineRun' or 'GetPipelineRun', which also operate on pipeline runs. The purpose is clear but 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 does not mention prerequisites (e.g., needing a pipeline run ID from 'GetPipelineRun'), exclusions, or comparisons to other pipeline-related tools. 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.
Behavior2/5
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. The description only states what the tool does at a high level ('get details') without explaining what kind of details are returned, whether this is a read-only operation, if it requires specific permissions, or what happens when the catalog doesn't exist. For a retrieval tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 - a single Chinese phrase that directly states the tool's purpose. While this is efficient, it may be too brief given the complexity of the domain. There's no wasted language, but the brevity comes at the cost of completeness. The structure is front-loaded with the core purpose but lacks supporting 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?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'details' are returned, the response format, error conditions, or how this differs from the sibling ListCatalogs tool. Given the data cataloging domain complexity and the presence of a similar sibling tool, more contextual information would be needed for effective tool 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 schema description coverage is 100% with comprehensive documentation of the single 'Id' parameter including format examples for different catalog types. The description adds no parameter information beyond what's already in the schema. Since schema coverage is high, the baseline score of 3 is appropriate - the schema does the heavy lifting while the description doesn't add value but doesn't need to compensate for gaps either.
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 '获取数据地图数据目录详情' translates to 'Get data map data catalog details' which clearly indicates a retrieval operation on a catalog resource. However, it doesn't specify what 'details' include or differentiate this from the sibling tool 'ListCatalogs' which presumably lists multiple catalogs rather than retrieving details of a specific one. The purpose is understandable but lacks specificity about the scope of details returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With a sibling tool 'ListCatalogs' present, there's no indication whether GetCatalog is for single-item retrieval while ListCatalogs is for bulk listing, or if they serve different purposes. No prerequisites, exclusions, or contextual usage information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states what the tool does ('get field information') without mentioning any behavioral traits such as whether it's a read-only operation, requires specific permissions, returns structured data, or has performance considerations. For a tool with no annotations, 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, efficient sentence in Chinese that directly states the tool's function. It's front-loaded with no unnecessary words, making it easy to parse quickly. However, it could be slightly more structured by explicitly mentioning the parameter or output, but given its brevity and clarity, it earns a high score for 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?
Given the complexity of metadata retrieval tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'field information' includes (e.g., data types, constraints), how results are returned, or any prerequisites. With siblings like 'GetTable' and 'ListColumns', more context is needed to distinguish this tool's specific role and 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?
The input schema has 100% description coverage, with one parameter 'Id' documented as 'ID, refer to [metadata entity concept description]'. The description doesn't add any meaning beyond this, such as clarifying what type of ID (e.g., column ID, table ID) or providing examples. Since schema coverage is high, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.
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 '获取数据地图数据表字段信息' (Get data map data table field information) states a purpose but is vague. It specifies the resource ('data map data table field information') but lacks a clear verb beyond 'get' and doesn't differentiate from sibling tools like 'GetTable' or 'ListColumns' that might retrieve related metadata. The purpose is understandable but not precise enough for optimal 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. With siblings like 'GetTable' (for table metadata) and 'ListColumns' (for listing columns), the description doesn't clarify if this tool retrieves detailed field metadata for a specific column or table, or when it should be preferred over other tools. This omission leaves usage context ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 this is a query operation, implying it's read-only, but doesn't confirm if it's safe or has side effects. It also lacks details on authentication needs, rate limits, error handling, or what the response looks like (especially critical since there's 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.
Conciseness4/5
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 ('查询'), though it could be slightly more specific (e.g., clarifying '开发态' means development state). There's no wasted text.
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 (a read operation with 3 parameters, no annotations, and no output schema), the description is incomplete. It doesn't explain what '详情' (details) includes in the response, which is critical for the agent to understand the return value. Without annotations or output schema, the description should provide more behavioral and output context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 three parameters (ProjectId, ApiId, TenantId) with descriptions. The tool description adds no additional parameter information beyond what's in the schema, such as which parameters are required or how they interact. This meets the baseline score of 3 when schema coverage is high.
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 '查询数据服务API开发态的详情' clearly states the action (query) and resource (data service API development details), but it's somewhat vague about what 'development details' specifically entail. It doesn't distinguish this tool from sibling tools like GetDataServiceApiTest or GetDataServicePublishedApi, which also retrieve API-related information but for different states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 prerequisites (e.g., needing a ProjectId or ApiId), nor does it clarify the relationship with sibling tools like GetDataServiceApiTest (for test details) or GetDataServicePublishedApi (for published details), 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.
Behavior2/5
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 states it's a query (read operation) but doesn't mention authentication needs, rate limits, error conditions, or what '发布态信息' specifically includes (e.g., version, status, endpoints). For a tool with 3 parameters and no output schema, this leaves significant gaps in understanding 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 a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple query tool, though it could be slightly more informative 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?
Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what '发布态信息' entails in the response, how to interpret results, or any behavioral nuances. For a query tool in a complex data service context, this leaves too much unspecified for reliable agent 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 description coverage is 100%, with all three parameters (ProjectId, ApiId, TenantId) clearly documented in the schema. The description adds no additional parameter semantics beyond implying it queries based on these IDs. Since the schema does the heavy lifting, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询数据服务API的发布态信息' clearly states the action (查询/query) and resource (数据服务API的发布态信息/published state information of data service APIs), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'GetDataServiceApi' (which likely gets non-published API info) or 'ListDataServicePublishedApis' (which likely lists multiple published APIs), leaving the distinction unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 prerequisites (e.g., needing a published API), exclusions (e.g., not for draft APIs), or comparisons to siblings like 'GetDataServiceApi' or 'ListDataServicePublishedApis', leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action ('view details') without mentioning permissions required, rate limits, response format, or whether it's a read-only operation. This is inadequate for a tool with no annotation coverage, as it lacks critical 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('查看数据源详情'), which is highly concise and front-loaded with the core action. There's no wasted text, but it could be slightly more informative without losing efficiency, such as by adding a brief context or usage hint.
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 data source management and the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'details' include, potential errors, or how it fits into the broader context of sibling tools, leaving gaps in understanding for effective tool 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, with the parameter 'Id' documented as '数据源ID，数据源的唯一标识符' (data source ID, the unique identifier of the data source). The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
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 '查看数据源详情' (view data source details) clearly states the verb ('view') and resource ('data source details'), providing a basic understanding of the tool's purpose. However, it doesn't differentiate from sibling tools like 'ListDataSources' or 'GetDataServiceApi', which also retrieve data source information, making it somewhat vague in comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. It doesn't specify prerequisites (e.g., needing a data source ID), exclusions, or comparisons to siblings like 'ListDataSources' for listing all data sources or 'GetDataServiceApi' for API-related details, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the action ('查看') but doesn't describe traits like whether it's read-only (implied by '查看' but not explicit), pagination behavior (hinted by 'PageNumber' parameter but not explained), error handling, or output format. This is a significant gap for a tool with 6 parameters and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('查看数据集成同步任务的运行日志') that directly states the purpose without waste. It's front-loaded and appropriately sized for a simple tool, though it could be slightly more structured (e.g., by hinting at key parameters).
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 (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values (logs format), behavioral aspects like pagination or read-only nature, or how to interpret parameters like 'NodeType' in context. For a log retrieval tool with multiple inputs, this leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 6 parameters thoroughly (e.g., 'FailoverId', 'Id', 'PageNumber', 'NodeType'). The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters (e.g., 'Id' vs 'DIJobId') or usage examples. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查看数据集成同步任务的运行日志' clearly states the purpose (viewing logs for data integration sync tasks) with a specific verb ('查看') and resource ('运行日志'), but it doesn't distinguish this tool from sibling tools like 'GetTaskInstanceLog' or 'ListTaskInstanceOperationLogs', which might also retrieve logs. It's adequate but 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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., after a job run), or exclusions, leaving the agent to 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.
Behavior2/5
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. The description only states it retrieves details without mentioning: what format the details come in, whether this is a read-only operation (implied but not stated), authentication requirements, rate limits, error conditions, or what happens if the node doesn't exist. For a tool with zero annotation coverage, this is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase in Chinese. While this is efficient and front-loaded, it may be too brief given the lack of other contextual information. However, every word earns its place by stating the core action and target resource 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?
Given that there's no output schema and no annotations, the description should provide more complete context about what this tool returns and how it behaves. The description only states what the tool does at a high level without addressing: the format/structure of returned node details, error handling, authentication needs, or how this differs from related 'Get' and 'List' operations in the sibling toolset. For a tool in a complex data development environment, this is 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 both parameters ('Id' and 'ProjectId') clearly documented in the schema. The description adds no additional parameter information beyond what's already in the schema. According to scoring 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取数据开发节点详情' (Get data development node details) clearly states the verb ('获取' - get) and resource ('数据开发节点详情' - data development node details), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'GetNode' vs 'ListNodes' or 'GetTask' - it's a generic 'get details' operation without specifying what makes this particular 'get' unique in the context of this toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 are many sibling tools with 'Get' prefixes (GetAlertRule, GetCatalog, GetColumn, etc.) and specifically 'ListNodes' exists, but the description doesn't indicate when to retrieve a single node's details versus listing multiple nodes. No prerequisites, constraints, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While '获取' (get) implies a read operation, the description doesn't disclose important behavioral traits: whether this requires specific permissions, what format/details are returned, if there are rate limits, or how errors are handled. For a read operation with zero annotation coverage, this leaves significant gaps in understanding 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase that directly states the tool's purpose. While appropriately sized, it could be considered slightly under-specified rather than optimally concise, as it doesn't provide enough context for optimal tool selection.
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 pipeline run operations in DataWorks, no annotations, no output schema, and many similar sibling tools, the description is incomplete. It doesn't explain what 'details' are returned, how this differs from other pipeline/run retrieval tools, or any behavioral constraints. For a tool that likely returns structured execution data, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 (ProjectId and Id) with their descriptions. The tool description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 '获取发布流程详细信息' (Get release pipeline details) states a clear verb ('获取' - get) and resource ('发布流程详细信息' - release pipeline details), but it's somewhat vague about what 'details' specifically include. It doesn't distinguish this tool from other 'Get' siblings like GetPipelineRunStage or GetWorkflowInstance, which might also retrieve pipeline-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. With many sibling tools like ListPipelineRuns (which likely lists multiple runs) and GetWorkflowInstance (which might retrieve workflow execution details), there's no indication of when this specific tool is appropriate versus those alternatives or what prerequisites might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While '获取' (get) implies a read-only operation, the description doesn't specify authentication requirements, rate limits, error conditions, or what happens if the RemindId doesn't exist. For a tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Chinese phrase that gets straight to the point. There's no wasted language or unnecessary elaboration, though it could potentially benefit from slightly more specificity about what '详情' (details) encompasses.
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 no annotations and no output schema, the description is insufficiently complete. It doesn't explain what information is returned, whether there are any prerequisites for using the tool, or how it differs from similar 'Get' tools in the sibling list. The agent would have significant gaps in understanding how to properly use 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 has 100% description coverage (RemindId is documented as '自定义监控规则的ID' - custom monitoring rule ID), so the schema does the heavy lifting. The description doesn't add any parameter information beyond what's already in the schema, which meets the baseline expectation when schema coverage is high.
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 '获取自定义监控报警规则详情' (Get custom monitoring alarm rule details) clearly states the action (get) and resource (custom monitoring alarm rule details), but it's somewhat vague about what 'details' specifically include. It doesn't distinguish this tool from other 'Get' siblings like GetAlertRule, GetDataQualityRule, or GetDIAlarmRule, which appear to retrieve similar monitoring/alerting 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 guidance on when to use this tool versus alternatives. With many sibling tools that retrieve various monitoring/alerting rules (GetAlertRule, GetDataQualityRule, GetDIAlarmRule), there's no indication of what makes 'custom monitoring alarm rules' different or when this specific tool should be selected over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what the tool does at a high level ('获取数据地图数据库模式信息') without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, what permissions are needed, potential side effects, rate limits, or what format the information is returned in. For a tool with no annotation coverage, this is inadequate.
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, efficient Chinese sentence that directly states the tool's purpose. It's appropriately sized for a simple tool and front-loaded with the core function. There's no wasted verbiage, though it could benefit from slightly more detail given the lack of annotations.
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 apparent complexity (involving data map database schemas) and the complete lack of annotations and output schema, the description is insufficient. It doesn't explain what information is returned, how it's structured, or any prerequisites. For a tool that likely returns metadata or structural information, more context is needed to understand its full behavior and 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 description adds no parameter semantics beyond what's in the input schema. The schema has 100% description coverage for the single parameter 'Id', with detailed format explanation. Since schema coverage is high, the baseline is 3 even without additional param info in the description. The description doesn't compensate or add context about the parameter's role.
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 '获取数据地图数据库模式信息' (Get data map database schema information) states the purpose clearly in Chinese, but it's somewhat vague. It specifies the resource ('数据地图数据库模式信息') but doesn't clarify what '获取' (get) entails - whether it retrieves metadata, structure, or details. It doesn't distinguish from siblings like 'GetCatalog', 'GetDatabase', or 'ListSchemas', which might have overlapping functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With many sibling tools like 'GetCatalog', 'GetDatabase', 'ListSchemas', and 'GetTable', there's no indication of how this tool differs or when it's appropriate. The user must infer usage from the tool name and parameter alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'get' implying a read operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what happens if the task doesn't exist. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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, efficient phrase ('获取任务的详情') with no wasted words. It's appropriately sized for a simple get operation, though it could be more front-loaded with additional context if needed.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'task details' include in the response, error handling, or behavioral constraints. For a tool with 2 parameters and many sibling alternatives, more context is needed to understand its full scope and 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 parameters (Id and ProjectEnv) well-documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取任务的详情' (Get task details) states a clear verb ('get') and resource ('task details'), but it's vague about what 'details' include and doesn't distinguish from sibling tools like GetTaskInstance, GetTaskInstanceLog, or ListTasks. It provides basic purpose but lacks specificity about scope or 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. With many sibling tools related to tasks (GetTaskInstance, ListTasks, UpdateTask, etc.), the description offers no context about prerequisites, when this is appropriate, or what distinguishes it from other task-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While '获取' (get) implies a read-only operation, the description doesn't mention any behavioral traits like authentication requirements, rate limits, error conditions, or what happens when parameters are omitted (since all are optional). For a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase that directly states the tool's purpose without unnecessary words. It's appropriately sized for what it conveys, though it could be more informative given the lack of other guidance.
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 (3 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what 'workflow details' include, how results are structured, or provide any context about the DataWorks platform. For a retrieval tool with optional parameters and no output schema, more completeness is needed to guide the agent 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?
Schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's in the schema (e.g., it doesn't explain parameter relationships or provide examples). With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 '获取数据开发工作流详情' (Get data development workflow details) clearly states the verb ('get') and resource ('workflow details'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'GetWorkflow' or 'GetWorkflowInstance', which appear to retrieve different workflow-related information, leaving the scope somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With sibling tools like 'GetWorkflow', 'GetWorkflowInstance', 'ListWorkflowDefinitions', and 'GetWorkflowDefinition' all available, there's no indication of what distinguishes this specific retrieval operation from the others, 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.
Behavior2/5
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 the tool '获取报警信息的列表' (gets a list of alert messages), implying a read-only operation, but doesn't specify critical behaviors like pagination handling (implied by parameters but not described), rate limits, authentication requirements, or error conditions. For a list tool with 9 parameters and no annotations, 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, efficient sentence ('获取报警信息的列表') that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a basic list operation, though it could be slightly more informative without losing conciseness. There's no wasted verbiage, earning a high score for efficiency.
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 (9 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return format (e.g., structure of alert messages), pagination behavior, or error handling. For a list tool with multiple filtering options and no structured output, the description should provide more context to help an agent understand what to expect and how to use it 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 has 100% description coverage, with each parameter well-documented (e.g., 'PageNumber' for pagination, 'BeginTime' for time range). The description adds no additional parameter semantics beyond what the schema provides, such as explaining relationships between parameters (e.g., 'BaselineId' and 'RemindId' are mutually exclusive based on 'AlertRuleTypes'). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 '获取报警信息的列表' (Get a list of alert messages) clearly states the verb ('获取' - get) and resource ('报警信息的列表' - list of alert messages), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'GetAlertMessage' (which likely retrieves a single alert message) or 'ListAlertRules' (which lists rules rather than messages), leaving room for confusion about when to use this specific 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 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 prerequisites (e.g., required permissions), context (e.g., for monitoring or debugging), or comparisons to siblings like 'GetAlertMessage' (for single messages) or 'ListAlertRules' (for rules). This lack of usage context makes it harder for an agent to decide 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.
Behavior2/5
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. The description only states it queries a list, but doesn't mention pagination behavior (though parameters suggest it), authentication requirements, rate limits, or what happens when no catalogs match. For a tool with 8 parameters and no annotation coverage, this is a significant gap in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase. While this is efficient, it may be too brief for a tool with 8 parameters and complex filtering capabilities. However, it does front-load the core purpose without unnecessary elaboration, earning points for efficiency.
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, no annotations, and no output schema, the description is inadequate. It doesn't explain what a 'data catalog' means in this context, what the return format looks like, or how the various filtering parameters interact. The description should provide more context about the domain and expected usage patterns given 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 documents all 8 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询数据地图数据目录列表' (Query data map data catalog list) states a vague purpose - it mentions querying a list but doesn't specify what kind of catalogs or what the tool actually returns. While it includes the verb 'query' and resource 'data catalog list', it lacks specificity about the domain context (data governance/metadata management) and doesn't distinguish from other list tools like ListDatabases or ListTables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 are many other list tools in the sibling set (ListDatabases, ListTables, ListFunctions, etc.), but the description doesn't explain what makes this catalog listing different or when it should be chosen over other listing tools. No context about prerequisites or typical use cases is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 querying but fails to disclose behavioral traits such as pagination behavior (implied by PageSize/PageNumber), rate limits, authentication needs, or what happens with invalid inputs. This leaves significant gaps for a tool with 7 parameters.
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, efficient sentence in Chinese that directly states the tool's function. It is front-loaded with no wasted words, though it could benefit from slight elaboration to improve clarity 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?
Given the tool's complexity (7 parameters, no annotations, no output schema), the description is incomplete. It lacks details on return values, error handling, or operational context, making it insufficient for an agent to fully understand how to invoke and interpret results 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?
Schema description coverage is 100%, so the schema documents all parameters thoroughly. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 '查询数据地图数据表字段列表' (Query data map data table field list) states the purpose as a query operation for table fields, which is clear but generic. It doesn't specify what distinguishes this tool from similar siblings like 'GetColumn' or 'ListTables', leaving ambiguity about its unique 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. With many sibling tools like 'GetColumn' (singular) and 'ListTables', the description lacks context on selection criteria, prerequisites, or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it's a query operation, but doesn't disclose behavioral traits like pagination behavior (implied by PageSize/PageNumber), return format, rate limits, authentication needs, or whether it's read-only. For a list tool with 11 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.
Conciseness4/5
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. It's appropriately sized for a list operation, though it could be more informative 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?
Given the complexity (11 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, filtering logic, or how parameters interact (e.g., date ranges, pagination). For a data quality monitoring tool with many filtering options, more context 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 description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, meeting 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询质量监控任务实例列表' (Query quality monitoring task instance list) states a clear verb ('查询' - query) and resource ('质量监控任务实例列表' - quality monitoring task instance list), but it's vague about scope and doesn't distinguish from siblings like 'ListDataQualityEvaluationTasks' or 'ListTaskInstances'. It lacks specificity about what exactly is being listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 prerequisites, context, or exclusions, leaving the agent to 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.
Behavior2/5
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 this is a query/list operation, implying it's read-only and non-destructive, but doesn't confirm this explicitly. It lacks details on permissions required, rate limits, pagination behavior (beyond what's in the schema), error conditions, or response format. For a list 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('查询质量监控任务列表') that directly states the tool's purpose without unnecessary words. It's appropriately sized for a basic list operation, though it could be more front-loaded with key distinctions if it were longer. There's no wasted verbiage, earning a high score for 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?
Given the complexity (a list operation with 5 parameters, no annotations, and no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., task details, statuses), how results are structured, or any behavioral nuances. Without annotations or an output schema, the description should provide more context about the operation's scope and results to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 5 parameters (ProjectId, PageSize, PageNumber, TableGuid, Name) with descriptions. The tool description adds no additional parameter information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询质量监控任务列表' (Query quality monitoring task list) clearly states the verb ('query') and resource ('quality monitoring task list'), providing a basic understanding of the tool's function. However, it doesn't differentiate from sibling tools like 'ListDataQualityEvaluationTaskInstances' or 'ListDataQualityRules', which also list related data quality entities. The purpose is clear but lacks specificity about what distinguishes this particular listing 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 prerequisites (e.g., needing a ProjectId), exclusions, or comparisons to sibling tools like 'GetDataQualityEvaluationTask' (for single task details) or 'ListDataQualityEvaluationTaskInstances' (for task instances). Without such context, users 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it 'gets information list' without disclosing behavioral traits like pagination behavior (implied by PageSize/PageNumber parameters but not explained), authentication requirements, rate limits, or what constitutes 'information' in the list. The description is minimal and lacks operational context.
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, efficient sentence in Chinese with no wasted words. It's appropriately concise for a list operation, though it could be more front-loaded with key details (like specifying 'APIs' explicitly).
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 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format, pagination behavior, or error conditions. For a list tool with filtering parameters, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 7 parameters well-documented in the schema itself. The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.
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 '获取数据服务API开发中的信息列表' (Get information list in data service API development) states a general purpose (list information) but lacks specificity about what exactly is being listed (APIs) and doesn't distinguish from many sibling list tools. It's vague about the resource scope compared to more specific siblings like ListDataServicePublishedApis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With siblings like GetDataServiceApi (singular retrieval), ListDataServicePublishedApis (published APIs only), and CreateDataServiceApi (creation), the description offers no comparison or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action ('get list') without disclosing behavioral traits like pagination behavior (implied by PageSize/PageNumber but not explained), rate limits, authentication needs, or what happens on empty results. For a list tool with zero annotation coverage, this is inadequate.
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, efficient sentence with no wasted words. However, it's under-specified rather than concise—it could benefit from additional context without becoming verbose, but as-is it's structurally sound.
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 no annotations, no output schema, and a list operation with filtering/pagination parameters, the description is incomplete. It doesn't explain return format, pagination behavior, error conditions, or how filters interact. For a tool with 5 parameters and no structured output documentation, this leaves 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%, so the schema fully documents all 5 parameters. The description adds no parameter information beyond what's in the schema, but since the schema is comprehensive, the baseline score of 3 is appropriate as the description doesn't need to compensate.
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 '获取数据开发函数列表' (Get data development function list) states the verb ('get') and resource ('function list'), but it's vague about scope and doesn't distinguish from sibling tools like GetFunction (which likely retrieves a single function). It doesn't specify whether this lists all functions or filtered subsets, leaving purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 GetFunction or other List* tools. The description doesn't mention prerequisites, context, or exclusions, 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.
Behavior2/5
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. The description only states it's a query operation, but doesn't mention whether it's read-only, paginated, requires authentication, has rate limits, or what the return format looks like. For a tool with 9 parameters and no output schema, 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, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately concise for a basic description, though it could be improved with more context. There's no structural issue with front-loading since it's just one sentence.
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 (9 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'data map entity lineage' means, how results are structured, or provide usage context compared to siblings. For a list/query tool with rich filtering options, more guidance on behavior and output is needed to be 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 all 9 parameters with their types and descriptions. The description adds no additional parameter information beyond what's in the schema, which is acceptable given the high coverage. The baseline score of 3 reflects adequate but not enhanced parameter documentation.
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 '查询数据地图实体血缘列表' (Query data map entity lineage list) states the verb ('query') and resource ('data map entity lineage list'), providing a basic purpose. However, it's vague about what 'data map entity lineage' entails and doesn't distinguish this tool from sibling tools like 'ListLineageRelationships' or 'GetLineageRelationship', which appear related but have different names and potentially different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With sibling tools like 'ListLineageRelationships' and 'GetLineageRelationship' available, there's no indication of differences in scope, filtering capabilities, or output format. This leaves the agent without context for selecting the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states it's a list operation, implying read-only behavior, but doesn't clarify output format (e.g., paginated list), error conditions, authentication needs, rate limits, or what 'network resources' entails. This leaves significant gaps for a tool with 4 parameters.
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, efficient sentence in Chinese that directly states the tool's purpose. It's front-loaded with no wasted words, though it could benefit from slightly more detail to improve clarity 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?
Given no annotations and no output schema, the description is insufficient for a tool with 4 parameters. It lacks details on behavioral traits (e.g., pagination behavior implied by PageSize/PageNumber), output format, and error handling. The agent must rely heavily on the input schema alone, leaving context 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 the input schema fully documents all parameters (ResourceGroupId, PageSize, PageNumber, SortBy). The description adds no additional parameter semantics beyond implying resource group filtering, which is already covered in 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取资源组网络资源列表' (Get resource group network resource list) clearly states the action (get/list) and target (network resources in a resource group), which is adequate. However, it doesn't differentiate this tool from other list tools like ListResources, ListNodes, or ListRoutes, leaving the scope vague regarding what 'network resources' specifically means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 prerequisites, exclusions, or compare it to sibling tools like GetNetwork (which might fetch a single network) or other list tools. The agent must infer usage solely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While '获取' (get) implies a read operation, the description doesn't specify whether this requires special permissions, what format the dependencies are returned in, whether results are paginated (though parameters suggest they are), or any rate limits. For a tool with 4 parameters and no annotations, this is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose. There's no wasted language or unnecessary elaboration. However, it could be slightly more specific about what type of dependencies are being retrieved to improve clarity without sacrificing 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 tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how dependencies are structured, or provide any context about the relationship between this tool and similar sibling tools. The description should do more to compensate for the lack of 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?
The schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
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 '获取数据开发节点的依赖节点' (Get data development node dependencies) clearly states the verb 'get' and resource 'dependencies', but it's somewhat vague about what exactly is being retrieved. It doesn't specify whether this returns upstream dependencies, downstream dependencies, or both, nor does it distinguish from sibling tools like ListUpstreamTasks or ListDownstreamTasks which might 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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like ListUpstreamTasks, ListDownstreamTasks, ListLineageRelationships, and GetLineageRelationship that might provide related dependency information, there's no indication of how this tool differs or when it should be preferred over those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'list' which implies a read-only operation, but doesn't disclose behavioral traits such as pagination handling (implied by PageSize/PageNumber but not explained), rate limits, authentication needs, or what happens if parameters are omitted. The description is minimal and lacks critical operational context.
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, efficient sentence in Chinese ('获取数据开发节点列表') that directly states the action. It's appropriately sized and front-loaded with no wasted words, though it could benefit from more detail given the tool's complexity.
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, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., what fields are included in the node list), pagination behavior, error conditions, or how filtering parameters interact. For a list tool with multiple optional filters, more context 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 description coverage is 100%, so the schema fully documents all 7 parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain parameter interactions or default behaviors). Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate or enhance understanding.
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 '获取数据开发节点列表' (Get data development node list) clearly states the verb ('get') and resource ('node list'), but it's vague about scope and doesn't differentiate from sibling tools like 'GetNode' (which retrieves a single node) or 'ListNodeDependencies' (which lists node dependencies). It provides basic purpose but lacks 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. The description doesn't mention prerequisites (e.g., needing a ProjectId), exclusions, or comparisons to similar tools like 'ListTasks' or 'ListWorkflowInstances'. Usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states 'query' (a read operation), but it doesn't mention pagination behavior (implied by PageNum and PageSize parameters), rate limits, authentication requirements, or what the return format looks like (e.g., list structure, error handling). For a tool with 13 parameters and no output schema, 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, efficient sentence ('查询权限申请单列表') that directly states the purpose without unnecessary words. It's appropriately sized for a list query tool, though it could be slightly more informative 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?
Given the complexity (13 parameters, no annotations, no output schema), the description is incomplete. It lacks information on behavioral traits (e.g., pagination, auth), usage context compared to siblings, and output format. For a tool with rich input schema but no structured output or annotations, the description should provide more guidance to be fully helpful to 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 85%, so the schema already documents most parameters well (e.g., QueryType, MaxComputeProjectName, EndTime). The description adds no additional parameter semantics beyond what's in the schema. However, since coverage is high (>80%), the baseline score is 3, as the schema does the heavy lifting, and the description doesn't need to compensate significantly.
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 '查询权限申请单列表' (Query permission application order list) clearly states the verb ('query') and resource ('permission application order list'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'GetPermissionApplyOrderDetail' (which retrieves details of a specific order) or 'ApprovePermissionApplyOrder' (which approves orders), leaving room for ambiguity about when to use this list tool versus 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?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't specify that this is for listing multiple orders with filtering, while 'GetPermissionApplyOrderDetail' is for retrieving a single order's details. Without such context, an agent might struggle to choose between this and other permission-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action ('获取发布流程列表') without mentioning permissions, pagination behavior, rate limits, or what data is returned. For a list tool with 5 parameters, this leaves critical operational details unspecified, though it implies a read-only 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, efficient phrase ('获取发布流程列表') that is front-loaded and wastes no words. However, it lacks structural elements like context or usage notes that could enhance clarity without sacrificing brevity.
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 no annotations and no output schema, the description is incomplete for a tool with 5 parameters. It doesn't explain the return format, error conditions, or behavioral traits like pagination. For a list operation in a complex system with many siblings, 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.
Parameters3/5
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 input schema (e.g., ProjectId, Status with enum values, PageSize). The description adds no additional parameter information beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
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 '获取发布流程列表' (Get pipeline run list) states the basic action and resource but lacks specificity. It doesn't distinguish this tool from similar list tools like ListWorkflowInstances or ListTaskInstances, nor does it clarify what 'pipeline runs' are beyond the name. The purpose is understandable but vague 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. With many sibling tools (e.g., ListWorkflowInstances, ListTaskInstances), the description doesn't explain the context for selecting this specific list tool, such as for deployment processes versus other workflow types. It offers no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states the action ('获取' - get) without mentioning any behavioral traits. It doesn't indicate if this is a read-only operation (likely, but not stated), whether it requires specific permissions, if results are paginated (implied by PageSize/PageNumber parameters but not described), rate limits, or what the output format looks like (no output schema). For a tool with 6 parameters and no annotations, 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, efficient sentence in Chinese ('获取工作空间角色详情列表') that directly states the tool's purpose. It's front-loaded with no unnecessary words. However, it could be slightly more specific (e.g., clarifying '详情' or adding context) without losing conciseness, but as-is, it's appropriately sized for its minimal 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?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral context (e.g., read-only nature, pagination behavior), usage guidelines relative to siblings, and details on output format. While the schema covers parameters well, the description doesn't add enough value to compensate for missing annotations and output schema, making it inadequate for an agent to fully understand the tool's behavior and 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?
The input schema has 100% description coverage, with each parameter clearly documented in Chinese (e.g., ProjectId as 'DataWorks工作空间的ID', Type with enum-like values 'UserCustom' and 'System'). The description adds no additional parameter semantics beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline score is 3 even with no param info in the description. The description doesn't compensate but doesn't need to, given the comprehensive schema.
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 '获取工作空间角色详情列表' (Get workspace role details list) states the basic purpose with a verb ('获取' - get) and resource ('工作空间角色详情列表' - workspace role details list). However, it's vague about what '详情' (details) specifically includes and doesn't differentiate from sibling tools like 'GetProjectRole' (singular) or 'ListProjectMembers' (members vs. roles). The description is functional but lacks specificity about the scope of returned 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. There are several sibling tools that might overlap (e.g., 'GetProjectRole' for a single role, 'ListProjectMembers' for members with roles, 'GrantMemberProjectRoles' for assignment), but the description doesn't mention any of these or clarify this tool's specific use case (e.g., listing all roles vs. filtered roles). Without such context, an 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It doesn't disclose behavioral traits like pagination behavior (implied by PageSize/PageNumber but not explained), rate limits, authentication needs, error conditions, or what 'list' means operationally. The description is minimal and lacks critical context for a tool with 5 parameters.
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?
Extremely concise single sentence with no waste. However, it's arguably too brief given the tool's complexity (5 parameters, no annotations, no output schema). The structure is front-loaded but lacks necessary elaboration.
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?
Incomplete for a 5-parameter tool with no annotations and no output schema. The description doesn't explain what the tool returns, how results are structured, pagination behavior, or error handling. Given the rich sibling toolset and lack of structured metadata, the description is 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 parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying resource listing. Baseline 3 is appropriate since the schema does the heavy lifting, though the description doesn't compensate with any parameter context.
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 '获取数据开发文件资源列表' (Get data development file resource list) states the verb ('获取' - get/list) and resource ('数据开发文件资源' - data development file resources), but is vague about scope and doesn't distinguish from sibling tools like ListResources (general) or ListFunctions, ListNodes, etc. It doesn't specify what 'file resources' means in this context versus 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 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 GetResource (singular) or other List* tools for different resource types. The description doesn't mention prerequisites, context, or exclusions. With many sibling List* tools, this omission is significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'get' implying a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, pagination behavior (implied by PageSize/PageNumber but not explained), or that it returns a list (not detailed). The description is minimal, missing key operational context for a tool with parameters.
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, efficient sentence in Chinese ('获取任务的操作日志列表'), which is appropriately concise and front-loaded. There's no wasted verbiage, though it could benefit from slight elaboration for clarity. It earns its place but leaves room for improvement in structure with additional context.
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 no annotations, no output schema, and 5 parameters, the description is incomplete. It doesn't explain the return format (list of logs), error conditions, or how parameters like Date and ProjectEnv affect results. For a list operation with filtering and pagination, more context is needed to guide effective use, making it inadequate 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 parameters are fully documented in the schema (e.g., '任务ID' for Id, '项目环境' for ProjectEnv). The description adds no additional meaning beyond the schema, not explaining parameter interactions or constraints like the 31-day limit for Date. Baseline is 3 as the schema does the heavy lifting, but no extra value is provided.
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 '获取任务的操作日志列表' translates to 'Get task operation logs list', which clearly states the verb ('get') and resource ('task operation logs'). However, it doesn't differentiate from sibling tools like 'ListTaskInstanceOperationLogs' or 'GetTaskInstanceLog', leaving ambiguity about scope (task vs. task instance). The purpose is understandable but lacks specificity compared to 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 'ListTaskInstanceOperationLogs' or 'GetTaskInstanceLog'. The description doesn't mention prerequisites, context (e.g., project environment), or exclusions. Usage is implied by the name alone, with no explicit instructions for selection among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action ('get list') without disclosing behavioral traits like pagination behavior (implied by PageSize/PageNumber but not explained), rate limits, authentication requirements, or what happens on empty results. For a list operation with 5 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('获取数据开发工作流列表') that is front-loaded and wastes no words. However, it could be more structured by explicitly mentioning key aspects like filtering or pagination to improve clarity 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?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return format, error conditions, or how to interpret results. For a list tool with filtering and pagination, more context is needed to guide effective use, especially without annotations or 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 schema already documents all 5 parameters thoroughly. The description adds no parameter-specific information beyond the schema, such as how filters interact or default behaviors. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取数据开发工作流列表' (Get data development workflow list) clearly states the verb ('get') and resource ('workflow list'), but it's vague about scope and doesn't distinguish from siblings like 'ListWorkflows' or 'ListWorkflowInstances'. It specifies 'data development' workflows, which provides some context, but lacks precision about what exactly is being listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'ListWorkflows', 'ListWorkflowInstances', and 'GetWorkflowDefinition', the description doesn't explain how this differs (e.g., listing definitions vs. instances, or filtered vs. comprehensive lists). The absence of usage context leaves the agent guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. '移动' (move) implies a mutation operation, but the description doesn't disclose behavioral traits like required permissions, whether the move is reversible, what happens to dependencies, rate limits, or error conditions. It's a bare statement of function without operational context.
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?
Extremely concise single phrase with zero waste. However, it's under-specified rather than efficiently complete—it could benefit from one more clarifying sentence 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error handling, or side effects. Given the complexity of moving nodes in a development environment, more context is needed about success criteria and 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 all three parameters (ProjectId, Id, Path) with descriptions. The tool description adds no additional meaning about parameters beyond what's in the schema, such as format examples for Id or Path constraints. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '移动数据开发节点路径' (Move data development node path) states the action (move) and resource (data development node path), but is vague about scope and doesn't distinguish from sibling tools like MoveFunction, MoveResource, or MoveWorkflowDefinition. It doesn't specify whether this moves nodes within a project or workspace, or what 'data development node' precisely means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 RenameNode or CreateNode. The description doesn't mention prerequisites (e.g., needing ProjectId or Id), exclusions, or typical scenarios for moving nodes versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'move' but doesn't disclose behavioral traits: whether this is a mutating operation, what permissions are required, if it's reversible, how it affects dependencies, or what happens on success/failure. For a tool that likely modifies workflow locations, this lack of transparency 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, efficient phrase that directly states the tool's purpose without unnecessary words. However, it could be more front-loaded with key operational details given the lack of annotations and output schema.
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 a move operation (likely mutating), no annotations, no output schema, and multiple sibling move tools, the description is insufficient. It doesn't explain what 'move' entails operationally, what the tool returns, or how it differs from other move operations. For a 3-parameter tool with no structured safety or output information, this is 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 all three parameters (ProjectId, Id, Path) documented in the schema. The description adds no additional parameter semantics beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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 '移动数据开发工作流路径' translates to 'Move data development workflow path', which clearly states the action (move) and target (workflow path). However, it doesn't specify what 'move' entails operationally (e.g., relocation within a hierarchy) or distinguish it from similar tools like MoveFunction, MoveNode, and MoveResource that appear to perform analogous operations on different 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 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 prerequisites (e.g., needing the workflow ID), context for moving workflows, or differences from other move operations (MoveFunction, MoveNode, MoveResource). Usage is implied only by 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. '启动' (start) implies a mutation operation that likely changes system state, but the description doesn't disclose what permissions are required, whether this is idempotent, what happens if the job is already running, or what the expected outcome is. The description is too minimal to provide meaningful behavioral context for a tool that presumably initiates data integration processes.
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 - a single Chinese phrase. While this is efficient, it may be too brief for a tool with complex parameters and behavioral implications. However, every word earns its place by directly stating the tool's action, so it scores well on conciseness despite potential under-specification.
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, the description is insufficiently complete. It doesn't explain what happens after starting the job, what success/failure looks like, or any side effects. The tool has complex nested parameters (including deprecated fields) and presumably significant system impact, but the description provides minimal context to help an agent understand the full implications of using 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 4 parameters thoroughly. The description adds no parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone, though the description doesn't add any value in this dimension.
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 '启动数据集成同步任务' (Start data integration synchronization task) states a clear verb ('启动' - start) and resource ('数据集成同步任务' - data integration synchronization task), but it's somewhat vague about what exactly is being started. It doesn't specify whether this starts a specific job instance or a job definition, nor does it distinguish from sibling tools like 'StartWorkflowInstances' or 'ExecPipelineRunStage' 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.
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. With many sibling tools like 'StartWorkflowInstances', 'ExecPipelineRunStage', and 'RerunTaskInstances' that might involve starting processes, there's no indication of what makes this tool unique or when it should be preferred. No prerequisites, 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.
Behavior2/5
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 'terminate', implying a destructive action, but does not disclose behavioral traits like whether termination is reversible, requires specific permissions, affects related resources, or has side effects. For a mutation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '终止工作流实例', which is concise and front-loaded with the core action. It wastes no words, but could be slightly more informative without losing efficiency. It earns its place by stating the purpose 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?
Given the tool is a mutation (termination) with no annotations and no output schema, the description is incomplete. It lacks details on behavior, outcomes, error handling, or how it interacts with sibling tools. For a destructive operation in a complex workflow system, more context is needed to ensure safe and 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 clear descriptions for 'Ids' (workflow instance ID list) and 'Comment' (remark information). The description adds no additional meaning beyond the schema, such as format details or usage examples. With high schema coverage, the baseline is 3, as the schema adequately documents parameters without extra value from the description.
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 '终止工作流实例' (terminate workflow instances) clearly states the action (terminate) and resource (workflow instances), which is specific. However, it does not differentiate from sibling tools like 'StopTaskInstances' or 'DeleteWorkflowInstances', leaving ambiguity about scope or distinctions. It avoids tautology but lacks sibling differentiation, making it vague in 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 such as 'StopTaskInstances', 'DeleteWorkflowInstances', or 'SuspendTaskInstances'. The description does not mention prerequisites, exclusions, or specific contexts for termination, offering only a basic action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'triggering' but doesn't disclose behavioral traits such as whether this is a read-only or destructive operation, permission requirements, rate limits, or what happens upon triggering (e.g., immediate execution vs. queued). This leaves significant gaps in understanding 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 phrase, '触发调度任务实例', which is concise and front-loaded. However, it's overly brief, bordering on under-specification, as it lacks necessary details for a tool with three parameters and no annotations, slightly reducing its effectiveness.
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 a triggering operation with three parameters, no annotations, and no output schema, the description is incomplete. It fails to explain what 'triggering' means in practice, the expected outcomes, or error conditions, leaving the agent with insufficient context for reliable 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%, so the schema already documents all three parameters (TaskId, TriggerTime, EnvType) with descriptions. The tool description adds no additional meaning beyond the schema, such as parameter interactions or usage examples, meeting the baseline for high schema coverage.
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 '触发调度任务实例' (Trigger scheduler task instance) states a clear verb+resource action, but it's vague about what 'triggering' entails (e.g., immediate execution, scheduling for future). It doesn't differentiate from siblings like 'StartWorkflowInstances' or 'ExecuteAdhocWorkflowInstance', leaving ambiguity about the specific 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?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'StartWorkflowInstances' and 'ExecuteAdhocWorkflowInstance' present, the description lacks context about prerequisites, appropriate scenarios, or exclusions, offering no help in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states this is an update operation but doesn't mention whether it requires specific permissions, what happens to existing alarm rules, whether changes are reversible, or any rate limits. The MCP Resource mention adds minimal context but doesn't address core behavioral traits needed 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences: one stating the purpose and another about the MCP Resource. While efficient, the second sentence about examples doesn't directly help the agent understand the tool's function and could be considered somewhat extraneous, preventing a perfect 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?
For an update tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a successful update, what errors might occur, or how to interpret results. The mention of an MCP Resource for examples doesn't compensate for these fundamental gaps in a mutation operation 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 already documents all 9 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting without compensating with extra insights.
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 '更新数据集成同步任务告警规则' (Update data integration sync task alarm rules), which provides a clear verb ('更新' - update) and resource ('告警规则' - alarm rules). However, it doesn't differentiate from sibling tools like 'UpdateAlertRule' or 'CreateDIAlarmRule', leaving ambiguity about when to use this specific tool versus 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 'CreateDIAlarmRule' or 'UpdateAlertRule'. The description only mentions the tool has an 'MCP Resource' with examples, but this doesn't help the agent understand the appropriate context for selecting this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While '更新' implies a mutation operation, the description doesn't specify whether this requires special permissions, what happens on success or failure, if it's idempotent, or any rate limits. For a mutation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('更新数据开发函数信息') that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, though it could benefit from slightly more detail to improve clarity 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?
Given the complexity of updating a function (a mutation operation), no annotations, no output schema, and 3 parameters, the description is incomplete. It lacks details on behavioral aspects like permissions, error handling, or what the update entails, and doesn't explain the return values or potential side effects. This makes it inadequate for safe and effective use by an AI 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 description coverage is 100%, meaning all parameters (ProjectId, Id, Spec) are documented in the schema with descriptions. The tool description adds no additional information about parameters beyond what the schema provides, such as explaining the relationship between ProjectId and Id or detailing the format of Spec. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to heavily.
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 '更新数据开发函数信息' clearly states the action ('更新' meaning 'update') and the resource ('数据开发函数信息' meaning 'data development function information'), which is a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'UpdateTask' or 'UpdateNode', which also perform updates on different resources, leaving the purpose somewhat vague in 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an existing function to update, or differentiate from similar tools like 'RenameFunction' or 'MoveFunction', which might handle specific aspects of function management. This lack of context makes it unclear 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.
Behavior2/5
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. While '更新' implies a mutation, it doesn't specify permissions required, whether changes are reversible, rate limits, or what happens on success/failure. For a mutation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('更新数据开发文件资源信息'), which is appropriately concise and front-loaded. It wastes no words, though it could benefit from more detail to improve clarity and completeness.
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 updating a resource with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, usage context, and expected outcomes, making it inadequate for an agent to fully understand the tool's operation and 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 description coverage is 100%, with all parameters documented in the input schema (e.g., ProjectId, Id, Spec, ResourceFile). The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新数据开发文件资源信息' clearly states the action ('更新' meaning 'update') and resource ('数据开发文件资源信息' meaning 'data development file resource information'), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'UpdateNode', 'UpdateFunction', or 'UpdateTask', which also update resources in the same domain, leaving ambiguity about what specifically distinguishes this 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing resource), exclusions, or compare to siblings like 'CreateResource' or 'DeleteResource'. This lack of context makes it hard for an agent to decide 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.
Behavior2/5
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 the tool updates metadata, implying a mutation operation, but fails to describe permissions required, whether changes are reversible, rate limits, or error handling. 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.
Conciseness4/5
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 function without unnecessary words. It's front-loaded with the core action, making it easy to parse, though it could benefit from slightly more detail given the lack of annotations.
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 updating metadata (a mutation operation), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error conditions, and what the update entails, making it inadequate for safe and effective tool invocation by an AI 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 detailed descriptions for both parameters (Id and Readme) in the input schema. The description adds no additional meaning beyond the schema, such as examples or context for the parameters. Baseline score 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('更新' meaning update) and target ('数据地图数据表的业务元数据' meaning data map table business metadata), which clarifies the tool's purpose. However, it's vague about what '业务元数据' specifically entails and doesn't differentiate from sibling tools like UpdateColumnBusinessMetadata or other metadata update tools, leaving 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 explicit guidance on when to use this tool versus alternatives is provided. The description implies it's for updating business metadata of tables, but it doesn't specify prerequisites, constraints, or compare it to similar tools like UpdateColumnBusinessMetadata or UpdateDataQualityRule, 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.
Behavior2/5
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. While '更新' implies a mutation, it doesn't specify permissions required, whether changes are reversible, error handling, or response format. For a mutation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('更新数据开发工作流信息') with no wasted words. It's front-loaded and appropriately sized for its purpose, though it could benefit from more detail given the lack of annotations.
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 a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error conditions, or return values, which are crucial for an agent to use this tool effectively in context with 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?
Schema description coverage is 100%, so the input schema already documents all three parameters (ProjectId, Id, Spec) with descriptions. The tool description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, resulting in a baseline score of 3.
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 '更新数据开发工作流信息' (Update data development workflow information) states the verb ('更新' - update) and resource ('数据开发工作流信息' - data development workflow information), which is clear. However, it doesn't differentiate from sibling tools like 'UpdateWorkflow' or 'RenameWorkflowDefinition', making it somewhat vague about the specific scope of this update operation compared to 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. It doesn't mention prerequisites (e.g., needing an existing workflow definition), exclusions, or comparisons with similar tools like 'UpdateWorkflow' or 'RenameWorkflowDefinition', leaving the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. '下线' implies a destructive/mutative action, but the description doesn't clarify if this is reversible, what permissions are needed, or what side effects occur. It lacks behavioral details like confirmation prompts or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single phrase. No wasted words, though this brevity contributes to underspecification in other dimensions. The structure is front-loaded with 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?
Incomplete for a destructive tool with no annotations and no output schema. The description doesn't explain what '下线' means operationally, what happens to the API, or what the tool returns. Given the complexity implied by three parameters and lack of structured safety hints, more context 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 description coverage is 100%, so the schema already documents all three parameters (ProjectId, ApiId, TenantId). The description adds no additional parameter context beyond what's in the schema, meeting the baseline for high coverage.
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 '下线数据服务API' (deactivate data service API) states a verb+resource action but is vague about what '下线' specifically entails (decommission, disable, or archive). It doesn't distinguish from sibling tools like DeleteDataServiceApi, which suggests a similar but different 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?
No guidance on when to use this tool versus alternatives like DeleteDataServiceApi or UpdateDataServiceApi. The description provides no context about prerequisites, consequences, or appropriate scenarios for invoking this operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'add' (implying a write/mutation), but doesn't disclose behavioral traits such as permissions required, whether the operation is idempotent, error handling, or what happens on success/failure. For a mutation 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.
Conciseness5/5
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.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks crucial context such as what happens after addition (e.g., success response, error cases), entity type limitations (implied by schema but not emphasized), and how it integrates with sibling tools. The schema covers parameters well, but behavioral and output aspects are 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 the schema already documents all three parameters (MetaCollectionId, Id, Remark) with basic descriptions. The description adds no additional meaning beyond what's in the schema, such as clarifying entity types or remark usage. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '向数据地图集合中添加实体对象' (Add entity objects to a data map collection) clearly states the action (add) and target (entity objects to collection), but it's somewhat vague about what constitutes an 'entity object' and doesn't differentiate from the sibling tool 'RemoveEntityFromMetaCollection' beyond the opposite action. It's functional but lacks specificity about entity types or collection 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. The description doesn't mention prerequisites (e.g., existing collection or entity), exclusions, or related tools like 'CreateMetaCollection' or 'ListEntitiesInMetaCollection'. Users must 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'create' which implies a write/mutation operation, but it doesn't disclose behavioral traits such as required permissions, whether the creation is idempotent, error handling, or what happens on success/failure. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('创建数据开发文件资源') with no wasted words. It is front-loaded and appropriately sized for the tool's purpose, earning full marks for 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?
Given this is a mutation tool (create operation) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects, error handling, and what the tool returns, which are critical for an AI agent to use it correctly in a data development 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 clear descriptions for ProjectId, Spec, and ResourceFile. The description adds no additional parameter semantics beyond what the schema provides, such as explaining relationships between parameters or usage examples. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建数据开发文件资源' (Create data development file resource) states the verb 'create' and the resource type 'data development file resource', which gives a basic purpose. However, it doesn't specify what this resource is used for or how it differs from other 'Create' tools in the sibling list (e.g., CreateDataSource, CreateFunction, CreateNode), making it vague about its specific 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?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions, and with many sibling tools like CreateDataSource or CreateFunction, it fails to differentiate usage scenarios, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('创建') without disclosing behavioral traits. It doesn't mention whether this is a mutating operation, what permissions are required, if it's idempotent, what happens on failure, or what the typical response looks like. For a creation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple creation tool and front-loads the essential 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 creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a successful creation returns, what error conditions might occur, or how this tool relates to other workflow management tools in the system. The 100% schema coverage helps with parameters, but overall context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 (ProjectId and Spec). The description adds no additional meaning about parameter usage, constraints, or relationships beyond what's in the schema. The baseline of 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建数据开发工作流' (Create data development workflow) states the verb and resource but is vague about what constitutes a 'data development workflow' in this context. It doesn't distinguish from siblings like CreateWorkflowInstances or CreateDIJob, leaving ambiguity about the specific type of workflow 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 like CreateWorkflowInstances or CreateDIJob. The description offers no context about prerequisites, dependencies, or appropriate scenarios for creating a workflow definition versus other workflow-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. '查询' (query) implies a read operation, but it doesn't disclose behavioral traits like whether it requires authentication, returns structured data, has rate limits, or what happens with invalid AlertId. The description lacks essential context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase with zero wasted words. It's front-loaded and efficiently communicates the core action, though this brevity contributes to gaps in other dimensions.
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 no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It doesn't explain what the tool returns (e.g., alert details, status, metadata), error conditions, or behavioral constraints, leaving significant gaps for a read operation in a complex system with many 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?
Schema description coverage is 100%, with AlertId documented as '报警ID，可调用[ListAlertMessages]获取' (Alert ID, can be obtained by calling ListAlertMessages). The description adds no additional parameter information beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
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 '查询报警信息' (Query alert information) states the general purpose but lacks specificity. It doesn't clarify what resource is being retrieved (e.g., details of a specific alert vs. general alert data) or how it differs from sibling tools like ListAlertMessages. The description is vague about scope and granularity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 input schema references ListAlertMessages as a source for AlertId values, but the description itself doesn't mention this prerequisite or differentiate usage from other alert-related tools like GetAlertRule or ListAlertMessages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While '获取' (get) implies a read operation, the description doesn't specify whether this requires authentication, returns structured data, handles errors, or has any side effects. For a tool with no annotation coverage, this leaves significant behavioral gaps that could affect agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 phrase in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information. There's no wasted verbiage or structural issues.
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 (a retrieval tool with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a single rule object, a list, or metadata), any prerequisites, or error conditions. For a tool in a system with many similar 'get' operations, more context is needed to distinguish it properly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 single parameter 'Id' documented as '自定义告警规则ID' (custom alert rule ID). The description doesn't add any parameter information beyond what's in the schema. Since the schema fully documents the parameter, the baseline score of 3 is appropriate—the description neither compensates for gaps nor adds extra value.
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 '获取自定义监控告警规则' (Get custom monitoring alert rules) clearly states the verb 'get' and resource 'custom monitoring alert rules', making the basic purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'ListAlertRules' or 'GetAlertMessage', leaving ambiguity about what specifically this tool retrieves versus 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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'ListAlertRules' (likely for listing multiple rules) and 'GetAlertMessage' (for alert messages), there's no indication whether this tool is for retrieving a single rule by ID, all rules, or something else. The lack of context makes it unclear when this specific tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a read-only operation ('get'), but doesn't specify permissions, rate limits, error handling, or what the return data includes (e.g., format, fields). For a tool with no annotation coverage, this leaves significant gaps in understanding its 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, efficient phrase ('获取数据地图数据库详情') with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
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 implied by the parameter format and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'data map database details' returns, how to interpret the ID format in practice, or any behavioral nuances, leaving the agent with insufficient context for effective 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 description adds no parameter information beyond what the input schema provides. With 100% schema description coverage for the single parameter 'Id', the schema already documents its format and requirements. The description doesn't compensate or add context, so it meets 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取数据地图数据库详情' (Get data map database details) states the verb ('get') and resource ('data map database details'), which provides a basic purpose. However, it's vague about what 'data map database details' specifically entails and doesn't differentiate from sibling tools like 'GetCatalog', 'GetTable', or 'ListDatabases', leaving ambiguity about scope and 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?
The description offers no guidance on when to use this tool versus alternatives. With many sibling tools like 'GetCatalog', 'GetTable', and 'ListDatabases', there's no indication of context, prerequisites, or exclusions, making it unclear how this tool fits into the broader workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a read operation ('获取' meaning get), but doesn't specify permissions, rate limits, error conditions, or output format. For a tool with no 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.
Conciseness5/5
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 any wasted words. It's appropriately sized and front-loaded, 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 complexity of data quality tasks and the lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned, potential side effects, or how it fits into broader workflows, leaving significant gaps for a tool that likely returns structured instance 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?
The input schema has 100% description coverage for its single parameter 'Id' (数据质量监控实例ID), so the schema fully documents the parameter. The description adds no additional semantic context beyond what's in the schema, resulting in a baseline score of 3 as the schema does the heavy lifting.
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 '获取数据质量校验任务实例详情' (Get data quality evaluation task instance details) clearly states the verb '获取' (get) and resource '数据质量校验任务实例详情' (data quality evaluation task instance details), providing a basic purpose. However, it doesn't distinguish this tool from similar siblings like 'GetDataQualityEvaluationTask' or 'GetTaskInstance', making it somewhat vague in comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With siblings like 'ListDataQualityEvaluationTaskInstances' (for listing) and 'GetDataQualityEvaluationTask' (for task-level details), there's no indication of context, prerequisites, or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states it queries details, with no information about permissions required, rate limits, error conditions, response format, or whether it's a read-only operation. For a tool with no annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 phrase ('查询质量规则详情') with zero wasted words. It's appropriately sized for a simple lookup tool and front-loads the core action. Every word earns its place by conveying the essential 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?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what 'details' include, how results are structured, or any behavioral aspects like error handling. For a tool that presumably returns structured data about quality rules, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter ('Id' with description '规则ID' - rule ID), so the schema fully documents the parameter. The description adds no additional parameter information beyond what's in the schema. Baseline score of 3 is appropriate when the schema does all the work.
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 '查询质量规则详情' (Query quality rule details) states a clear verb ('查询' - query) and resource ('质量规则详情' - quality rule details), but it's vague about what 'details' includes and doesn't distinguish from sibling tools like 'ListDataQualityRules' or 'GetDataQualityRuleTemplate'. It provides basic purpose but lacks specificity about scope or content of the returned details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 prerequisites, when this tool is appropriate, or contrast it with sibling tools like 'ListDataQualityRules' (for listing multiple rules) or 'GetDataQualityRuleTemplate' (for templates). The agent must 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it 'gets' partition details, implying a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, response format, or whether it returns a single partition or multiple. For a tool with no annotation coverage, 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.
Conciseness5/5
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 with zero wasted words. It's appropriately sized 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'partition details' include, the return format, or any behavioral context. For a tool that likely returns structured data about partitions, this leaves significant gaps for an AI agent to understand how to use it 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?
Schema description coverage is 100%, with both parameters (TableId and Name) well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, such as format examples or constraints. With 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取数据地图数据表的分区详情' (Get partition details of a data map data table) states the verb ('获取' - get) and resource ('分区详情' - partition details), but is vague about scope and doesn't distinguish from sibling tools like 'ListPartitions'. It specifies '数据地图数据表' (data map data table) which provides some context, but lacks precision about what exactly 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 like 'ListPartitions' or 'GetTable'. The description doesn't mention prerequisites, exclusions, or comparative use cases. It simply states what the tool does without contextual framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read operation ('获取' - get), but doesn't disclose behavioral traits like whether it requires specific permissions, what happens if the ID is invalid, if it returns structured data, or any rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient phrase ('获取工作空间详情') that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loaded with the core action, making it easy to parse quickly.
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 no annotations and no output schema, the description is incomplete for a tool that likely returns structured project details. It doesn't hint at what '详情' (details) includes—such as metadata, configuration, or status—leaving the agent uncertain about the return value. For a retrieval tool with rich sibling context, more completeness 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?
The input schema has 100% description coverage, with one parameter 'Id' clearly described as 'DataWorks工作空间的ID' (DataWorks workspace ID). The description doesn't add any parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 '获取工作空间详情' (Get workspace details) states a clear verb ('获取' - get) and resource ('工作空间详情' - workspace details), providing basic purpose. However, it doesn't differentiate from sibling tools like 'GetProjectMember' or 'GetProjectRole', which also retrieve project-related information, making it somewhat vague about what specific 'workspace details' are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With many sibling tools like 'ListProjects' (which might list multiple projects) and other 'Get*' tools for specific project components, there's no indication of when this tool is appropriate, such as for retrieving high-level project metadata versus detailed member or role information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 it's a query (read-only), implying no destructive actions, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or response format. For a tool with no annotations, this leaves significant gaps in understanding its 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, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what '详情' (details) includes in the response, such as member roles or permissions, nor does it cover error handling or dependencies. For a tool that retrieves specific member data, more context is needed to use it 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?
Schema description coverage is 100%, with clear descriptions for both parameters (ProjectId and UserId). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询工作空间成员详情' (Query workspace member details) states the verb (query) and resource (workspace member details), which is clear. However, it doesn't distinguish this tool from its sibling 'ListProjectMembers', which likely lists multiple members rather than getting details of a specific one. The purpose is understandable but 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 doesn't mention prerequisites, such as needing a specific project or user ID, or contrast it with 'ListProjectMembers' for bulk queries. Without usage context, the agent must infer from parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation ('get'), but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what happens if the resource doesn't exist. For a tool with no 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.
Conciseness5/5
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.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'details' include in the return value, potential side effects, or error handling. For a tool in a complex data development environment with many siblings, 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.
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 (Id and ProjectId) clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides, such as format examples or interdependencies. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取数据开发文件资源详情' (Get data development file resource details) clearly states the action (get) and resource (file resource details), but it's somewhat vague about what 'details' entail and doesn't distinguish from sibling tools like GetResourceGroup or GetTask, which also retrieve details of different resources. It avoids tautology but lacks 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. With many sibling 'Get' tools (e.g., GetResourceGroup, GetTask, GetProject), the description doesn't indicate this is specifically for file resources in data development contexts, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves details (implying a read operation) but doesn't disclose behavioral traits such as authentication requirements, rate limits, error conditions, or what the output includes (since there's no output schema). This is a significant gap for a tool with no 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, efficient phrase in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with no wasted sentences.
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 a data retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'details' are returned, potential side effects, or usage context, leaving gaps that could hinder an AI agent's ability to use the tool 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 schema description coverage is 100%, with detailed descriptions for both parameters (Id and IncludeBusinessMetadata). The description adds no additional parameter semantics beyond what the schema provides, so it meets 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取数据地图数据表详情' (Get data map data table details) states the tool's purpose as retrieving table details, which is clear but generic. It doesn't distinguish this from similar 'Get' tools like GetColumn, GetDatabase, or GetSchema in the sibling list, nor does it specify what 'details' include beyond what the parameters imply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 many sibling tools like GetColumn, GetDatabase, and ListTables, the description lacks any indication of context, prerequisites, or comparisons, leaving the agent to infer usage based on 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.
Behavior2/5
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 this is a 'get' operation, implying it's read-only, but doesn't confirm this or describe other traits like authentication requirements, rate limits, error conditions, or what 'details' include (e.g., status, timestamps). For a tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('获取' meaning 'get') and resource ('任务实例的详情' meaning 'task instance details'), making it immediately understandable. Every word contributes directly 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?
Given the complexity (a read operation with 1 parameter) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' are returned (e.g., JSON structure, fields like status or execution time), which is critical since there's no output schema. For a tool that retrieves specific instance data, more context on the return value is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 1 parameter with 100% description coverage ('任务实例的唯一标识符' meaning 'unique identifier of the task instance'). The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 '获取任务实例的详情' translates to 'Get details of a task instance', which clearly states the verb ('get') and resource ('task instance details'). However, it doesn't distinguish this tool from sibling tools like 'GetTask' or 'GetTaskInstanceLog', which also retrieve task-related information. The purpose is clear but 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 doesn't mention prerequisites (e.g., needing a task instance ID), exclusions, or comparisons to similar tools like 'GetTask' (for task definitions) or 'GetTaskInstanceLog' (for logs). Without any usage context, the agent must 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.
Behavior2/5
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. '获取' (get) implies a read operation, but the description doesn't specify whether this requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this is a significant gap in 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, efficient phrase ('获取事件的详情') with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose immediately.
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 simplicity (1 parameter, no output schema) and lack of annotations, the description is incomplete. It doesn't explain what 'event' refers to in this context (e.g., data events, workflow events), what details are returned, or any behavioral traits. For a tool named 'GetTopic' among many similar 'Get' siblings, more context is needed to guide proper 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% description coverage (TopicId is documented as '事件的ID' - event ID), so the schema already provides parameter meaning. The description doesn't add any additional semantic context beyond what's in the schema, such as format examples or constraints. With 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取事件的详情' (Get event details) states a clear verb ('获取' - get) and resource ('事件的详情' - event details), providing a basic purpose. However, it doesn't distinguish this tool from other 'Get' siblings like GetAlertRule, GetCatalog, GetColumn, etc., which also retrieve details of different resources. The purpose is clear but 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 doesn't mention prerequisites (e.g., needing a TopicId), exclusions, or context for selecting this over other 'Get' tools. Without any usage context, the agent must infer based on 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.
Behavior2/5
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 the tool retrieves a list, implying a read-only operation, but doesn't specify whether it's safe, what permissions are needed, if there are rate limits, or what the output format looks like (e.g., pagination, error handling). 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.
Conciseness5/5
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 key 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a retrieval tool with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what '基线实例' (baseline instances) are, how they relate to events, what the return data includes, or any behavioral aspects like safety or performance. This leaves the agent with insufficient context for effective 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 has 100% description coverage, with the TopicId parameter documented as '事件的ID' (event ID). The description doesn't add any extra meaning beyond this, such as explaining what constitutes a valid TopicId or how it relates to '基线实例' (baseline instances). With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 '获取事件影响的基线实例列表' (Get a list of baseline instances affected by an event) specifies a verb ('获取' - get) and resource ('基线实例列表' - baseline instance list) with some context about events. However, it's somewhat vague about what '基线实例' (baseline instances) refers to in this domain, and it doesn't clearly distinguish this tool from sibling tools like GetTopic, GetTaskInstance, or ListTopics, which might retrieve 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. It doesn't mention prerequisites (e.g., needing a TopicId), exclusions, or compare it to similar tools in the sibling list (e.g., GetTopic for topic details or ListTopics for listing topics). 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it retrieves details, but doesn't disclose behavioral traits like whether it's a read-only operation (implied but not explicit), error conditions (e.g., invalid ID), response format, or any rate limits. For a tool with no annotation coverage, 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.
Conciseness5/5
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 with zero wasted words. It's appropriately sized 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a single parameter, the description is incomplete. It doesn't explain what 'details' include, potential errors, or the return structure. For a retrieval tool, this leaves significant gaps in understanding its behavior and 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 input schema has 100% description coverage for its single parameter ('Id'), so the schema already documents it well. The description adds no additional parameter semantics beyond implying an ID is needed. With high schema coverage, the baseline is 3 even without param info in the description.
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 '获取工作流实例的详情' (Get workflow instance details) states a clear verb ('获取' - get) and resource ('工作流实例' - workflow instance), but it's vague about what '详情' (details) includes. It doesn't distinguish this tool from siblings like 'GetWorkflowDefinition' or 'ListWorkflowInstances' beyond the specific 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?
No guidance is provided on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an instance ID), comparison to 'ListWorkflowInstances' for listing multiple instances, or when this retrieval is appropriate. The description only states what it does, not 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.
Behavior2/5
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 '导入' (import) which implies a write/mutation operation, but doesn't disclose behavioral traits like whether it overwrites existing workflows, requires specific permissions, returns an identifier, or has side effects. The description is minimal and lacks operational 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, efficient phrase ('导入数据开发工作流') with zero wasted words. It's appropriately sized and front-loaded, though its brevity contributes to gaps in other dimensions.
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 importing a workflow (a mutation operation with no annotations and no output schema), the description is inadequate. It doesn't explain what 'Spec' contains, how the import works, what happens on success/failure, or what the tool returns. For a tool with 2 parameters and significant implied behavior, more context 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 description coverage is 100%, with both parameters documented in the schema: 'ProjectId' (DataWorks workspace ID) and 'Spec' (FlowSpec information describing the workflow). The description adds no additional parameter semantics beyond what's already in 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '导入数据开发工作流' (Import data development workflow) states a clear verb ('导入' - import) and resource ('数据开发工作流' - data development workflow), but it's somewhat vague about what exactly is being imported. It distinguishes from obvious siblings like 'CreateWorkflowDefinition' (which likely creates new workflows) by focusing on import, but doesn't specify the source format or mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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's no mention of prerequisites (e.g., needing an existing workflow definition file), when not to use it, or how it differs from similar tools like 'CreateWorkflowDefinition' or 'UpdateWorkflowDefinition' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('get list') without mentioning pagination behavior (implied by PageNumber/PageSize parameters but not described), rate limits, authentication needs, or what constitutes a 'custom rule'. For a list operation with 7 parameters, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 directly states the tool's purpose without any fluff. It is appropriately sized and front-loaded, making it easy to parse quickly. Every word earns its place by conveying 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 complexity (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return format, pagination behavior, or how parameters interact (e.g., filtering by Types vs. Owner). For a list tool with multiple filtering options and no structured output, 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.
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 (e.g., PageNumber for pagination, Types for alert types). The description adds no additional parameter semantics beyond what the schema provides. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 '获取自定义规则列表' (Get custom rule list) clearly states the verb ('get') and resource ('custom rule list'), providing a basic purpose. However, it doesn't distinguish this tool from other list tools on the server (like ListDataQualityRules, ListDIAlarmRules, etc.), leaving ambiguity about what specifically makes 'alert rules' different. The purpose is understandable but 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. With many sibling list tools available (e.g., ListAlertMessages, ListDataQualityRules), there's no indication of context, prerequisites, or exclusions. The agent must infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but only states the action without detailing traits. It doesn't mention whether this is a read-only operation, if it requires authentication, potential rate limits, pagination behavior (implied by parameters but not described), or error conditions, making it insufficient for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 in Chinese that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick 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?
Given the complexity (6 parameters, 1 required) and lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects, usage context, or return values, leaving significant gaps for an agent to understand how to invoke the tool correctly and interpret results, especially for a list operation with filtering 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 description coverage is 100%, so all parameters are documented in the input schema. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or providing examples. This meets the baseline score of 3, as the schema adequately covers parameter details without extra value from the description.
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 '查询质量规则模版列表' (Query quality rule template list) clearly states the action (query/list) and resource (quality rule templates), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'GetDataQualityRuleTemplate' (singular) or 'ListDataQualityRules' (actual rules vs templates), leaving room for 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. The description lacks context such as prerequisites (e.g., needing a project ID), comparisons to similar tools (e.g., 'GetDataQualityRuleTemplate' for a single template), or typical use cases, leaving the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 this is a read operation ('获取'), implying it's non-destructive, but doesn't mention authentication needs, rate limits, pagination behavior (though parameters suggest it), or what the return format looks like. For a list tool with 7 parameters and no annotations, this leaves significant gaps in understanding 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.
Conciseness5/5
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 any fluff. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, and there's no wasted verbiage.
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 (7 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain the return format (e.g., structure of the list, error handling), pagination behavior implied by parameters, or how filtering interacts. For a list tool with multiple filters and pagination, more context is needed to use it effectively, especially without annotations or 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% description coverage, with all 7 parameters well-documented in Chinese. The description adds no additional parameter information beyond what the schema provides (e.g., it doesn't explain how filtering with 'CreatorId' or keywords works in practice). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 '获取数据服务API的发布态信息列表' clearly states the action ('获取' - get/fetch) and resource ('数据服务API的发布态信息列表' - list of published data service APIs), which is specific. However, it doesn't distinguish this tool from sibling tools like 'ListDataServiceApis' (which likely lists unpublished APIs) or 'GetDataServicePublishedApi' (which likely gets a single published API), leaving the differentiation unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 sibling tools like 'ListDataServiceApis' or 'GetDataServicePublishedApi', nor does it specify prerequisites such as required authentication or project context. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool does ('view metrics') without mentioning any behavioral traits like whether this is a read-only operation, what permissions might be required, whether results are paginated, or what format the output takes. For a tool with 4 parameters and no annotations, this is insufficient 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 extremely concise - a single Chinese phrase that directly states the tool's purpose. There's zero wasted language, and it's front-loaded with the essential information. This is appropriately sized for what it communicates.
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 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what metrics are available, what format the output takes, whether time ranges are required, or how to interpret results. For a metrics querying tool in a complex data integration context, this leaves too many unanswered questions for effective agent 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?
With 100% schema description coverage, the input schema already documents all 4 parameters (StartTime, EndTime, MetricName, DIJobId) with basic descriptions. The tool description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 but doesn't provide extra value like explaining metric name formats or time range requirements.
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 '查看数据集成同步任务运行指标' (View data integration synchronization task running metrics) states a clear verb ('view') and resource ('metrics'), but is somewhat vague about scope and doesn't differentiate from siblings like ListDIJobEvents or ListDIJobRunDetails. It doesn't specify whether this lists metrics for all jobs or a specific one, or what types of metrics are available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With many sibling tools like ListDIJobEvents, ListDIJobRunDetails, and GetDIJobLog that might provide related information, there's no indication of when this specific metrics-listing tool is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it's a query/list operation, but doesn't disclose behavioral traits like whether it's read-only, pagination behavior (implied by parameters but not described), rate limits, authentication needs, or what happens on errors. For a tool with 8 parameters and no annotations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 (8 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain return values, error conditions, or usage context. The agent lacks sufficient information to understand the full scope and behavior of 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%, so the schema fully documents all 8 parameters. The description adds no additional meaning about parameters beyond the schema. According to rules, baseline is 3 when schema coverage is high (>80%), even with no param info in description.
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 '查询数据地图集合中的实体列表' clearly states the action (query/list) and target (entities in a data map collection), but it's vague about what 'entities' specifically are and doesn't distinguish this tool from other list tools like ListMetaCollections or ListEntities (if present). It provides a basic purpose but lacks 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. The description doesn't mention prerequisites, context, or exclusions. With many sibling tools available, the agent receives no help in selecting this specific list operation over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. The description only states it's a query operation, implying read-only and non-destructive behavior, but it doesn't specify details like pagination handling (implied by parameters but not described), rate limits, authentication needs, or what the return format looks like. For a list tool with 10 parameters, this is insufficient 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, efficient sentence in Chinese ('查询数据地图集合列表'), which is appropriately concise and front-loaded. There's no wasted verbiage, making it easy to parse quickly.
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 (10 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, error handling, or how the filtering parameters interact. For a list tool with rich filtering options, more context is needed to guide effective use, especially without annotations or 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% description coverage, with each parameter well-documented in the schema itself (e.g., Type with enum values, ParentId, Order, etc.). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
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 '查询数据地图集合列表' (Query data map collection list) states the verb 'query' and resource 'data map collection list', providing a basic purpose. However, it's vague about what 'data map collection' means and doesn't distinguish this tool from other list tools like ListEntitiesInMetaCollection or ListMetaCollection (if it existed as a sibling), which might have similar functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With many sibling tools (e.g., ListEntitiesInMetaCollection, ListMetaCollection if present), there's no indication of context, prerequisites, or exclusions. It lacks any mention of when this tool is appropriate or what scenarios it's designed for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the query action without disclosing behavioral traits like pagination behavior (implied by PageSize/PageNumber but not explained), rate limits, authentication requirements, error conditions, or response format. For a list operation with 5 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. It's front-loaded and appropriately sized for a simple description, though this conciseness comes at the cost of completeness.
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 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the tool's behavior, output format, error handling, or how it differs from sibling tools. For a list operation with filtering and pagination parameters, more context 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 description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning about parameters beyond what the schema provides (e.g., no explanation of how filtering with RoleCodes/UserIds works together). 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询工作空间成员列表' (Query workspace member list) states the basic action (query/list) and resource (workspace members), but it's vague about scope and lacks sibling differentiation. It doesn't specify whether this lists all members or filtered subsets, nor how it differs from GetProjectMember (which appears to fetch a single member).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 GetProjectMember or CreateProjectMember. The description provides no context about prerequisites, typical use cases, or exclusions. Users 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While '获取' implies a read-only operation, the description doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the logs come in. For a list operation with no annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 directly states the tool's purpose without unnecessary words. It's appropriately front-loaded with the core functionality and contains zero redundant information. Every word earns its place in this minimal but complete statement of what the tool does.
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 list operation with 4 parameters and no output schema, the description is insufficiently complete. It doesn't explain what the output looks like (log format, structure), whether results are paginated (implied by parameters but not stated), or how this differs from similar logging tools. With no annotations and no output schema, the description should provide more behavioral context to be truly helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 all 4 parameters (Id, PageSize, PageNumber, Date). The description adds no additional parameter context beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify edge cases. With complete 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.
Purpose3/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 (任务实例的操作日志列表/task instance operation logs list), making the purpose understandable. However, it doesn't distinguish this tool from similar sibling tools like 'ListTaskOperationLogs' or 'GetTaskInstanceLog', leaving ambiguity about when to use this specific tool versus 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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'ListTaskOperationLogs' and 'GetTaskInstanceLog' available, there's no indication of how this tool differs in scope, granularity, or use case. The description offers no context about prerequisites, limitations, or typical scenarios for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states the action ('获取任务实例列表') without any details on permissions required, rate limits, pagination behavior (implied by PageSize and PageNumber parameters but not described), or what the return format looks like. This is inadequate for a tool with 19 parameters and 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 extremely concise with a single phrase ('获取任务实例列表'), which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration, making it highly structured for its brevity.
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 (19 parameters, no annotations, no output schema), the description is insufficient. It does not address behavioral aspects like pagination, filtering logic, or return values, which are critical for an agent to use the tool effectively. The high parameter count and lack of output information make this description incomplete for practical 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 description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters (e.g., how TaskId and TaskIds interact) or providing examples. With high schema coverage, the baseline score is 3, as the description does not compensate but also does not detract.
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 '获取任务实例列表' (Get task instance list) clearly states the verb ('获取' - get) and resource ('任务实例列表' - task instance list), which establishes the basic purpose. However, it lacks specificity about what distinguishes this tool from other list tools like ListTasks or ListWorkflowInstances, making it somewhat vague in comparison to 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 description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, such as how it differs from ListTasks (which might list task definitions) or ListWorkflowInstances (which might list workflow instances). This leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states what the tool does ('get list'), without mentioning whether this is a read-only operation, if it requires specific permissions, what the return format looks like, or any pagination behavior (despite parameters for PageSize and PageNumber). For a listing tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 in Chinese ('获取上游任务实例列表') that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a listing tool with pagination parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'upstream' means in this context, what data is returned, or how pagination works. The agent would struggle to use this tool effectively without additional context or trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 (Id, PageSize, PageNumber are all documented in Chinese), so the schema already provides parameter semantics. The description adds no additional meaning beyond what's in the schema—it doesn't explain how 'Id' relates to upstream instances, default behaviors, or parameter interactions. With 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取上游任务实例列表' (Get upstream task instances list) clearly states the verb ('获取' - get) and resource ('上游任务实例列表' - upstream task instances list), providing a basic purpose. However, it doesn't distinguish this tool from similar sibling tools like 'ListDownstreamTaskInstances' or 'ListTaskInstances', leaving ambiguity about what specifically makes 'upstream' instances different.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 are multiple related listing tools (e.g., ListDownstreamTaskInstances, ListTaskInstances, ListTasks), but the description doesn't explain when 'upstream' instances are needed, what prerequisites exist, or any exclusions. This leaves the agent to guess based on 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a destructive mutation ('remove'), but doesn't disclose critical behavioral traits: whether this operation is reversible, what permissions are required, if it affects task execution, or what happens if dependencies are invalid. For a mutation tool with zero annotation coverage, this is a significant gap in safety and operational 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, efficient phrase ('移除任务实例的依赖关系') that directly states the tool's action without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
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 (a destructive mutation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the impact of removal, error conditions, or return values, leaving gaps that could lead to incorrect usage. For a tool that modifies dependencies, more context is needed to ensure safe 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 clear parameter descriptions in Chinese ('任务实例ID', '上游任务实例ID列表', '备注信息'). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but no extra value is added.
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 '移除任务实例的依赖关系' (Remove task instance dependencies) clearly states the action (remove) and target (task instance dependencies), providing a basic understanding of purpose. However, it doesn't differentiate from sibling tools like 'DeleteTask' or 'DeleteTaskInstance' that might also affect tasks, nor does it specify what type of dependencies are being removed (e.g., upstream/downstream, execution dependencies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 prerequisites (e.g., whether the task instance must be in a specific state), exclusions, or related tools like 'ListUpstreamTaskInstances' or 'ListDownstreamTaskInstances' that might help identify dependencies before removal. Without this, an agent might misuse it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action ('启动' meaning start) but doesn't explain what starting entails—whether it's a mutation, requires permissions, has side effects, or what happens if instances are already running. This leaves significant gaps for a tool that likely modifies 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, efficient phrase ('启动工作流实例') that is front-loaded and wastes no words. It's appropriately sized for conveying the core action without unnecessary elaboration.
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 a likely state-modifying tool with no annotations and no output schema, the description is inadequate. It doesn't cover behavioral aspects like effects, permissions, or response format, leaving the agent with insufficient information to use the tool safely and 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?
Schema description coverage is 100%, so the schema already documents both parameters ('Ids' as workflow instance ID list and 'Comment' as remark information). The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.
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 '启动工作流实例' (Start workflow instances) clearly states the verb and resource, but it's somewhat vague about scope and doesn't differentiate from sibling tools like 'CreateWorkflowInstances' or 'ExecuteAdhocWorkflowInstance'. It specifies the action but lacks detail about what 'starting' entails versus creating or executing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'CreateWorkflowInstances' or 'ExecuteAdhocWorkflowInstance'. The description doesn't mention prerequisites, context, or exclusions, 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.
Behavior2/5
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 displays converted timestamps but doesn't specify whether this is a read-only operation, what happens with invalid timestamps, if there are rate limits, or what the output format looks like. For a tool with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two sentences, but could be more front-loaded. The second sentence essentially restates the purpose with slightly different wording. While not wasteful, it doesn't maximize information density or provide a clear hierarchy of 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 data transformation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens with invalid inputs, what timezone is used, whether the operation is idempotent, or what the return structure looks like. Given the complexity of timestamp conversion and lack of structured metadata, more context 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?
The schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain timestamp format expectations, default behaviors, or provide examples of valid formats. 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.
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: converting timestamps to dates/times. It specifies both the action ('转成' meaning convert) and the resource ('时间戳' meaning timestamps). However, it doesn't differentiate from its sibling tool 'ToTimestamps' which appears to do the inverse operation, preventing 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool. It mentions '返回内容如果有时间戳' (if the returned content has timestamps), which gives a basic context, but doesn't explicitly contrast with alternatives like 'ToTimestamps' or explain when one would choose conversion over other timestamp handling methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description implies a read operation ('查询' - query), but it doesn't specify whether this requires permissions, what the return format looks like (e.g., JSON structure), or any rate limits. For a tool with no annotation coverage, this leaves significant behavioral gaps, though it correctly indicates a query rather than a mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 phrase ('查询数据质量监控详情') 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 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?
Given the tool's low complexity (1 parameter, no nested objects, no output schema), the description is minimally adequate. It clarifies the tool queries details rather than lists or creates, but lacks output information and behavioral context. With no annotations and no output schema, the description should ideally provide more guidance on return values or usage, but it meets a basic threshold 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 input schema has 1 parameter ('Id') with 100% description coverage ('数据质量监控ID' - data quality monitoring ID). The description adds no additional parameter semantics beyond what the schema provides. With high schema coverage, the baseline is 3, as the schema adequately documents the parameter without needing extra details from the description.
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 '查询数据质量监控详情' (Query data quality monitoring details) states a clear verb ('查询' - query) and resource ('数据质量监控详情' - data quality monitoring details), providing a basic purpose. However, it doesn't distinguish this tool from sibling tools like 'GetDataQualityEvaluationTaskInstance' or 'ListDataQualityEvaluationTasks', which appear to handle similar data quality monitoring entities. The purpose is clear but 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. With sibling tools like 'GetDataQualityEvaluationTaskInstance' (likely for instances) and 'ListDataQualityEvaluationTasks' (likely for listing multiple), there's no indication of context, prerequisites, or exclusions. The agent must 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'view' implies a read-only operation, it doesn't disclose important behavioral aspects like authentication requirements, rate limits, error conditions, or what happens when WithDetails is false versus true. For a tool with 4 parameters and no annotation coverage, this is a significant gap in 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, efficient Chinese phrase that directly states the tool's purpose. There's zero wasted language or unnecessary elaboration. It's appropriately sized and front-loaded with the essential 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 4 parameters with 100% schema coverage but no annotations and no output schema, the description provides the basic purpose but lacks important context. For a read operation that likely returns structured configuration data, the description doesn't hint at the return format or what 'configuration details' actually include beyond what's implied by the WithDetails parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 '查看数据集成同步任务配置详情' translates to 'View data integration synchronization task configuration details', which clearly states the verb ('view') and resource ('data integration synchronization task configuration details'). However, it doesn't distinguish this tool from potential siblings like GetDIJobLog or GetDIJobMetrics, which also retrieve DI job information but focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With sibling tools like GetDIJobLog (for logs), GetDIJobMetrics (for metrics), and ListDIJobs (for listing), there's no indication of when this specific configuration-detail tool is appropriate versus those other DI job-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a read operation ('获取' - get), implying it's likely safe and non-destructive, but doesn't disclose any behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the ID doesn't exist. For a tool with zero annotation coverage, 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.
Conciseness5/5
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 any fluff. It's appropriately sized for a simple lookup tool and front-loaded with the essential 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's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks context about the network resource type, return format, or error handling. Without annotations or output schema, more detail would be helpful for the agent to use 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 description coverage is 100%, with the parameter 'Id' documented as '网络资源ID' (network resource ID). The description adds no additional meaning beyond this, as it doesn't explain what format the ID should be in, where to find it, or provide examples. With 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取某个网络资源详细信息' (Get detailed information of a network resource) states a clear verb ('获取' - get) and resource ('网络资源' - network resource), but it's vague about what constitutes 'detailed information' and doesn't distinguish this tool from other Get* tools in the sibling list (like GetResource, GetNode, GetRoute). It's better than a tautology but lacks 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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., GetResource, GetNode, ListNetworks), there's no indication of what makes this tool unique or when it should be preferred. 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.
Behavior2/5
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. While '查询' implies a read-only operation, it doesn't specify whether this requires specific permissions, what format the details are returned in, whether there are rate limits, or if it returns sensitive information. For a tool that retrieves permission application details (potentially sensitive), this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 Chinese sentence that directly states the tool's purpose without any wasted words. It's appropriately sized for a simple lookup tool and front-loads the essential 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 single-parameter lookup tool with 100% schema coverage but no annotations and no output schema, the description is minimally adequate. It states what the tool does but lacks important context about behavioral characteristics, return format, and differentiation from sibling tools. The simplicity of the tool (one required parameter) keeps this from being a lower 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 description coverage is 100% with the single parameter 'FlowId' clearly documented as '权限申请单ID' (permission application order ID). The description doesn't add any additional parameter semantics beyond what the schema provides, but with complete 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询权限申请单的详细信息' clearly states the action (查询 - query) and resource (权限申请单的详细信息 - permission application order details), which is better than a tautology. However, it doesn't differentiate from sibling tools like 'ListPermissionApplyOrders' or 'ApprovePermissionApplyOrder' - it's a specific detail retrieval tool but this distinction isn't explicitly made 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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (like needing a specific FlowId), when this is appropriate versus listing orders, or what context requires detailed information versus summary information from other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states that this updates alert rules without mentioning whether this is a destructive operation, what permissions are required, how errors are handled, or what happens to existing configurations. For a mutation tool with complex 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is appropriately concise, but the second sentence about 'MCP Resource' adds technical clutter without enhancing understanding for tool selection. While brief, the structure could be improved by front-loading more actionable information rather than implementation 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?
For a complex mutation tool with 6 parameters, nested objects, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'updating' entails (partial vs. full updates), success/failure conditions, or relationship to other alert management tools, leaving significant gaps in understanding the tool's behavior 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?
The schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond the schema, which meets the baseline expectation when schema coverage is complete but doesn't provide 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 verb ('更新' meaning 'update') and resource ('自定义监控告警规则' meaning 'custom monitoring alert rule'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'CreateAlertRule' or other alert-related tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'CreateAlertRule' or 'DeleteAlertRule'. The mention of 'MCP Resource' is a technical implementation note rather than usage guidance, leaving the agent with no context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. '终止' (terminate/abolish) implies a destructive mutation, but the description doesn't specify whether this is reversible, what permissions are required, what happens to dependent resources, or what the response looks like. For a destructive operation with zero annotation coverage, this is a significant gap in 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 Chinese phrase ('终止发布流程') that directly conveys the core purpose without any wasted words. It's perfectly front-loaded and appropriately sized for what it communicates.
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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'terminate' means operationally, what side effects occur, what permissions are needed, or what the tool returns. Given the complexity of pipeline operations and lack of structured behavioral information, the description should provide more context about this irreversible-seeming 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?
Schema description coverage is 100%, so the schema already documents both parameters (ProjectId and Id). The description doesn't add any parameter-specific information beyond what's in the schema. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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 '终止发布流程' (terminate release pipeline) clearly states the action (terminate) and resource (release pipeline). It distinguishes from siblings like 'StopWorkflowInstances' or 'DeleteWorkflowDefinition' by focusing specifically on pipeline runs. However, it doesn't explicitly differentiate from 'ExecPipelineRunStage' or 'GetPipelineRun', which are related but not direct 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. The description doesn't mention prerequisites, consequences, or when this operation is appropriate compared to other pipeline-related tools like 'StopWorkflowInstances' or 'DeleteWorkflowDefinition'. The user 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.
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. '创建' (create) implies a write operation, but the description doesn't mention whether this requires admin permissions, what happens if the user already exists in the workspace, whether the operation is idempotent, or what the expected response looks like. For a mutation tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single Chinese phrase that directly states the tool's purpose with zero wasted words. It's perfectly concise and front-loaded, though this conciseness comes at the cost of completeness in other dimensions.
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 that creates workspace members with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after creation, what permissions are needed, potential side effects, or how this differs from related tools. The 100% schema coverage helps with parameters, but behavioral context 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?
The input schema has 100% description coverage, with all three parameters clearly documented in Chinese. The description doesn't add any parameter information beyond what's already in the schema, so it meets 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.
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 (workspace member) in Chinese. It's specific enough to understand the basic function, though it doesn't explicitly differentiate from sibling tools like 'GrantMemberProjectRoles' or 'RevokeMemberProjectRoles' 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.
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's no mention of prerequisites, when this tool is appropriate versus other member management tools like 'GrantMemberProjectRoles', or any context about required permissions or system state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. '删除' (delete) implies a destructive operation, but the description doesn't specify whether this deletion is permanent, requires specific permissions, has confirmation steps, or what happens to associated resources. For a destructive operation with zero annotation coverage, this is a significant gap in safety 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, efficient phrase that directly states the tool's purpose without any wasted words. It's appropriately sized for a simple deletion operation and front-loads the essential 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 destructive deletion tool with no annotations and no output schema, the description is insufficient. It doesn't address critical behavioral aspects like permanence, authorization requirements, error conditions, or what constitutes success. The context demands more disclosure for safe 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, with the single parameter 'Id' documented as '自定义规则的ID' (ID of the custom rule). The description doesn't add any additional parameter context beyond what the schema already provides, so it meets 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除自定义规则' (Delete custom rule) clearly states the verb ('删除' - delete) and resource ('自定义规则' - custom rule), making the purpose unambiguous. It doesn't explicitly distinguish from sibling tools like DeleteDataQualityRule or DeleteDIAlarmRule, but the specificity of 'custom rule' suggests a particular type of rule, earning 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. With many sibling deletion tools (DeleteDataQualityRule, DeleteDIAlarmRule, etc.), there's no indication of what makes an 'alert rule' different or when this specific deletion tool is appropriate. 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.
Behavior2/5
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. While '删除' implies a destructive operation, it doesn't specify whether deletion is permanent, requires specific permissions, has confirmation steps, or what happens to associated resources. This is inadequate for a destructive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese phrase that directly states the action. There's no wasted language or unnecessary elaboration, making it 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?
For a destructive deletion tool with no annotations and no output schema, the description is insufficient. It doesn't explain what '数据质量监控' refers to (task vs. rule vs. instance), doesn't warn about consequences, and provides no information about return values or error conditions. The context signals show this is a 2-parameter tool, but the description doesn't adequately address its 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?
The input schema has 100% description coverage, with both parameters clearly documented in Chinese ('DataWorks工作空间的ID' and '数据质量监控ID'). The description doesn't add any parameter information beyond the schema, but with complete schema coverage, the baseline is 3. The description's clarity about what's being deleted slightly enhances understanding, warranting a 4.
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 '删除数据质量监控' (Delete data quality monitoring) clearly states the verb ('删除' - delete) and resource ('数据质量监控' - data quality monitoring), making the purpose understandable. However, it doesn't specify what exactly is being deleted (a task, rule, or instance) or differentiate from sibling tools like DeleteDataQualityRule, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 multiple deletion tools in the sibling list (DeleteDataQualityRule, DeleteDataServiceApi, etc.), but the description offers no comparison, prerequisites, or context about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. '删除' implies a destructive mutation, but the description doesn't disclose behavioral traits like whether deletion is permanent, requires specific permissions, has side effects, or what happens to associated resources. This is a significant gap for a destructive operation 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.
Conciseness5/5
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 any wasted words. It's appropriately sized 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.
Completeness2/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 no annotations and no output schema, the description is incomplete. It doesn't address critical context like what the deletion entails, success/failure responses, or error conditions. Given the complexity and lack of structured data, more behavioral disclosure 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 description coverage is 100%, so the schema already documents all three parameters (DIAlarmRuleId, Id, DIJobId) with descriptions. The tool description adds no additional parameter semantics beyond what the schema provides, maintaining 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 states the action ('删除' meaning 'delete') and the resource ('数据集成同步任务告警规则' meaning 'data integration sync task alarm rule'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'DeleteAlertRule' or 'DeleteDataQualityRule', which might handle different types of alarm rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 exclusions. It doesn't mention when to use it over other delete tools like 'DeleteAlertRule' or what context requires this specific alarm rule deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While '删除' (delete) implies a destructive mutation, the description doesn't specify whether this operation is reversible, what permissions are required, or what happens to associated resources. It also doesn't mention error conditions or response format. For a destructive tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase in Chinese that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, with every word earning its place. No structural issues or verbosity are present.
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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical aspects like what happens after deletion, whether confirmation is needed, error handling, or the response structure. The description alone is insufficient for safe and effective use of this tool in 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 has 100% description coverage, with all three parameters clearly documented in Chinese. The description adds no parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_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.
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 resource (data integration sync job) in Chinese, which translates to 'Delete data integration sync job'. This is specific and unambiguous about what the tool does. However, it doesn't distinguish from sibling tools like DeleteDIAlarmRule or DeleteDataServiceApi, which have similar delete operations 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 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 are multiple delete tools in the sibling list (e.g., DeleteDIAlarmRule, DeleteDataServiceApi), but the description doesn't clarify that this is specifically for DI jobs rather than other resources. No prerequisites, exclusions, or contextual usage information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While '删除' implies a destructive mutation, the description doesn't specify whether this action is reversible, what permissions are required, or what the response looks like (e.g., success confirmation or error handling). For a destructive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundant information. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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 this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It should address behavioral aspects like irreversibility, permissions, or response format to help the agent understand the consequences and requirements of invocation. The current description is too minimal for safe and effective 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 has 100% description coverage (the single parameter 'Id' is documented as '血缘关系ID'), so the schema already provides the necessary parameter information. The description doesn't add any additional semantic context about the parameter beyond what's in the schema, which meets the baseline expectation when schema coverage is high.
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 (数据地图血缘关系/data map lineage relationship). It's specific about what gets deleted. However, it doesn't distinguish this tool from other deletion tools like DeleteAlertRule or DeleteDataQualityRule, which would require mentioning it specifically targets lineage relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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's no mention of prerequisites (e.g., needing the relationship ID), when not to use it, or what happens after deletion. With sibling tools like GetLineageRelationship and ListLineageRelationships available, the description should ideally indicate this is for removal after identification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While '删除' clearly indicates a destructive operation, the description doesn't mention whether this deletion is permanent, requires specific permissions, has confirmation steps, or what happens to dependent resources. For a destructive tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase that directly states the tool's purpose without any wasted words. It's appropriately sized for what it communicates and is front-loaded with the essential 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 destructive operation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like whether the deletion is reversible, what permissions are required, what happens to dependencies, or what the response contains. Given the complexity of a deletion operation and the lack of structured information, the description should provide more behavioral 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 input schema already documents both parameters (ProjectId and Id) with their descriptions. The tool description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info 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 ('删除' meaning delete) and the resource ('数据开发节点' meaning data development node), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like DeleteTask, DeleteWorkflow, or DeleteResource, which all perform deletion operations 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 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 are multiple deletion tools in the sibling list (DeleteTask, DeleteWorkflow, DeleteResource, etc.), but the description doesn't specify what makes a 'data development node' different or when this specific deletion tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. '移除' (remove) implies a destructive mutation, but the description doesn't disclose behavioral traits like whether this requires admin permissions, if the action is reversible, what happens to the member's data, or error conditions. This is inadequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('移除工作空间成员') that directly states the tool's purpose with zero wasted 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.
Completeness2/5
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 crucial context such as behavioral details (e.g., permissions, reversibility), usage guidelines, and expected outcomes, leaving significant gaps for an AI agent to operate safely and 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 schema description coverage is 100%, with clear descriptions for both parameters (ProjectId and UserId). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '移除工作空间成员' (Remove workspace member) clearly states the action (remove) and target (workspace member), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'RevokeMemberProjectRoles' or 'RemoveEntityFromMetaCollection', which might handle similar removal operations in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 prerequisites, conditions, or compare it to other member/role management tools in the sibling list, 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.
Behavior2/5
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 this is a deletion operation, implying it's destructive, but doesn't disclose critical behavioral traits like whether deletion is permanent/reversible, what permissions are required, whether it affects dependent resources, or what happens on success/failure. 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.
Conciseness5/5
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 any unnecessary words. It's appropriately sized and front-loaded with 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?
This is a destructive mutation tool with no annotations and no output schema. The description only states what it does at a high level without covering behavioral aspects (permanence, dependencies, permissions) or response format. Given the complexity and risk of a delete operation, the description is incomplete and 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 schema already documents both parameters (ProjectId and Id) with clear descriptions. The tool description adds no additional parameter information beyond what's in the schema. With high schema coverage, the baseline is 3 even without param details 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 ('删除' meaning delete) and the resource ('数据开发文件资源' meaning data development file resource), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from other delete operations in the sibling list (like DeleteAlertRule, DeleteDataQualityRule, etc.), 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.
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 are multiple delete operations in the sibling list (e.g., DeleteResource, DeleteNode, DeleteFunction), but no indication of which resource types each handles or any prerequisites for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states what the tool does ('获取数据开发函数详情') without revealing any behavioral traits such as whether it's a read-only operation, what permissions are required, how errors are handled, or what the return format looks like. 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.
Conciseness5/5
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 any unnecessary words. It's appropriately sized and front-loaded, with zero waste.
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 retrieving function details in a data development context, the description is incomplete. No annotations are provided to indicate safety or behavior, and there's no output schema to describe return values. The description alone doesn't explain what '详情' (details) includes, how results are structured, or any error conditions. For a tool with 2 parameters and no annotations/output schema, the description should provide more context about 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%, with both parameters ('Id' and 'ProjectId') clearly documented in the schema as 'UDF函数的唯一标识符' (UDF function's unique identifier) and 'DataWorks工作空间的ID' (DataWorks workspace ID). The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline of 3 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取数据开发函数详情' (Get data development function details) clearly states the verb ('获取' - get) and resource ('数据开发函数' - data development function). It distinguishes from siblings like 'CreateFunction', 'DeleteFunction', 'ListFunctions', 'MoveFunction', and 'RenameFunction' by specifying retrieval of details rather than creation, deletion, listing, moving, or renaming. However, it doesn't explicitly mention that it retrieves details for a specific function rather than all functions, which would make it a perfect 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 doesn't mention when to use 'GetFunction' versus 'ListFunctions' (which likely lists multiple functions) or other sibling tools like 'GetDataServiceApi' or 'GetNode'. There's no indication of prerequisites, context, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While '获取' (get) implies a read operation, the description doesn't specify whether this is a safe, idempotent query or if it has side effects. It also doesn't mention rate limits, authentication requirements, error conditions, or what the response format might be (since there's no output schema). For a status-checking tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('获取异步API运行状态') that directly states the tool's purpose without any wasted words. It's appropriately sized for a simple status-checking tool and is front-loaded with the essential 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what status information is returned (e.g., progress percentage, success/failure, error messages), how to interpret results, or any behavioral nuances. For a tool that retrieves operation status—which could involve complex states—this minimal description leaves significant gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 the JobId parameter clearly documented as '调用异步API后返回的任务ID' (task ID returned after calling an asynchronous API). The description doesn't add any additional parameter semantics beyond what the schema already provides. With high schema coverage, the baseline score of 3 is appropriate—the description neither compensates for gaps nor adds 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 '获取异步API运行状态' clearly states the purpose as retrieving the status of an asynchronous API operation. It uses a specific verb ('获取' meaning 'get') and resource ('异步API运行状态' meaning 'asynchronous API operation status'). However, it doesn't explicitly differentiate from sibling tools like 'GetTaskInstance' or 'GetWorkflowInstance' that might also retrieve status information for different 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 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 prerequisites (e.g., that a JobId must be obtained from a previous async API call), nor does it distinguish this tool from other status-checking tools in the sibling list like 'GetTaskInstance' or 'GetWorkflowInstance'. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read operation ('获取') but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding 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.
Conciseness5/5
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, making it easy to parse quickly.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what information is returned about the resource group, potential errors, or any behavioral constraints. For a tool that fetches specific data, more context is needed to use it 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 schema description coverage is 100%, with the single parameter 'Id' documented as '通用资源组唯一标识' (universal resource group unique identifier). The description adds no additional parameter semantics beyond what the schema provides, so it 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 the verb ('获取' meaning 'get') and resource ('资源组信息' meaning 'resource group information'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'ListResourceGroups' or 'GetResource', which are similar read operations on related 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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'ListResourceGroups' for listing multiple resource groups or 'GetResource' for individual resources, leaving the agent to infer usage context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('get route information') but lacks behavioral details such as required permissions, error handling (e.g., if ID is invalid), response format, or any side effects. For a read operation without annotations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('根据ID获取指定路由信息'), directly stating the purpose without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured for its 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?
Given the tool's simplicity (1 parameter, read-only implied), no output schema, and no annotations, the description is minimal. It states what the tool does but lacks context on behavior, output, or integration with other tools. For a basic retrieval tool, it's functional but incomplete, as it doesn't guide the agent on practical use or potential issues.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 the parameter 'Id' documented as '路由ID' (route ID). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate since the schema adequately covers the single 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 ('获取' meaning 'get') and resource ('路由信息' meaning 'route information'), specifying it's based on ID. It distinguishes from sibling tools like 'ListRoutes' by focusing on a single route retrieval rather than listing. However, it doesn't explicitly contrast with other 'Get' tools (e.g., 'GetDataServiceApi'), leaving some ambiguity in 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. The description doesn't mention prerequisites (e.g., needing a valid route ID), exclusions, or comparisons to similar tools like 'ListRoutes' for browsing or other 'Get' tools for different resources. 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.
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 states the tool retrieves logs but doesn't mention whether this is a read-only operation, what permissions might be required, the format or size of returned logs, or any rate limits. This leaves significant behavioral aspects undocumented for a tool that presumably accesses execution 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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's perfectly front-loaded and wastes no space, making it easy to parse quickly.
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 that retrieves execution logs with 2 parameters and no annotations or output schema, the description is insufficient. It doesn't explain what the logs contain, their format, whether they're truncated, or how to interpret them. The absence of behavioral context and output information makes this description incomplete for practical 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 description coverage is 100%, with both parameters ('Id' and 'RunNumber') clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what the schema already provides, such as explaining relationships between parameters or providing usage examples. The baseline score of 3 reflects adequate but minimal value addition.
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 ('获取' meaning 'get') and resource ('任务实例的运行日志' meaning 'task instance execution logs'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential sibling tools like 'GetTaskInstance' or 'ListTaskInstanceOperationLogs', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 are no explicit instructions about prerequisites, when-not scenarios, or references to sibling tools like 'GetTaskInstance' or 'ListTaskInstanceOperationLogs' that might serve related purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states this is a grant operation (implying mutation/permission assignment) but doesn't disclose important behavioral traits like required permissions, whether this overwrites existing roles, what happens if the user doesn't exist, rate limits, or what the response looks like. For a permission-granting tool with zero annotation coverage, 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.
Conciseness5/5
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 any unnecessary words. It's appropriately sized and front-loaded with the essential 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 role-granting mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after granting roles (success/failure responses), what valid RoleCodes are, permission requirements, or error conditions. The context demands more behavioral and operational information than 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%, so the schema already documents all three parameters (ProjectId, UserId, RoleCodes) with their descriptions. The description doesn't add any parameter-specific information beyond what's in the schema, such as format examples for RoleCodes or where to find UserId values. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('授予' meaning 'grant') and resource ('工作空间成员新的空间角色' meaning 'workspace member new workspace roles'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its sibling 'RevokeMemberProjectRoles', which handles the opposite 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 doesn't mention prerequisites (like needing admin permissions), when not to use it, or how it differs from similar tools like 'CreateProjectMember' or 'UpdateProjectMember' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a list operation. It doesn't disclose behavioral traits like pagination behavior (implied by parameters but not described), rate limits, authentication requirements, error conditions, or what happens when parameters are omitted. The description is minimal and lacks critical operational 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?
Extremely concise single sentence that directly states the tool's purpose. No wasted words or unnecessary elaboration. The description is front-loaded with the core functionality.
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 list tool with 4 parameters and no output schema, the description is insufficient. It doesn't explain the return format, pagination behavior, or typical response structure. With no annotations and no output schema, the agent lacks critical information about what to expect from 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%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters (e.g., how DIAlarmRuleId and JobId interact) or provide usage examples. Baseline 3 is appropriate when schema does the documentation 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 (获取/list) and resource (告警规则列表/alarm rule list) with specific context (数据集成同步任务/data integration sync task). It distinguishes from siblings like GetDIAlarmRule (singular) and CreateDIAlarmRule, but doesn't explicitly differentiate from other list tools like ListAlertRules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. The description doesn't mention when to use ListDIAlarmRules instead of GetDIAlarmRule (for single rule) or other list tools, nor does it provide context about prerequisites or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While '获取' (get/retrieve) implies a read operation, the description doesn't mention pagination behavior (implied by PageSize/PageNumber parameters), rate limits, authentication requirements, or what format the events list returns. For a tool with 6 parameters and no annotations, this is insufficient 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, efficient Chinese sentence that directly states the tool's purpose without unnecessary words. It's appropriately concise for a list/retrieval 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?
For a tool with 6 parameters, no annotations, and no output schema, the description is too minimal. It doesn't explain what constitutes an 'event', what information events contain, how results are structured, or provide any examples. The agent would need to guess about the return format and practical usage despite the complete parameter 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 schema already documents all 6 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain relationships between parameters (e.g., that StartTime/EndTime define a time range) or provide examples of EventType values. Baseline 3 is appropriate when the schema does the documentation 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 ('获取' meaning 'get' or 'retrieve') and resource ('数据集成同步任务的运行事件列表' meaning 'data integration synchronization task run events list'). It's specific about what it retrieves, though it doesn't explicitly differentiate from sibling tools like 'ListDIJobMetrics' or 'ListDIJobRunDetails' which might retrieve related but different 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. With many sibling tools like 'ListDIJobs', 'ListDIJobMetrics', and 'ListDIJobRunDetails', there's no indication of when this specific event listing tool is appropriate versus those other DI job-related list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While '获取' (get) implies a read operation, the description doesn't disclose important behavioral traits like whether this requires specific permissions, whether results are paginated (though PageSize/PageNumber parameters suggest pagination), rate limits, or what format the progress information takes. For a tool with 8 parameters and no annotations, this is insufficient 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, efficient Chinese sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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, no annotations, and no output schema, the description is inadequate. It doesn't explain what '执行进展' (execution progress) actually contains, how results are structured, or provide usage context. The agent would need to infer too much about this tool's behavior and output format from just the brief 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 description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions '执行进展' (execution progress) which aligns with the tool's purpose but doesn't provide additional parameter context. 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 clearly states the verb '获取' (get/retrieve) and the resource '数据集成同步任务运行的执行进展' (execution progress of data integration sync task runs). It's specific about what information is being retrieved. However, it doesn't explicitly differentiate from sibling tools like 'ListDIJobs' or 'ListDIJobEvents', which reduces it from 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 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. With many sibling tools available (like ListDIJobs, ListDIJobEvents, ListDIJobMetrics), there's no indication of when this specific progress-listing tool is appropriate versus other DI job-related listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the action ('获取列表' meaning 'get list') but doesn't describe pagination behavior (implied by PageSize/PageNumber), authentication needs, rate limits, or what happens if parameters are omitted. For a list tool with 7 parameters and no annotations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('获取数据集成同步任务配置列表') that directly states the purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste.
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 (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain return values (e.g., list structure, fields), error conditions, or behavioral aspects like pagination handling. For a list tool with rich filtering options, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 7 parameters documented in the input schema (e.g., ProjectId as workspace ID, PageSize with defaults). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating 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 verb ('获取' meaning 'get' or 'list') and resource ('数据集成同步任务配置列表' meaning 'data integration sync task configuration list'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'GetDIJob' (which likely retrieves a single job) or 'ListDIJobRunDetails' (which likely lists run details rather than configurations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 prerequisites (e.g., needing a ProjectId), exclusions, or comparisons to siblings like 'GetDIJob' or 'ListDIJobRunDetails', leaving the agent with no 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.
Behavior2/5
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 only states the query action without mentioning whether this is a read-only operation, if it requires specific permissions, what the return format looks like (e.g., paginated list), or any rate limits. For a tool with 6 parameters and no 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.
Conciseness5/5
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 any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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 (6 parameters, no output schema, and no annotations), the description is incomplete. It lacks information about behavioral traits, usage context, and output expectations. While the schema covers parameters well, the description fails to provide necessary context for safe and effective use, especially for a query tool in a data management system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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, thoroughly documenting all 6 parameters including 'TableId' (required), 'Order', 'PageSize', 'PageNumber', 'SortBy', and 'Name'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating 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 ('查询' meaning 'query') and resource ('数据地图数据表的分区列表' meaning 'partition list of data map data tables'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'GetPartition' or 'ListTables', which appear to serve related but distinct purposes in the same domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 are no explicit instructions about prerequisites, context, or comparisons to sibling tools like 'GetPartition' (which might retrieve a single partition) or 'ListTables' (which might list tables rather than partitions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states '获取' (get/list) which implies a read-only operation, but doesn't clarify pagination behavior (implied by PageSize/PageNumber parameters), rate limits, authentication needs, or what happens if parameters are omitted. For a tool with 5 parameters and no annotations, 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.
Conciseness5/5
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. It's front-loaded with no unnecessary words, making it highly concise and well-structured for quick 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?
Given the tool's complexity (5 parameters including pagination and sorting), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., list structure, error handling), behavioral constraints, or usage context. For a list operation with multiple parameters, more guidance 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 description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples of valid NetworkId formats or pagination defaults). With high schema coverage, the baseline is 3 even without param info 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 verb ('获取' meaning 'get' or 'list') and resource ('网络资源的路由列表' meaning 'network resource route list'), providing a specific purpose. However, it doesn't distinguish this tool from other list tools like ListNetworks or ListResources, which would require sibling differentiation 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.
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's no mention of prerequisites (e.g., needing a ResourceGroupId), exclusions, or comparisons to similar tools like GetRoute (which might fetch a single route). It's a bare statement of function 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. '移动' (move) implies a mutation/write operation, but the description doesn't disclose any behavioral traits: no information about permissions required, whether the operation is reversible, what happens to dependencies, error conditions, or rate limits. For a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase in Chinese that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's appropriately sized and front-loaded with the essential 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 annotations and no output schema, the description is insufficient. It doesn't explain what '移动' (move) entails operationally, what the expected outcome is, error conditions, or how this differs from other move operations. The 100% schema coverage helps with parameters, but behavioral context is critically lacking for a tool that modifies resources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 (ProjectId, Id, Path) are documented in the schema. The description adds no additional parameter information beyond what's already in the schema. With complete schema coverage, the baseline score 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '移动数据开发文件资源路径' clearly states the action (移动/move) and resource (数据开发文件资源路径/data development file resource path) in Chinese. It's specific about what the tool does, though it doesn't explicitly distinguish from sibling tools like MoveFunction, MoveNode, or MoveWorkflowDefinition, which all perform similar 'move' operations on different 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 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 are multiple 'Move' tools in the sibling list (MoveFunction, MoveNode, MoveWorkflowDefinition), but the description doesn't indicate this is specifically for 'Resource' objects or differentiate from those other move operations. No context about prerequisites or constraints is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 a removal action, implying a mutation, but doesn't disclose behavioral traits like whether this requires specific permissions, if the removal is reversible, what happens on success/failure, or any side effects (e.g., cascading impacts). For a mutation 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.
Conciseness5/5
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—every part of the sentence contributes to understanding the action and target.
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 (a mutation operation), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, reversibility, or error handling, and provides no context on usage versus siblings. For a 2-parameter mutation tool with no structured support, the description should do more 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?
Schema description coverage is 100%, with both parameters ('MetaCollectionId' and 'Id') documented in the schema. The description doesn't add any meaning beyond what the schema provides—it doesn't explain parameter relationships, formats, or examples. Baseline 3 is appropriate when the schema does the heavy lifting, though no extra value is added.
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 ('移除' meaning 'remove') and target ('实体对象' meaning 'entity object') from a specific resource ('数据地图集合' meaning 'data map collection'). It's specific enough to understand the basic operation, though it doesn't explicitly differentiate from sibling tools like 'DeleteMetaCollection' or 'AddEntityIntoMetaCollection' beyond the obvious action difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 prerequisites (e.g., needing the entity to already be in the collection), exclusions, or related tools like 'AddEntityIntoMetaCollection' or 'ListEntitiesInMetaCollection' for context. The agent must infer usage solely 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.
Behavior2/5
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. '重命名' implies a mutation/write operation, but the description doesn't specify whether this requires special permissions, whether the rename is reversible, what happens to references to the old function name, or what the response looks like. For a mutation tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Chinese phrase that directly states the tool's purpose. There's zero wasted language or unnecessary elaboration. It's appropriately sized for what it communicates.
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, the description is inadequate. It doesn't explain what happens after renaming, whether there are side effects, what permissions are needed, or what format the response takes. The agent must guess about the tool's behavior and 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 the schema already documents all three parameters (ProjectId, Id, Name) with Chinese descriptions. The tool description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation entirely through 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 ('重命名' meaning 'rename') and resource ('数据开发函数' meaning 'data development function'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'RenameNode', 'RenameResource', or 'RenameWorkflowDefinition' which perform similar rename operations on different 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives. There's no mention of prerequisites (like needing the function ID), when not to use it, or how it differs from other rename operations in the system. The agent must 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.
Behavior2/5
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. '重命名' (rename) implies a mutation operation, but the description doesn't specify permissions required, whether the change is reversible, what validation occurs on the new name, or what happens to dependencies. For a mutation tool with zero annotation coverage, this is insufficient 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, efficient Chinese phrase that communicates the core purpose without any wasted words. It's appropriately sized for a simple rename operation and gets straight to the point.
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, the description is inadequate. It doesn't explain what the tool returns, error conditions, side effects, or how it interacts with the system. Given the complexity of renaming a node in a data development environment (which likely has dependencies and validation rules), more context is needed for the agent to use this tool 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?
Schema description coverage is 100%, so the schema already documents all three parameters (ProjectId, Id, Name) with Chinese descriptions. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info 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 '重命名数据开发节点' (Rename data development node) clearly states the verb (rename) and resource (data development node), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like RenameFunction, RenameResource, and RenameWorkflowDefinition, which perform similar rename operations on different 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 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's no mention of prerequisites (like needing the node ID), what happens if the rename fails, or how this differs from other rename operations in the system. The agent must 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While '重命名' implies a mutation operation, the description doesn't disclose important behavioral traits like required permissions, whether the rename is reversible, potential side effects, or what happens to references to the renamed resource. For a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Chinese sentence that states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the essential 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 annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns, what permissions are required, potential error conditions, or how it differs from other rename operations. The description should provide more context about this specific rename operation's behavior 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?
Schema description coverage is 100%, so the schema already documents all three parameters (ProjectId, Id, Name) with Chinese descriptions. The tool description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info 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 ('重命名' meaning 'rename') and the resource ('数据开发文件资源' meaning 'data development file resource'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like RenameFunction, RenameNode, and RenameWorkflowDefinition, which perform similar rename operations on different 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 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 are multiple rename tools in the sibling list (RenameFunction, RenameNode, RenameWorkflowDefinition), but the description doesn't explain what distinguishes this particular rename operation or when it should be chosen over other rename tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. '重命名' implies a mutation operation, but the description doesn't state whether this requires specific permissions, whether the change is reversible, what validation occurs on the new name, or what happens to running instances. For a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, with every word 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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after renaming, whether there are side effects, what permissions are required, or what the response contains. Given the complexity of renaming a workflow definition in a data development environment, more context 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 description coverage is 100%, so the schema already documents all three parameters (ProjectId, Id, Name) with their descriptions. The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info 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 verb ('重命名' meaning 'rename') and resource ('数据开发工作流' meaning 'data development workflow'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'RenameFunction', 'RenameNode', or 'RenameResource', which all perform similar rename operations on different 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 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 prerequisites (like needing the workflow ID), when renaming is appropriate, or what happens to existing references after renaming. There's no comparison to sibling rename tools or other workflow modification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states this is a revocation action (implying mutation/destructive), but doesn't mention permission requirements, whether changes are reversible, what happens to the member's access, or any side effects. For a mutation tool with zero annotation coverage, 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.
Conciseness5/5
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 with zero wasted words. It's appropriately sized and front-loaded with 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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after revocation, whether there are confirmation steps, what the response looks like, or error conditions. Given the complexity of role management and zero structured coverage, more context 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 description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema (ProjectId, UserId, RoleCodes). 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 the action ('撤销' meaning 'revoke') and the resource ('空间成员的空间角色' meaning 'space member's space roles'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling tool 'GrantMemberProjectRoles' beyond the obvious opposite action, missing an explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 specific contexts. While the presence of 'GrantMemberProjectRoles' as a sibling implies this is for removing rather than adding roles, there's no explicit when/when-not guidance or mention of other related tools like 'DeleteProjectMember'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states this is a revocation action (implying mutation/destructive), but doesn't mention required permissions, whether the change is reversible, what happens to existing permissions not mentioned, or any rate limits. The description is minimal and lacks critical behavioral context for a permission management 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, efficient Chinese phrase that directly states the tool's purpose with zero wasted words. It's appropriately sized for what it communicates.
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 permission revocation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after revocation, whether there are confirmation steps, what the response looks like, or error conditions. The minimal description leaves significant gaps for understanding this mutation 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 6 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. This meets the baseline of 3 when schema coverage is high.
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 (revoke) and resource (table permissions) in Chinese. It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'RevokeMemberProjectRoles' or 'ApprovePermissionApplyOrder' which handle different permission 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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when not to use it, or how it relates to sibling tools like 'GrantMemberProjectRoles' or 'CreatePermissionApplyOrder' for permission management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While 'stop' implies a state change operation, the description doesn't specify whether this is reversible, what permissions are required, whether it's synchronous or asynchronous, or what happens to in-progress data. For a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Chinese phrase that directly conveys the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the essential 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 that stops data integration jobs, the description is insufficient. With no annotations, no output schema, and multiple similar 'stop' tools in the sibling list, the description should provide more context about what this tool specifically does, when to use it, and what behavioral characteristics it has.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales 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 (InstanceId, Id, DIJobId) including the deprecation warning for DIJobId. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline for high schema coverage without adding 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 action ('停止' meaning 'stop') and the target resource ('数据集成同步任务' meaning 'data integration synchronization task'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'StopTaskInstances' or 'StopWorkflowInstances' that also stop different types of tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 are multiple other 'stop' tools in the sibling list (StopTaskInstances, StopWorkflowInstances), but the description doesn't explain what distinguishes this tool for stopping DI jobs specifically. No prerequisites or context for usage is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. '终止' (stop/terminate) implies a destructive mutation, but the description doesn't clarify whether this is reversible, what permissions are required, whether it affects downstream tasks, or what the expected outcome is. For a mutation tool with zero annotation coverage, this minimal description leaves critical behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go 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 phrase that directly states the tool's purpose with zero wasted words. It's appropriately sized for what it communicates, though it could benefit from additional context. The front-loaded nature makes the core function immediately 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?
For a destructive mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'stop' means operationally, whether the action is reversible, what permissions are required, how it differs from suspension, or what happens to task dependencies. Given the complexity of stopping task instances in a workflow system, this minimal description leaves too many contextual 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%, with both parameters ('Ids' and 'Comment') clearly documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info 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 '终止任务实例' (Stop task instances) clearly states the action (stop/terminate) and target resource (task instances). It distinguishes from siblings like 'StopWorkflowInstances' and 'StopDIJob' by specifying task instances rather than workflows or DI jobs. However, it doesn't explicitly differentiate from 'SuspendTaskInstances' which might be a similar 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. There's no mention of prerequisites, when this operation is appropriate versus suspension or deletion, or what happens to dependent tasks. With multiple task-related tools in the sibling list (StopWorkflowInstances, SuspendTaskInstances, RerunTaskInstances), the lack of comparative guidance 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.
Behavior2/5
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 the conversion action but doesn't cover critical details like input format expectations (e.g., date/time string formats), output format (e.g., Unix timestamp in seconds or milliseconds), error handling, or whether it's a read-only operation. This leaves significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's function without any fluff. It's front-loaded and wastes no words, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain the return values (e.g., what the timestamps look like), error conditions, or input formatting requirements. For a tool with one parameter but no structured output documentation, more context is needed to ensure reliable 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 description coverage is 100%, with the parameter 'DateTimeDisplay' documented as an array of strings for dates or times. The description adds minimal value beyond this, only implying that the input consists of dates or times without specifying formats or constraints. Given the high 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.
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: converting dates or times to timestamps. It specifies the verb ('转成' meaning 'convert to') and the resource ('时间戳' meaning 'timestamps'), making the function unambiguous. However, it doesn't differentiate from the sibling tool 'ConvertTimestamps', which appears to serve a similar purpose, preventing 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 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 the sibling tool 'ConvertTimestamps' or any other context for selection. The lack of usage instructions leaves the agent without clear decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 this is an update operation, implying mutation, but doesn't mention whether it requires specific permissions, if changes are reversible, what happens to existing metadata not specified, or any rate limits. This leaves significant 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?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., permissions, side effects), usage context, and return values, leaving the agent with incomplete information to operate the tool 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 schema description coverage is 100%, so the schema already documents both parameters ('Id' and 'Description') adequately. The description adds no additional parameter details beyond what's in the schema, such as examples or constraints, resulting in 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 clearly states the verb ('更新' meaning 'update') and the resource ('数据地图数据表字段的业务元数据' meaning 'business metadata of data table fields in the data map'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'UpdateTableBusinessMetadata', which might handle metadata at the table level rather than column 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?
The description provides no guidance on when to use this tool versus alternatives, such as 'UpdateTableBusinessMetadata' for table-level updates or other metadata tools. It lacks context about prerequisites, permissions, or typical scenarios for updating column business metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'update' which implies mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with 14 parameters and 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.
Conciseness5/5
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 the essential 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 (14 parameters, mutation operation) and lack of annotations/output schema, the description is inadequate. It doesn't explain what 'development information' entails, the update scope, or behavioral context. For a tool with this many parameters and no structured safety hints, more descriptive context 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 description coverage is 100%, so the schema already documents all 14 parameters thoroughly with descriptions, enums, and constraints. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline for 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 ('更新' meaning 'update') and target ('数据服务API开发态的信息' meaning 'data service API development information'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'UpdateDataSource' or 'UpdateDataQualityRule', which follow similar naming patterns for 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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an existing API), exclusions (e.g., cannot update published APIs), or related tools like 'CreateDataServiceApi' or 'PublishDataServiceApi' from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states what the tool does ('get list') without mentioning whether it's read-only, if it requires authentication, how results are returned (e.g., pagination, format), or any rate limits. This is a significant gap for a 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.
Conciseness5/5
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 any unnecessary words or fluff. It's front-loaded and appropriately sized for a simple listing 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?
Given the tool's simplicity (0 parameters) and lack of annotations or output schema, the description is minimal. It states the purpose but fails to provide behavioral context (e.g., read-only nature, return format), which is needed for the agent to use it effectively. This makes it incomplete despite the low 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?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't mention parameters, which is appropriate here since none exist. A baseline of 4 is applied as it compensates adequately for the lack of parameters by not introducing confusion.
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 ('获取' meaning 'get/retrieve') and resource ('数据地图元数据采集器类型列表' meaning 'data map metadata crawler type list'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'ListDataSources' or 'ListFunctions', which also list resources, though the resource type 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 versus alternatives. It lacks context about prerequisites, typical use cases, or comparisons to other listing tools in the sibling set, leaving the agent to infer usage based solely on 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.
Behavior2/5
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 the tool queries a list, implying a read-only operation, but does not specify if it requires authentication, has rate limits, returns paginated results, or details error conditions. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase in Chinese ('查询数据源分享规则列表') that directly conveys the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for a simple list 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?
Given the tool's low complexity (a list query with two optional parameters), no annotations, and no output schema, the description is minimally adequate. It states what the tool does but lacks details on behavior, output format, or usage context, making it incomplete for fully informed agent invocation without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need 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, fully documenting both parameters ('DataSourceId' and 'TargetProjectId') in Chinese. The description does not add any additional meaning beyond the schema, such as explaining parameter interactions or default behaviors. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation 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 '查询数据源分享规则列表' (Query data source sharing rule list) clearly states the verb ('查询' - query) and resource ('数据源分享规则列表' - data source sharing rule list), indicating it retrieves a list of sharing rules for data sources. It does not explicitly differentiate from sibling tools like 'GetDataSource' or 'ListDataSources', which focus on data sources themselves rather than their sharing rules, but the purpose 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 other list tools or related operations. It lacks context about prerequisites, exclusions, or typical scenarios, leaving the agent to infer usage based on 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

alibabacloud-dataworks-mcp-server MCP server

Copy to your README.md:

[![alibabacloud-dataworks-mcp-server MCP server](https://glama.ai/mcp/servers/aliyun/alibabacloud-dataworks-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/aliyun/alibabacloud-dataworks-mcp-server)

Score Badge

Copy to your README.md:

[![alibabacloud-dataworks-mcp-server MCP server](https://glama.ai/mcp/servers/aliyun/alibabacloud-dataworks-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/aliyun/alibabacloud-dataworks-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aliyun/alibabacloud-dataworks-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server