huawei-lts-skill

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
Many tools have nearly identical names (ListLogStream vs ListLogStreams, ShowAomMappingRule vs ShowAomMappingRules) and all descriptions are generic, providing no clarity. Typos and irregular casing (Createfavorite, ListBreifStructTemplate) further blur boundaries.
Naming Consistency3/5
Most tools follow a consistent Create/Delete/List/Update/Show pattern, but there are clear exceptions like ConsumerGroupHeartBeat, lowercase 'favorite' names, and a typo in ListBreifStructTemplate. The overall convention is readable but not uniform.
Tool Count1/5
92 tools is excessive for an MCP server and will severely overload an agent's context and selection process. Even a comprehensive API wrapper should be split into smaller, focused servers or curated to essential operations.
Completeness4/5
The tool set covers CRUD operations for most core LTS resources (log groups, streams, access configs, alarm rules, transfers, etc.), with only minor gaps such as no update for log stream index or individual log group retrieval. Overall the domain is well-covered.
Average 1.4/5 across 92 of 92 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It states nothing about side effects, required permissions, rate limits, or what the operation does to resources. The description is completely uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is very short but not concisely informative—it is an under-specification that does not earn its place. It provides no value beyond the tool name itself.
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?
Although the schema shows nested objects, there is no operational context, no return value description, and no behavioral details. For a tool with this complexity and no output schema, the description is severely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters including a nested body object, but the description adds zero explanation about parameter meanings or relationships. With only 50% schema coverage and no description support, the agent has no assistance in constructing a valid request.
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 'Huawei Cloud LTS operation CreateNotificationTemplate' is a tautology—it merely restates the tool name with generic wording. It provides no specific verb, resource, or action detail, so the agent cannot determine what the 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?
There is no guidance on when to use this tool versus alternatives. Sibling tools like UpdateNotificationTemplate and ListNotificationTemplate exist, but the description gives no context for selecting among them.
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 behavior. It does not mention any side effects, permissions, pagination, return format, or other behavioral traits. The description is entirely empty of behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, uninformative phrase. This is under-specification, not conciseness. It offers no structured information about purpose, usage, or behavior.
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?
With no annotations, no output schema, and minimal parameter guidance, the description is wholly inadequate. The tool is one of many similar list operations, and without additional context, even the basic purpose is unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with log_group_id and log_stream_id having no descriptions. The tool description adds no parameter meaning whatsoever, failing to compensate for the missing schema details. Even the described parameters (region, project_id) are self-explanatory, but their relationship to the operation is not clarified.
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 is 'Huawei Cloud LTS operation ListHistorySql.' which is a tautology—it restates the name without providing any verb, resource, or outcome. It does not explain what ListHistorySql does, making it impossible to distinguish from the many other List* 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?
No guidance is provided on when to use this tool versus alternatives. With over 70 sibling tools, many of which are also list operations, the lack of any context or exclusions leaves the agent without 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 present, so the description must carry the full burden of behavioral disclosure. It fails entirely: there is no mention of side effects, mutation, required permissions, rate limits, response behavior, or any other runtime trait. The tool's behavior is completely opaque.
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 short sentence, which is not conciseness but under-specification. It conveys no meaningful content beyond the tool name, so the sentence does not earn its place. A concise description should be short yet informative; this one is merely short.
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 of the body schema, the absence of annotations, and no output schema, the description is wholly inadequate. The agent cannot determine required parameters, expected result, error conditions, or side effects. The description is complete only in the sense of being entirely void of task-relevant information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (region and project_id have descriptions), but the 'body' parameter—a large nested object with over 30 properties—has no schema description. The tool description adds zero parameter semantics and does not compensate for the half-documented body. This is a serious gap for an operation that clearly requires a complex payload.
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 'Huawei Cloud LTS operation CreateAccessConfig' is essentially a tautology—it restates the tool name and adds only a generic product prefix. It does not specify what CreateAccessConfig does, what resource it acts on, or what effect it produces, and it does not distinguish from any of the many other Create* 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?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites, constraints, or scenarios. It is purely nominal and offers no decision support.
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. It does not state that this is a mutating operation, what side effects it has, whether it requires prior resources, error conditions, or permissions. The agent has no insight into the operation's behavior 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?
The description is a single short sentence, but it is under-specification rather than conciseness. It omits all substantive content, making it ineffective despite its brevity.
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 creation tool with 5 parameters, a nested body, no output schema, and no annotations. The description fails to explain the operation's purpose, parameter semantics, side effects, or expected return value, making it completely inadequate for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (region and project_id have minimal overrides). The description adds no parameter context whatsoever. The nested body properties (timeout, create_time, consumer_group_name) are unexplained, and it is unclear how top-level group_id/stream_id relate to body log_group_id/log_stream_id.
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 is a tautology: 'Huawei Cloud LTS operation CreateConsumerGroup' merely restates the tool name without explaining what the operation does. It does not identify the resource (consumer group) or the action (creation) beyond the name, and it is indistinguishable from sibling tools like CreateLogGroup or CreateAccessConfig.
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 does not mention use cases, prerequisites, or the relationship to other resources such as log groups and log streams, nor does it exclude other options.
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 disclosing behavioral traits, but it offers none. It does not mention whether the operation is destructive, requires specific permissions, has side effects (e.g., creates a dashboard resource), or any rate limits or error conditions. The agent is left completely uninformed.
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 short, but this is under-specification rather than concise efficiency. It consists of a single sentence that only restates the tool name. There is no front-loading of useful information; the sentence earns no place as it provides zero 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 three parameters, a nested object, no annotations, and no output schema, the description is woefully incomplete. The agent cannot determine required inputs, expected behavior, or return values. A minimal viable description would at least explain that it creates a dashboard and what the body fields represent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics. While the schema includes descriptions for 'region' and 'project_id' (overrides), the nested 'body' parameters 'title' and 'group_name' are undocumented, and their meaning is not clarified anywhere. The tool name implies creating a dashboard, but the description does not explain how the parameters relate to that operation.
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 'Huawei Cloud LTS operation CreateDashBoard' is a pure tautology that restates the tool name without providing any information about what the tool actually does. It fails to specify the verb's resource, action, or outcome, and offers no differentiation from similar sibling tools like CreateDashboardGroup.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any use cases, prerequisites, or exclusions. Given the large sibling list with similar Create* operations, the agent receives no help in selecting 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?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states that this is an 'operation,' with no mention of effects (e.g., creating a dashboard group), required permissions, side effects, or return values. This is a complete failure to 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than effective conciseness. The single sentence does not earn its place because it simply repeats the tool name. There is no useful structure or front-loaded 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 moderate schema richness (nested body, region, project_id) and no output schema or annotations, the description is severely inadequate. It provides no context about the operation, no parameter guidance, and no distinction from numerous sibling create tools. This is one of the lowest-completeness descriptions possible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to any of the three parameters. The schema already indicates that body.group_name is a string and that region/project_id override environment variables, but the description does not explain group_name's purpose or relationship to the operation. Schema coverage is 67%, but the description fails to compensate for the missing coverage, especially for the nested body parameter.
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 is a tautology: 'Huawei Cloud LTS operation CreateDashboardGroup.' It merely restates the tool name without specifying what the operation does, what resource it creates, or what makes it distinct from sibling tools like CreateDashBoard or CreateLogGroup. There is no verb-resource clarity 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?
No guidance is provided on when to use this tool versus alternatives. The description does not indicate use cases, prerequisites, or exclusions. Sibling tools such as CreateDashBoard and CreateLogGroup suggest different resources, but the description gives no basis for choosing this one.
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, and the description carries the full burden of behavioral disclosure. It does not mention whether the operation is a read or write, side effects, permissions, or any other behavioral trait. The description is completely unhelpful.
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 short, but this is under-specification rather than concise writing. It contains zero useful information and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested object schema, no output schema, no annotations, and no meaningful description. The description is completely inadequate for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 67% coverage (region and project_id have descriptions), but the main 'body' parameter with eight properties is entirely undocumented. The description adds no meaning to any parameter, failing to compensate for the low schema coverage of the nested object.
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 is 'Huawei Cloud LTS operation Createfavorite.' It simply restates the tool name and adds no verb or resource specifics. It does not indicate what the tool actually does, making it a pure tautology.
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?
There is no guidance on when to use this tool versus alternatives like Deletefavorite or other create tools. The description provides no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 transparency, but it discloses nothing about side effects, permissions, rate limits, or data transformation. It does not contradict annotations because there are none, but it is entirely uninformative.
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 short sentence, but it is under-specification rather than conciseness. It does not earn its place because it adds no value beyond the tool name, failing the test of every sentence contributing 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?
The tool has a complex nested schema with many parameters, no output schema, and no annotations. The description is completely inadequate, omitting return values, side effects, prerequisites, and any operational context. This falls far short of what is needed for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the input schema. The schema has a nested 'body' object with many undocumented properties, and the description does not explain any of them. Even the top-level parameters 'region' and 'project_id' are not referenced, leaving the agent without semantic guidance for any parameter.
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 'Huawei Cloud LTS operation CreateLogDumpObs' merely restates the tool name and domain, providing no functional information about what the tool actually does. It fails to state the operation's purpose, such as creating a log dump to OBS, and does not distinguish it from 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?
No guidance is provided on when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions, leaving the agent without any decision-making support.
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. However, it reveals nothing about side effects, required permissions, idempotency, or error behavior. For a creation operation, an agent needs to know what gets created, any constraints, and what happens on conflict, none of which are mentioned.
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 short, but this is under-specification rather than conciseness. The single sentence merely repeats the tool name and adds a generic cloud context ('Huawei Cloud LTS operation'), so it does not earn its place. It lacks any substantive content that would justify its brevity.
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 (nested objects, no output schema, no annotations), the description is entirely inadequate. It must explain what the operation does, what the body parameter expects, and how log_group_id relates to the creation, but it provides none of this. The agent is left with only an opaque name and partial schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 50%, with only region and project_id having descriptions ('Overrides HUAWEI_REGION', etc.). The description text adds no parameter information at all, leaving body and log_group_id almost entirely unexplained. The description fails to compensate for the missing schema documentation, providing zero added meaning beyond the schema.
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 is a tautology: 'Huawei Cloud LTS operation CreateLogStream' merely restates the tool name and cloud provider without stating what the operation does, what resource it acts on, or what effect it has. It provides no specific verb or resource beyond the name itself, so an agent cannot determine the tool's 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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or comparisons to sibling tools like CreateLogGroup or ListLogStreams. The agent receives no help in deciding between this and other LTS 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?
With no annotations, the description carries the full burden of behavioral disclosure but reveals nothing beyond the generic 'operation' label. It does not state whether this creates, updates, or deletes, nor does it mention side effects, permissions, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. The single sentence provides no meaningful information and is essentially a placeholder, making it ineffective despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested body and no output schema or annotations, yet the description offers no details about return values, required inputs, or operational behavior. It is completely inadequate for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all. Although the schema documents region and project_id, the body's nested fields lack descriptions, and the description fails to compensate for this gap.
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 restates the tool name as 'Huawei Cloud LTS operation CreateStructConfig,' which is a tautology. It does not specify a verb, resource, or action, nor does it distinguish from related tools like CreateStructTemplate.
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 or how it compares to alternatives. The description offers no context about prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description discloses zero behavioral traits. It does not mention whether the deletion is permanent, requires specific permissions, affects related resources, or returns a response. The description completely fails to inform the agent about the operation's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than conciseness. The single sentence restates the tool name and provides zero useful information, so it does not earn its place.
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 delete operation with no annotations, no output schema, and a description that explains nothing. The agent cannot infer what resource is being deleted, the request requirements, or the consequences. The description is completely inadequate for safe and correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes three parameters, but the description adds no semantic meaning to any of them. The nested 'body.access_config_id_list' remains unexplained, and the description does not compensate for the 67% schema coverage gap by clarifying what these values represent or how they are used.
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 is a tautology: 'Huawei Cloud LTS operation DeleteAccessConfig' merely restates the tool name without specifying what action it performs. It does not differentiate this from sibling delete operations such as DeleteLogStream or DeleteTransfer.
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, prerequisites, or alternatives. The description offers no contextual signals beyond the product name, leaving the agent without any basis for choosing this over 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention that deletion is likely destructive/irreversible, whether associated charts can be deleted, or any required permissions. The description adds no transparency about the operation's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than conciseness. The single sentence provides no useful information and does not earn its place, making it an empty tautology.
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 delete operation with 4 parameters, no annotations, and no output schema, the description is completely inadequate. It fails to explain return values, side effects, required context, or any meaningful details necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with 'id' and 'is_delete_charts' lacking descriptions. The description adds no additional meaning about parameter semantics, leaving the agent without a clear understanding of how to populate these fields.
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 'Huawei Cloud LTS operation DeleteDashboard' is a tautology that simply restates the tool name without explaining what the operation does, what a dashboard is, or what LTS is. It provides no specific verb+resource information beyond the tool's 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?
There is no guidance on when to use this tool versus alternatives like DeleteLogGroup or DeleteLogStream. The description does not indicate prerequisites, scenarios, or exclusions, leaving the agent with no contextual 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?
Since no annotations are provided, the description must disclose behavioral traits. It only says 'operation,' giving no indication that deletion is destructive, whether it requires special permissions, or if it affects associated resources. No return or side effects are mentioned.
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 short (one sentence), but this is under-specification rather than conciseness. It earns no structural points because it fails to convey essential information; it is effectively a title, not a functional explanation.
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 (4 parameters, one nested object), lack of annotations/output schema, and many sibling tools, this description is completely inadequate. It does not explain what a notification template is, what deletion entails, or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description offers zero insight into the parameters. It does not explain that 'template_names' is the list of templates to delete, nor does it clarify the role of 'domain_id' or the nested 'body' object. The schema covers 50% of parameters with descriptions, but the tool description adds no value over the schema.
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 is a single phrase, 'Huawei Cloud LTS operation DeleteNotificationTemplate,' which merely restates the tool name without specifying the action. It does not state that it deletes a notification template, nor does it distinguish this from sibling delete tools like DeleteLogGroup or DeleteTransfer.
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 such as ListNotificationTemplate or UpdateNotificationTemplate. The description lacks any context, prerequisites, or scenarios where 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits. It does not mention destructive effects, permissions, rate limits, or any side effects. The description carries the full burden but fails to address it.
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 sentence, but it conveys no useful information. This is under-specification rather than conciseness, as the sentence does not earn its place by adding value beyond 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?
With 5 parameters, no annotations, no output schema, and a nested object, the description is completely inadequate. It fails to provide any context about parameters, return values, or operational requirements, leaving the agent without essential guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, and the description adds no parameter meaning whatsoever. The body object, group_id, and topic_id are entirely undocumented, and the description does not compensate for the lack of schema descriptions.
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 merely restates the tool name and says it is an 'operation', providing no verb or resource beyond the name itself. It does not state what the tool does, such as deleting search criteria from Huawei Cloud LTS.
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?
There is no guidance on when to use this tool versus alternatives. Sibling tools like CreateSearchCriterias and ListCriterias are not mentioned, and no context or exclusion criteria 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 the full burden of disclosing behavior. It does not state that this is a read-only listing operation, does not mention pagination, ordering, filtering, or any side effects. The name implies 'list' but the description itself is silent.
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 brief, but this is under-specification, not conciseness. It is a fragment that fails to convey necessary information, earning no place in a well-structured 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 complex tool with 7 parameters, nested objects, and no output schema or annotations. The description is a single phrase that provides almost no context, making it completely inadequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (only region and project_id have descriptions). The description does not compensate by explaining any of the 7 parameters or nested objects. It adds zero value beyond the schema.
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, 'Huawei Cloud LTS operation ListActiveOrHistoryAlarms,' adds no information beyond the tool's name. It is a tautology: it merely restates the tool name with a generic 'operation' prefix. There is no verb, no resource, and no distinction from 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 provides zero guidance on when to use this tool versus the many sibling tools like ListKeywordsAlarmRules or ListSqlAlarmRules. No context, 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.
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 reveals nothing about pagination, required vs optional parameters, return behavior, permissions, or side effects. The description simply restates the operation name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It contains zero informative content beyond what the name already conveys, making it a tautological label rather than a useful summary.
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?
With no output schema and no annotations, the description must explain the tool's purpose, inputs, and outputs. It does none of these. The tool has six parameters but no hint about which are needed, what the result list looks like, or how pagination works.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about any of the six parameters. Schema coverage is only 33%, with only 'region' and 'project_id' having 'Overrides' descriptions. The description does not compensate for the lack of documentation on 'limit', 'offset', 'log_group_id', or 'log_stream_id'.
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 'Huawei Cloud LTS operation ListCharts' is essentially a restatement of the tool's name. It provides no verb beyond the name itself and no explanation of what 'Charts' refers to or what the operation does. It does not distinguish this from the many other 'List*' 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?
There is no guidance on when to use this tool versus alternatives. No context is provided about prerequisites, typical scenarios, or how it relates to other LTS list operations like ListLogStreams or ListLogs.
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, and the description carries the full burden of behavioral disclosure. It gives no information about side effects, required permissions, pagination, return format, or any other behavioral traits. The description is entirely uninformative.
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 brief, but this is under-specification rather than conciseness. It is a single phrase that merely names the operation, providing no useful structure or substance.
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 (5 parameters, no output schema, no annotations) and the large set of sibling tools, the description is woefully incomplete. It does not explain what the tool returns, how it differs from similar list tools, or any operational details, making it nearly impossible for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters. While the schema covers 40% of parameters (region and project_id have descriptions), the remaining 60% (group_id, topic_id, search_type) are undocumented, and the description does not compensate. With low schema coverage, the description should clarify the parameters but does not.
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 is essentially a tautology: 'Huawei Cloud LTS operation ListCriterias' restates the tool name without specifying what it does. It lacks a clear verb and resource, and does nothing to distinguish this tool from siblings like ListQueryAllSearchCriterias or CreateSearchCriterias.
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?
There is no guidance on when to use this tool or when to use an alternative. The description provides zero context about the intended use case, prerequisites, or relationship to sibling 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, and the description gives no behavioral details. It does not state whether the operation is read-only, what permissions are required, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is under-specified and tautological. It lacks substance, so it is not effectively concise.
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?
With 5 parameters, no output schema, no annotations, and a proverbially empty description, the tool is completely inadequate for an AI agent to understand purpose, usage, or parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40% (region and project_id have descriptions), but the description adds no parameter context. The key parameters (group_id, stream_id, consumer_group_name) remain undocumented.
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 merely restates the tool name ('Huawei Cloud LTS operation ListDetailsConsumerGroup') without stating what the operation actually does. It does not distinguish from sibling tools like ListConsumerGroup.
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. There is no mention of prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It provides none: no read-only/write indication, no mention of pagination, return format, or required permissions. The agent cannot anticipate side effects or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence is concise in length, but it is under-specification, not efficiency. It contains no substantive information beyond the tool name, so it fails to earn its place as a meaningful 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?
The tool has nested parameters, no output schema, and no annotation context. The one-line description leaves the agent without essential information about filtering options or list behavior, making it completely inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics. While region and project_id have schema descriptions ('Overrides HUAWEI_REGION.'), the body/filter object is entirely undocumented in both schema and description. With 67% schema coverage, the main parameter lacks any meaning beyond its name.
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 'Huawei Cloud LTS operation ListHostGroup' merely restates the tool name and prefixes the service name. It does not state what the operation does (e.g., listing host groups with optional filters) or distinguish it from sibling tools like ListHost. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 ListHostGroup versus ListHost or other list operations. No use cases, 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?
No annotations are present, and the description carries the full burden of behavioral disclosure. The description reveals nothing about whether this operation is read-only, what permissions are needed, side effects, limits, or return characteristics.
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 short but this is under-specification, not conciseness. It is a single placeholder sentence that carries no useful information, while the tool's complexity (nested body object, multiple parameters) demands more explanation.
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 five parameters, a nested body structure, no output schema, and no annotations, this description is completely inadequate. An agent could not infer the operation's purpose, parameters, or behavior from this text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter meaning. Schema coverage is only 40% (region and project_id have descriptions), and the body object with time__, line_num, scroll_id, forwards_size, backwards_size remains unexplained. The tool name suggests 'context' but the meaning and purpose of these parameters are not clarified.
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 'Huawei Cloud LTS operation ListLogContext' is a tautology that merely restates the tool name without explaining what the operation does. It fails to mention the verb or resource, and provides no distinction from sibling tools like ListLogs or ListLogStream.
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?
There is no guidance on when to use this tool or how it differs from alternatives such as ListLogs or ListLogStream. No context, prerequisites, 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?
With no annotations and no description of behavior beyond 'operation', the tool's side effects, return format, pagination, or auth requirements are entirely undisclosed. The agent has no information about what invoking this tool will do.
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 brief but under-specified. One sentence that repeats the tool name without adding substantive detail is not effective conciseness; it lacks essential 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?
With no annotations, no output schema, a nested body schema with undocumented properties, and no behavioral explanation, the description is far from complete for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information. Although region and project_id have schema descriptions, the nested body object with seven properties has no explanations for fields like start_time, end_time, group_id, stream_id, key_word, is_iterative, or step_interval, and the description does not compensate for this gap.
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 merely restates the tool name as 'Huawei Cloud LTS operation ListLogHistogram' without stating what the tool does. It provides no verb, resource, or outcome, making it essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, when not to use it, or how it differs from sibling tools like ListLogs or ListLogContext. The description gives no context for selection among alternatives.
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, and the description offers no behavioral details. It does not disclose whether this is a read-only operation, any pagination behavior, authentication requirements, or rate limits, which is essential for a cloud API.
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 short (one clause) but fails to convey any meaningful information. This is under-specification rather than conciseness, as the single sentence doesn't earn its place.
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?
With 5 top-level parameters, a nested body object, and numerous sibling tools, this description is completely inadequate. It offers no context on purpose, usage, behavior, or parameters, making it impossible for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 40%, with descriptions only for region and project_id. The description does not compensate by explaining the body, log_group_id, log_stream_id, or any other parameters. Agents are left without guidance on required values or relationships.
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 only states 'Huawei Cloud LTS operation ListLogs,' which restates the tool name without explaining what the operation does. It doesn't describe the action (listing logs) or distinguish it from sibling tools like ListLogStream or ListLogContext.
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 ListLogs versus alternatives. Sibling tools include several other listing operations (ListLogGroups, ListLogStreams, etc.) but the description offers no differentiators or 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 must disclose behavioral traits, but it offers none. There is no indication of read-only/write behavior, whether the operation supports pagination, what the return format is, or any side effects. The agent has zero insight into the tool's runtime behavior.
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 short, but it is under-specified rather than concise. The single sentence is a waste because it repeats the tool name without adding information. True conciseness would pack meaningful content into few words; this fails to do so.
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 3 parameters, no output schema, and no annotations, the description is completely inadequate. It should cover basic purpose, when to use it, and how parameters affect the operation. Instead, it provides nothing beyond the name, leaving the agent unable to select or invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for region and project_id ('Overrides HUAWEI_REGION' and 'Overrides HUAWEI_PROJECT_ID'), but log_group_id has no description. The tool description adds no parameter semantics and does not clarify how log_group_id relates to the listing operation. Since schema coverage is only 67% and the description is silent, parameter meaning remains unclear.
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 is a tautology: 'Huawei Cloud LTS operation ListLogStream' merely restates the tool name without specifying what the operation does. It fails to identify the resource (log streams) or the action (list) beyond the name itself. The existence of a sibling tool 'ListLogStreams' makes this even more confusing, as the singular/plural distinction is not explained.
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?
There is no guidance on when to use this tool versus alternatives. The description provides no context about the intended use case, such as listing log streams under a specific log group, nor does it mention any exclusions or alternatives among the numerous sibling 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 must fully disclose behavior. It does not mention whether this is a read-only listing, any pagination behavior, required authorization, output format, or any other operational trait. The agent gets no information 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?
The description is short, but this is under-specification, not effective conciseness. It conveys no actionable information, so the brevity is unhelpful rather than 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?
Even though the tool is simple (4 flat params, no nested objects), the description leaves all key context missing: what the tool returns, what the parameters mean, and when it should be invoked. The absence of an output schema makes the description even more critical, and it completely fails to address this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (region and project_id have descriptions, limit and offset do not). The description adds no parameter meaning whatsoever. For a list operation, the semantics of limit and offset are important but not explained anywhere, and the description does not compensate for the coverage gap.
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 is essentially a restatement of the tool name: 'Huawei Cloud LTS operation ListNotificationTopics.' It provides no verb or resource description beyond the name itself, making it a tautology. There is no explanation that this tool lists notification topics or any distinguishing detail vs. sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like ListNotificationTemplate, ListNotificationTemplates, or ShowNotificationTemplate. The description entirely lacks context for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries the full burden, but it discloses nothing about behavior, side effects, permissions, or return values. It's a bare 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?
One sentence, but it is under-specification rather than conciseness. It simply restates the tool name; no useful content.
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?
With no output schema, three parameters, and a complex API context, the description is completely inadequate. It doesn't explain the operation's purpose, return value, or relation to similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. While the schema has descriptions for region and project_id, group_id is undocumented, and the description adds no meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description repeats the tool name ('ListQueryAllSearchCriterias') with a generic prefix, providing no verb, resource, or functionality. It fails to distinguish from siblings like ListCriterias or CreateSearchCriterias.
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 on when to use this tool vs alternatives. The description is merely a label; it doesn't indicate the use case, prerequisites, or alternatives.
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 mentions nothing about whether this is a read operation, how results are returned, pagination, rate limits, or required permissions. The description is entirely devoid of 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not conciseness. It contains only a single vacuous sentence that wastes the opportunity to convey essential information. A concise, effective description would be longer with meaningful detail.
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 5 parameters, nested body structure, no output schema, and no annotations, this description is wholly inadequate. The complexity is high, but the description offers no guidance on request structure, filtering logic, or response format. Agents have virtually no basis to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40%, leaving most parameters undocumented. The description adds zero parameter meaning. The schema only explains region and project_id overrides; body, log_group_id, and log_stream_id remain unexplained. With low coverage and no description compensation, agents cannot correctly populate parameters.
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 is a pure tautology: 'Huawei Cloud LTS operation ListQueryStructuredLogs.' It restates the tool name without defining what the operation does. It fails to mention that it lists or queries structured logs, leaving the actual 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 Guidelines1/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. Given many similar list/query siblings (e.g., ListStructuredLogsWithTimeRange), the lack of any comparison or when-to-use context is a critical 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 present, and the description does not disclose any behavioral details such as query semantics, time-range handling, security requirements, or side effects. The description adds nothing 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?
The description is extremely brief but this is under-specification, not effective conciseness. It fails to include any meaningful content while being a single tautological sentence.
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 no output schema, no annotations, and a rich set of sibling tools, the description is completely inadequate. It does not explain return values, required context, or how this operation differs from similar listing operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, with body and log_stream_id undocumented. The description offers no parameter meanings, formats, or relationships, so the agent gets no additional value.
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?
Description only restates the tool name as 'Huawei Cloud LTS operation ListStructuredLogsWithTimeRange.' It provides no verb or resource explanation, so the agent cannot determine what the tool does 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?
No guidance on when to use this tool versus closely related siblings like ListLogs, ListQueryStructuredLogs, or ListLogContext. No use cases, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral details such as what data is queried, whether it is read-only, pagination behavior, rate limits, or prerequisites. The description carries the full burden and fails completely.
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 short but this is under-specification, not conciseness. It lacks any meaningful content, making it unhelpful despite its brevity.
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 complex tool with nested objects, no output schema, and no annotations. The description is a single sentence that adds no value, leaving the agent without essential context for invocation. It is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has moderate 67% coverage (region and project_id have descriptions), but the 'body' parameter and all nested properties are undocumented. The description adds no parameter meaning whatsoever, leaving users to guess the semantics of fields like 'topn', 'filter', and 'sort_by'.
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 'Huawei Cloud LTS operation ListTopnTrafficStatistics' is a tautology that merely restates the tool name. It does not specify what the tool does, what resource it acts on, or what 'ListTopnTrafficStatistics' means, making purpose entirely 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?
No guidance is provided on when to use this tool or how it differs from alternatives. Notably, sibling tool 'ListTimeLineTrafficStatistics' appears similarly named, but no distinction or selection criteria are offered.
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 for behavioral disclosure. It discloses nothing about side effects, required permissions, or operational characteristics. The agent cannot know if this tool mutates state, creates resources, or is safe to invoke.
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 short sentence, but conciseness is not the same as under-specification. This text provides almost no useful content, so the brevity is not a virtue. It is closer to a placeholder than a carefully crafted concise 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?
With no annotations, no output schema, a nested body object, and no behavioral context, the description is completely inadequate. An agent would have no idea what this tool does, what inputs mean, what results to expect, or what side effects may occur.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes a 'body' object with kafka_name, instance_id, and connect_info, but the description provides no explanation of these or how they relate. Although region and project_id have descriptions in the schema, the crucial body parameter is untouched. The description adds zero semantic information beyond what the bare field names imply.
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 'Huawei Cloud LTS operation RegisterDmsKafkaInstance' merely restates the tool name and adds a generic platform prefix. It does not specify what 'RegisterDmsKafkaInstance' does, what resource it acts on, or how it differs from any of the many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. The description provides no context, prerequisites, or conditions under which an agent should select this tool over similar LTS 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 present, so the description must fully disclose behavioral traits. It provides none: no indication of read-only vs. mutating behavior, permissions required, side effects, rate limits, or return value structure. The agent is left completely in the dark about what the tool does when invoked.
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 short sentence, but it is under-specification rather than conciseness. It contains no substantive content that helps an agent, so the brevity is not a virtue.
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?
With 6 parameters, no output schema, no annotations, and a one-line non-description, this tool is severely under-documented. An agent cannot determine what the tool does, how to use it, or what it returns. This is completely inadequate for even basic operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description adds no parameter information beyond what is already in the schema. The bare parameters (_from, group_id, shard_id, stream_id) are not explained, and the description offers no guidance on how they relate to the operation or how to construct valid input.
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 'Huawei Cloud LTS operation ShowCursorByTime' merely restates the tool name with a service qualifier. It does not state what the operation does, what action is performed, or what resource it acts on. It is indistinguishable from sibling tools like ShowCursorTime and gives no verb+resource clarity.
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 usage guidance is provided. There is no mention of when to use this tool versus alternatives such as ShowCursorTime, ListLogs, or other cursor-related operations. The description offers no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses nothing about side effects, read-only vs. mutating behavior, cursor semantics, or any operational characteristics. The description adds zero value beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification, not conciseness. A single tautological sentence does not earn its place because it provides no actionable 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?
This tool has 6 parameters, no output schema, no annotations, and a complex sibling context. The description is completely inadequate for an agent to understand what the operation does, when to invoke it, or how to construct a valid request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 6 parameters and only 33% schema description coverage, the description needed to compensate by explaining parameter roles. Instead, it offers no parameter information at all. The only useful parameter descriptions come from the schema itself (region and project_id overrides), which are not sufficient.
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 merely restates the tool name and cloud service ('Huawei Cloud LTS operation ShowCursorTime') without a specific verb or resource. It is tautological and provides no information about what the tool actually does, failing to distinguish it from siblings like ShowCursorByTime.
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?
There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are provided, leaving the agent without any basis for selection among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 fails to mention any side effects, required preconditions, permissions, or the fact that the tool mutates checkpoint state. 'Update' implies mutation, but no consequence or prerequisite is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The phrase is short, but this is under-specification rather than conciseness. Every word ('Huawei Cloud LTS operation') contributes no information beyond the tool name itself. A concise description should pack meaning, not just repeat the title.
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?
With 7 parameters, no output schema, and no annotations, this complex operation requires substantial description. The single tautological phrase is completely inadequate for an agent to select, invoke, or verify the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, leaving most parameters (body, group_id, stream_id, consumer_name, consumer_group_name) undocumented. The description adds nothing to explain the purpose of these parameters or how they relate, making it impossible for an agent to construct a valid request.
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 'Huawei Cloud LTS operation UpdateCheckPoint' merely restates the tool name with a product prefix. It does not state what updating a checkpoint does, what resource it acts on, or how it differs from sibling tools like ShowCursorTime or ConsumerGroupHeartBeat.
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?
There is no guidance on when to use this tool, when not to, or which alternatives to consider. The description provides zero contextual clues about the checkpoint workflow, such as whether it is required after consuming log data or before resetting cursors.
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 discloses nothing about side effects, permissions, whether it is destructive, or what the operation actually changes. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It provides no actionable information. The brevity is not a virtue here; it fails to earn its place by adding any 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?
This is a complex tool with a deep nested request body, no output schema, no annotations, and many sibling tools. The description is completely inadequate for an agent to understand what the tool does, when to invoke it, or how to construct parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, but that coverage is only for trivial override parameters (region, project_id). The main 'body' parameter is a large nested object with dozens of undocumented properties. The description adds zero parameter semantics, failing to compensate for the schema's opaque structure.
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 'Huawei Cloud LTS operation UpdateKeywordsAlarmRule' is purely tautological. It restates the tool name and adds a generic 'operation' label, with no verb describing the action (e.g., 'Updates a keyword alarm rule') or the resource affected. It does not distinguish from the many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. There is no mention of prerequisites, use cases, or exclusions. Users are left to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is a partial or full replacement, what fields are required, whether it is idempotent, what side effects occur, or what the response looks like. The phrase 'Update' implies mutation but offers no detail about consequences, permissions, or state changes.
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 brief, but this is under-specification rather than conciseness. A single sentence that restates the tool name does not earn its place; it provides no actionable information. The structure is not front-loaded with useful content because there is no useful content.
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 tool has high complexity: a deeply nested 'body' parameter, no output schema, no annotations, and a large sibling list. The description is one vague sentence that explains nothing. It is completely inadequate for an agent to understand the operation, its inputs, or its effects. Even basic context about the Huaweicloud LTS domain is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, but the main 'body' parameter, a complex nested object, has no description in the schema. The tool description adds no parameter explanations whatsoever. It does not clarify what 'body' should contain, what each nested field means, or how 'region' and 'project_id' overrides work beyond their schema descriptions. The agent is left without essential semantic context for constructing valid input.
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 'Huawei Cloud LTS operation UpdateLogConvergeConfig' merely restates the tool name prefixed with a cloud service domain. It does not explain what 'LogConvergeConfig' is, what 'Update' does, or how it differs from sibling tools like ShowLogConvergeConfig or UpdateLogGroup. This is essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. There is no mention of prerequisites, typical scenarios, or relationships with sibling tools such as ShowLogConvergeConfig, which likely retrieves the same configuration. The description gives the agent no information to select this tool appropriately.
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, and the description contains zero behavioral information. It does not mention the effect of the update, potential risks, prerequisites, or permissions, leaving the agent entirely uninformed.
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 short, but it is under-specified rather than concise. The single sentence adds no useful information and fails to earn its place.
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?
With 5 parameters, a nested body, no output schema, and no annotations, the description is wholly inadequate. An agent cannot infer the semantics, required inputs, or potential side effects of this operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description does not compensate. The schema defines parameters like body, log_group_id, and log_stream_id without explanation, and the description adds no meaning to any of them.
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 'Huawei Cloud LTS operation UpdateLogStream' merely restates the tool name with the generic word 'operation'. It lacks a specific verb and resource description, and does not distinguish this tool from sibling tools like UpdateLogGroup or UpdateAccessConfig.
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?
There is no guidance on when to use this tool or when to choose an alternative. Given the large set of sibling tools, the description provides no context for selecting this operation.
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, and the description discloses zero behavioral traits. It does not mention whether the operation is a read or write, whether it has side effects (e.g., updating heartbeat timestamps), or whether it requires specific permissions or pre-existing resources.
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 very short, but it is under-specified rather than concise. The single phrase 'Huawei Cloud LTS operation ConsumerGroupHeartBeat' adds no information beyond the tool name itself, so the brevity does not serve the user.
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 (7 parameters, no annotations, no output schema), the description is severely incomplete. It fails to explain the operation's purpose, behavior, parameters, or expected results, making it impossible for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters, but only region and project_id have descriptions (29% coverage). The description provides no information about the other 5 parameters (body, group_id, stream_id, consumer_name, consumer_group_name), so the agent has no semantic guidance beyond the bare parameter names.
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 'Huawei Cloud LTS operation ConsumerGroupHeartBeat' is a tautology that merely restates the tool name without specifying any action or outcome. It does not indicate what a 'heart beat' does (e.g., sends a keep-alive signal, checks consumer group health), nor does it distinguish this tool from siblings like CreateConsumerGroup or ListConsumerGroup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 or what context it is appropriate for. There are no references to alternatives, prerequisites, or exclusions, leaving the agent without any criteria for selecting this tool over its many siblings.
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 disclosing behavioral traits like side effects, required permissions, or idempotency. The description provides none of this, giving no indication of what happens when the tool is invoked or what the consequences are.
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 short, but this is under-specification rather than conciseness. It contains a single vague clause that provides no useful information, failing to earn its place by not conveying any actionable content.
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 has 4 parameters, nested objects, no output schema, and no annotations, the description is completely inadequate. It does not help the agent understand how to invoke the tool, what inputs are needed, or what to expect as a result. This is a critical gap for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to any parameter. The schema covers only 50% of parameters with descriptions (region and project_id), leaving the body fields (ttl_in_days, log_group_name, etc.) undocumented. The description does not compensate, so the agent has no semantic understanding of what values to supply.
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 'Huawei Cloud LTS operation CreateLogGroup' is essentially a tautology—it restates the tool name without specifying what the operation does. It adds only the service context (Huawei Cloud LTS) but no actual verb or resource behavior, making it indistinguishable from a generic operation declaration.
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?
There is no guidance on when to use this tool versus any alternative. No mention of prerequisites, typical scenarios, or exclusions. The description simply states it is an operation, leaving the agent to infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'operation' and gives no details about effects, permissions, or side effects, making it impossible to anticipate what happens when invoked.
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 sentence, but it is under-specified rather than concise. It repeats the tool name and provides no structural value or informative content.
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 5 parameters, a nested body object, no output schema, and no annotations, this description is critically incomplete. It fails to provide operational context, parameter guidance, or behavioral expectations, making the tool effectively unusable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40% with region and project_id described, and the description adds zero parameter information. The body fields (name, criteria, search_type, etc.) remain undocumented, and the description does not compensate for the low schema coverage.
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 'Huawei Cloud LTS operation CreateSearchCriterias' merely restates the tool name and adds no verb+resource detail. It does not explain what the tool actually does or how it differs from sibling create operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any mention of prerequisites like group_id/topic_id or contrast with DeleteSearchCriterias or ListCriterias.
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 exist, so the description carries full responsibility for disclosing behavior. It does not mention side effects, permissions, required services, or what creating a transfer entails.
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 rather than concise. A single sentence that merely restates the tool name does not provide value; it is a placeholder, not an efficient specification.
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 of the nested body schema, the lack of annotations, and no output schema, the description is completely inadequate. An agent cannot understand what this tool does, when to use it, or how to structure the request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the schema. While schema coverage is 67% (region and project_id are described), the critical 'body' parameter and its nested fields lack any explanation. The schema field names are somewhat self-explanatory, but the description does not compensate for the missing semantics of the complex body structure.
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 'Huawei Cloud LTS operation CreateTransfer' is a tautology that restates the tool name without specifying what resource or action is involved. It fails to distinguish CreateTransfer from numerous sibling Create* tools like CreateLogGroup or CreateLogStream.
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. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent without any contextual decision support.
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 says nothing about deletion being destructive or irreversible, required permissions, consequences for associated log streams, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is tautological and adds no value beyond the tool name. It is under-specified rather than concise, failing to earn its place.
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 delete operation with no annotations and no output schema, this description is critically incomplete. It leaves the agent guessing about the meaning of log_group_id, deletion scope, and preconditions, making confident invocation impossible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 2 of 3 parameters with 'Overrides' descriptions, but the tool description itself adds no parameter meaning. The log_group_id parameter is left undocumented, and with moderate schema coverage (67%), the description should compensate but does not.
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 only restates the tool name ('Huawei Cloud LTS operation DeleteLogGroup') without specifying that it deletes a log group. It is a tautology and provides no information that would distinguish it from sibling tools like DeleteLogStream or UpdateLogGroup.
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?
There is no guidance on when to use this tool, what prerequisites exist, or how it relates to alternatives such as CreateLogGroup, UpdateLogGroup, or ListLogGroups. The description provides no usage context whatsoever.
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, yet it reveals nothing about side effects, permissions, pagination, or result format. The tool could be a read-only listing or something else with no indication.
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 text is short, but it is under-specified rather than concise. A single sentence that merely repeats the tool name does not earn credit for efficiency; it is a placeholder.
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 no annotations, no output schema, and a vague description, the context is completely inadequate. The agent has no understanding of what the tool does, what inputs matter, or what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (region and project_id are described, but log_group_name and log_stream_name are not). The description adds zero parameter meaning, so it fails to compensate for the low schema coverage.
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 merely states 'Huawei Cloud LTS operation ListLogStreams,' which is a tautology restating the tool name. It fails to convey that this tool lists log streams, let alone any specifics about its scope or behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool versus alternatives like ListLogStream (singular) or ListLogGroups, and no context for typical 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 the full burden for behavioral disclosure. It does not state whether this is a read-only operation, what it returns, whether pagination is involved, or any other behavioral traits. The description is essentially empty of behavioral content.
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 brief, but this is under-specification rather than effective conciseness. A single sentence that merely restates the tool name wastes the opportunity to convey useful information. It is not appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 5 parameters, the description should provide substantial context. It offers none. The tool cannot be correctly invoked or understood from this description alone, making it completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description should compensate for undocumented parameters like limit, offset, and domain_id. However, the description says nothing about parameters at all, adding no semantic meaning beyond the schema. This is a significant gap.
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 is a tautology: 'Huawei Cloud LTS operation ListNotificationTemplates' merely restates the tool name without explaining what the operation does. It provides no verb+resource beyond the name itself, which is not enough to distinguish it from siblings like ShowNotificationTemplate or DeleteNotificationTemplate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or distinctions such as singular vs plural 'NotificationTemplate' variants. It simply lacks any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits such as read-only status, pagination, filtering, or error conditions. The description carries no burden of transparency, resulting in a complete lack of behavioral information.
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 sentence, but it is under-specified rather than concise. It wastes the opportunity to provide meaningful information, making it insufficient for agent use.
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 has no output schema and no annotations, the description should explain return values or operational context. It does neither, making it completely inadequate for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 67% parameter description coverage, with region and project_id having descriptions but id lacking any. The description adds no semantic meaning beyond the schema, and the undocumented id parameter remains unexplained.
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 'Huawei Cloud LTS operation ListStructTemplate' merely restates the tool name without specifying what the operation does. It provides no verb or resource detail, making it a tautology that fails to distinguish it from sibling tools like ShowStructTemplate or ListBreifStructTemplate.
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 given on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 says nothing about side effects, read-only nature, required permissions, return values, or error behavior. The name implies a read operation, but the description does not confirm it.
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 short but under-specified. It is a single sentence that adds no information beyond the title, making it wasteful rather than concise. There is no front-loaded useful content.
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?
With three parameters, no output schema, and no annotations, the description must provide substantial context. Instead it offers none, making it completely inadequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (region and project_id have override descriptions, rule_id has none). The description adds no parameter meaning; it does not explain what rule_id represents or how parameters relate to the tool's function. The override hints are already in the schema, leaving rule_id unexplained.
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 is 'Huawei Cloud LTS operation ShowAomMappingRule,' which merely restates the tool name with a vendor prefix. It does not specify what the tool does, what resource it acts on, or what 'ShowAomMappingRule' means.
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?
There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are provided, leaving the agent with no information to choose this over sibling 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, what permissions are required, what the response contains, or any side effects. The word 'Show' suggests a read operation, but this is not explicit, and no behavioral details are given.
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 sentence, which is concise in length, but it is a minimal under-specification that restates the tool name. The structure provides no useful information, making this under-specification rather than effective conciseness.
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 tool has no annotations, no output schema, and a vague one-line description. Given the complexity implied by the name and the many sibling operations, the description is completely inadequate. It provides no context about the operation's purpose, behavior, return values, or parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes region and project_id as overrides, which adds some context, but member_account_id has no description and the meaning of 'converge config' is undefined. With 67% schema coverage (below the high threshold), the description does not compensate for the gap, leaving the tool purpose unclear and parameter semantics incomplete.
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 'Huawei Cloud LTS operation ShowLogConvergeConfig' is a tautology that restates the tool name without explaining what the operation does. It fails to identify the resource 'converge config' or provide any functional meaning, and does not distinguish it from siblings like UpdateLogConvergeConfig or ShowAdminConfig.
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 gives no information about when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions. The sibling list includes many 'Show' and 'List' operations, but no guidance is provided to help select this one.
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 it provides none. It does not state whether the operation is read-only, what data it returns, or any side effects. The agent cannot infer the safety profile or runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not effective conciseness. It contains zero informative content and does not earn its place. It provides no value beyond the tool name and product 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 has 4 parameters, no annotations, and no output schema, the description is completely inadequate. It fails to explain what the operation does, which the agent needs to understand input requirements, expected outputs, or any related operations. The context is entirely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, leaving log_group_id and log_stream_id entirely unexplained. The description does not compensate for this gap; it mentions no parameters at all. The agent has no insight into what the parameters mean or how they influence the operation.
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 merely restates the tool name as 'Huawei Cloud LTS operation ShowStructTemplate.' It does not specify what 'ShowStructTemplate' does, nor does it distinguish this operation from siblings like 'ListStructTemplate' or 'CreateStructTemplate.' The verb 'Show' and the resource are implied by the name, but the description adds no new clarity.
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 given on when to use this tool versus alternatives. The description does not mention prerequisites, intended scenarios, or related tools. There is no context to help an agent decide when to invoke this operation.
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 disclosing behavior. It does not mention that this tool likely modifies an alarm rule's status, any side effects, required permissions, or potential errors. The description is behaviorally opaque.
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 short, but brevity here is under-specification rather than conciseness. It contains only a restatement of the name and a vague 'operation' label. A well-structured description would front-load the purpose but still provide substantial guidance. This fails to convey any meaningful 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?
For a tool with a nested object parameter, no output schema, and no annotations, the description is grossly incomplete. It provides no context about expected inputs, behavior, or return values. An agent would be completely unable to craft a correct invocation based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 67% (region and project_id have descriptions), but the description adds no parameter-level meaning. The 'body' parameter, which is an object with nested properties (type, status, alarm_rule_id), is completely undocumented. The description does not explain what these fields represent or how they relate to the tool's action.
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 is a tautology: 'Huawei Cloud LTS operation UpdateAlarmRuleStatus.' It merely restates the tool name with a generic 'operation' label, offering no explanation of what the tool actually does (e.g., updating the status of an alarm rule). There is no specific verb or resource described beyond what is already in 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 no guidance on when to use this tool versus any alternative. It does not mention prerequisites, typical scenarios, or why one would choose this tool over sibling tools like UpdateKeywordsAlarmRule or UpdateSqlAlarmRule. There is no context to help an agent select it appropriately.
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?
There are no annotations, and the description carries the full burden of behavioral disclosure. It fails to mention whether the operation mutates state, what resources are affected, whether permissions are required, whether it is idempotent, or what side effects may occur.
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 short, but brevity is not conciseness when no information is conveyed. It is a tautological restatement of the tool name and fails the requirement that every sentence earn its place.
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 no annotations, no output schema, and a complex nested body parameter, this description is completely inadequate. It leaves the agent without any understanding of the operation's purpose, behavior, parameters, or return value, making correct invocation essentially impossible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents region and project_id as overrides, but the nested body object and its five properties are completely unexplained. The description adds no parameter meaning, and the body fields like template_id, log_group_id, and template_type are ambiguous without further context.
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 'Huawei Cloud LTS operation UpdateStructConfig' merely restates the tool name without explaining what the operation does. It does not specify a verb plus resource, nor does it distinguish this from closely named siblings like UpdateStructTemplate, CreateStructConfig, or ShowStructTemplate.
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 the many sibling tools. There is no mention of intended scenarios, prerequisites, or alternatives, leaving the agent without any 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?
There are no annotations, and the description says nothing about side effects, permissions, whether the operation overwrites an existing template, or any other behavioral traits. This leaves the agent completely uninformed about the operation's implications.
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 sentence, but it is under-specified rather than concise. It adds no value beyond the tool name, so it does not earn its place. The brevity is not a virtue here because it contains no actionable 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 complex nested schema, lack of output schema, and absence of annotations, the description is drastically incomplete. It fails to explain the operation's purpose, prerequisites, or expected behavior, making the tool effectively unusable for an AI agent without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters. While the schema includes descriptions for region and project_id ('Overrides HUAWEI_REGION'), the complex 'body' object with nested properties like rule, layers, content, and tokenizer is entirely undocumented. With 67% schema description coverage, the description does not compensate for the unexplained body fields.
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 'Huawei Cloud LTS operation UpdateStructTemplate.' simply restates the tool name with the generic word 'operation.' It lacks a specific verb and resource description, and does not distinguish this tool from closely related siblings like UpdateStructConfig or ShowStructTemplate.
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, what prerequisites exist, or how it compares to alternatives. The sibling list shows related operations, but the description gives no indication of the appropriate context for UpdateStructTemplate.
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, the description carries the full burden of disclosing behavior, but it reveals none. It does not state whether the operation is mutating, what effects it has, whether it can be reverted, or what inputs are needed beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified rather than informative. It wastes the opportunity to convey meaningful information, making the brevity detrimental rather than helpful.
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 has no output schema and no annotations, the description is the only source of context. It fails to explain what the operation does, how it works, or what results to expect, leaving the agent completely in the dark.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 67% of parameters (region and project_id have descriptions), but the tool description adds no semantic meaning. The key parameter 'log_converge_switch' is left completely undocumented, and the description does not explain how the parameters relate to the operation.
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 'Huawei Cloud LTS operation UpdateSwitch' merely restates the tool name and provides no action or resource context. It does not specify what the switch does, what it updates, or how it differs from 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?
No guidance is given about when to use this tool versus the many sibling update tools (e.g., UpdateLogGroup, UpdateAccessConfig). There is no mention of prerequisites, contexts, or scenarios for which this operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It discloses nothing about side effects, permissions, idempotency, or error conditions. The one-line phrase provides zero 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 a single sentence, but it is under-specified rather than concise. It fails to provide any meaningful information, so the sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested schema with no output schema or annotations, yet the description offers no context about what the operation does, how to invoke it, or what to expect in return. This is wholly inadequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions exist for region and project_id, but the main 'body' parameter has no description, and the tool description does not clarify how to populate it. The nested structure contains many fields (e.g., log_streams, log_transfer_info) with no guidance on required combinations or formats, leaving a significant semantic gap.
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 "Huawei Cloud LTS operation UpdateTransfer" merely restates the tool name and adds no functional detail. It fails to state what resource is updated or what effect the operation has, and it does not distinguish this tool from siblings like CreateTransfer or DeleteTransfer.
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, what prerequisites exist, or how it relates to alternative tools. Sibling tools such as CreateTransfer, DeleteTransfer, and ListTransfers are present, but no comparison or selection criteria are offered.
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 available, the description is the sole source of behavioral disclosure. It offers no insight into side effects, reversibility, prerequisites, or what 'disabling' entails. The agent cannot anticipate the operation's impact.
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 very short, but this is under-specification rather than concise efficiency. It provides no meaningful content, so the brevity is not a virtue. It fails to earn its place by adding any 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?
The tool has no annotations or output schema, and the description must compensate but does not. It gives no information about the operation's effect, scope, or relationship to other tools. An agent cannot determine the tool's purpose or how to invoke 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% (both region and project_id have descriptions), so the baseline is 3. The description itself adds no parameter guidance, but the schema already explains the parameters adequately, making 3 appropriate.
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 'Huawei Cloud LTS operation DisableLogCollection.' merely restates the tool name without specifying what disabling log collection actually does. It lacks a verb indicating the action's effect or the resource it operates on, making it a tautology rather than a clarifying statement.
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 sibling 'EnableLogCollection' directly relates, but the description does not mention it or any conditions that would warrant disabling log collection. The agent is left without any decision support.
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 must disclose behavior, but it only states the operation name. It does not describe side effects, required permissions, idempotency, or what changes occur, leaving the agent blindly invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise in length but not in substance. The sentence 'Huawei Cloud LTS operation EnableLogCollection' is an under-specification that wastes the opportunity to convey meaningful details, similar to a placeholder.
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 no annotations and no output schema, the description is the sole source of context. It fails to explain what the tool does, when it applies, or what to expect, making it completely inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents both parameters with descriptions covering 100% of the schema, so the baseline applies. The description adds no additional semantic meaning, but the schema alone is sufficient for parameter understanding.
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 merely restates the tool name as 'Huawei Cloud LTS operation EnableLogCollection' without explaining what enabling log collection accomplishes. It fails to specify the resource affected or the effect of the operation, making it a pure tautology.
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?
There is no guidance on when to use this tool, no mention of prerequisites, and no comparison to alternatives like DisableLogCollection. The description offers zero 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description offers no behavioral information—no side effects, read-only status, or limitations. The description is a bare phrase that repeats the tool's identity.
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 it is short, this is under-specification rather than concise clarity. The single sentence contributes no operational detail and could be replaced by the tool name itself.
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 nested body schema, an absent output schema, and no annotations, the description is grossly incomplete. It neither explains returned data, filtering semantics, nor how host listing works.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for region and project_id, and the body object is structurally defined with filter fields and host_id_list. With 67% schema description coverage, the schema carries the parameter semantics; the description adds nothing but is not required to compensate.
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 merely restates the tool name ('ListHost') as 'Huawei Cloud LTS operation ListHost,' providing no verb-resource specificity beyond the name itself. It fails to distinguish this host-listing operation from sibling list tools like ListHostGroup.
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 on when to use ListHost versus alternatives such as ListHostGroup or ListLogStream. No context about prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 fails to state that this is a read-only list operation, whether pagination is involved, or what the response contains. The description reveals no behavior beyond the name, leaving the agent without 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is severely under-specified rather than concise. It repeats the tool name and provides 'Huawei Cloud LTS operation' as boilerplate, offering no unique information. Every word is wasted because none of it helps the agent understand the tool's function.
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 a simple list operation with optional parameters and no output schema, the description is still completely inadequate. It fails to state the resource type (keyword alarm rules), the list semantics, or any relation to sibling tools like CreateKeywordsAlarmRule or UpdateKeywordsAlarmRule. The agent is left without enough context to correctly select or invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters, both with clear 'Overrides' descriptions. The tool description adds no additional parameter semantics, but the baseline of 3 is appropriate because the schema already fully documents the parameters and their override behavior.
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 is a tautology: it merely restates the tool name as 'Huawei Cloud LTS operation ListKeywordsAlarmRules.' It does not specify that the tool lists keyword alarm rules or what that entails. The name itself hints at the function, but the description adds no clarifying verb or resource distinction beyond the title.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention related operations like ListSqlAlarmRules or describe context such as listing alarm rules for monitoring. No exclusions, prerequisites, or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits such as read-only semantics, pagination, or side effects. It discloses none of these, offering only the operation name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It repeats the tool name and provides no useful content, so it fails to earn its place.
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?
Despite having no output schema and only two optional parameters, the description delivers zero contextual value. It doesn't explain what a log group is, what the tool returns, or any relevant operational context, making it 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% (both parameters have descriptions), so the baseline is 3. However, the parameter descriptions only state 'Overrides HUAWEI_REGION' and 'Overrides HUAWEI_PROJECT_ID', which are minimal. The tool description adds no further semantic context beyond the schema.
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 'Huawei Cloud LTS operation ListLogGroups' merely restates the tool name and provider, providing no information about what the operation actually does. It fails to specify that this tool lists log groups, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions, leaving the agent without any decision-making support.
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 for behavioral disclosure, but it discloses nothing—no mention of side effects, permissions, whether it's a write operation, or return behavior. The name hints at creation, but the description itself is devoid of 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified, not concise. The single sentence merely rephrases the title with generic words ('Huawei Cloud LTS operation') and provides no substantive content, so it fails to earn its place as useful documentation.
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 complex nested body schema, four parameters, and a large family of sibling tools, the description is severely incomplete. There is no output schema to compensate, and the tool description provides no information needed for correct invocation, especially considering AOM mapping rules are a niche Huawei Cloud concept.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention or explain any of the four parameters (body, region, is_batch, project_id) or the nested structure of body. With 50% schema description coverage, the tool description adds zero semantic value, leaving the agent to infer everything from parameter names alone.
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 essentially a tautology: 'Huawei Cloud LTS operation CreateAomMappingRules' restates the tool title without providing a verb or resource. It does not clarify what creating AOM mapping rules actually entails or distinguish it from sibling tools like UpdateAomMappingRules or ShowAomMappingRules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 is silent on context, prerequisites, exclusions, or relationships to other tools, offering no actionable direction for an 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, the description must carry the full burden of behavioral disclosure. It fails to mention whether this creates, modifies, or deletes resources, what side effects occur, or any permissions required. The name 'Create' implies a mutation, but no concrete behavior is described.
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 short but this is under-specification, not conciseness. It contains one vague sentence that repeats the tool name and offers no structured information, failing to earn its place.
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 complex nested schema, missing annotations, and lack of output schema, the description is woefully inadequate. It provides no context on the operation's purpose, parameter meaning, expected outcomes, or interaction with other LTS features.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters with only 2 described ('region' and 'project_id' as override hints), yielding 40% coverage. The description adds no parameter explanations whatsoever, leaving the complex 'body' parameter with nested fields completely unexplained.
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 reads 'Huawei Cloud LTS operation CreateLogStreamIndex.' This merely restates the tool's name without defining what the operation does. It does not specify the verb and resource beyond the title, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context or guidance is provided. The description does not indicate when to use this tool versus similar operations like UpdateLogStream or CreateLogStream, nor does it state prerequisites or intended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a destructive-sounding name, the description gives no insight into side effects, required permissions, reversibility, or what happens to associated data. The description carries the full burden for behavioral disclosure but says nothing, leaving the agent to guess.
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 short but under-specified. The single sentence does not earn its place because it adds no information beyond the tool name. It is concise but not usefully so, similar to the 'Process' calibration example.
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 of the input schema (nested objects, multiple parameters) and the absence of annotations and output schema, the description is grossly inadequate. It provides no operational context, expected outcomes, or usage examples, making it impossible for an agent to invoke the tool correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 50% description coverage (region and project_id have descriptions, body and domain_id do not). The tool description adds no parameter context whatsoever. The complex nested body object is undocumented, and the description does not help clarify what events or metadata should be provided.
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 merely restates the tool name ('Huawei Cloud LTS operation DeleteActiveAlarms') without explaining what the operation does. It lacks a specific verb+resource statement beyond the name itself, making it tautological rather than informative.
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. It does not mention related operations like ListActiveOrHistoryAlarms or other delete operations, nor does it state any prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits such as side effects, permissions, or reversibility. It discloses nothing beyond the operation name, leaving the agent completely uninformed about what executing this tool does in practice.
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 sentence, but brevity here results from under-specification rather than efficient structure. It contains no useful content beyond the title, making it too sparse to earn a passing score for conciseness.
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 5 parameters, no annotations, and no output schema, this description is wholly inadequate. It provides no context about the operation's purpose, effects, or return values, leaving the agent without enough information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, and the description provides no parameter information at all. The meaningful parameter names like consumer_group_name, group_id, and stream_id are left unexplained, and the description does not compensate for the schema's 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 "Huawei Cloud LTS operation DeleteConsumerGroup" only restates the tool name with the vague term 'operation' and provides no actual verb or resource detail. It doesn't explain that this tool deletes a consumer group, which is inferable from the name but not stated. It also fails to distinguish itself from sibling tools like CreateConsumerGroup or ListConsumerGroup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The description is purely nominal and offers no situational cues.
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 explaining behavior. It discloses no side effects, permissions, read-only nature, or other traits. The description adds nothing beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is very short, it is under-specified rather than concise. The single sentence merely restates the tool name and adds no useful content, so it does not earn its place.
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 4 parameters, no output schema, no annotations, and a closely related sibling ListDetailsConsumerGroup, this description is grossly incomplete. It does not explain what the operation does, what parameters mean, or how it differs from alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes region and project_id, but group_id and stream_id are completely undocumented. With 50% schema coverage and no parameter explanation in the description, the agent cannot infer the meaning or required format of these key 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 only repeats the operation name ('Huawei Cloud LTS operation ListConsumerGroup') without stating what it lists or what a consumer group is. It is a tautology that does not distinguish itself from sibling ListDetailsConsumerGroup or other list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 ListDetailsConsumerGroup, DeleteConsumerGroup, or CreateConsumerGroup. No context, prerequisites, 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 must disclose behavioral traits such as read-only vs. write, pagination, filtering, permissions, or response shape. It does none of this, leaving the agent with zero understanding of side effects or operational behavior.
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 short but this is under-specification, not conciseness. The single sentence contains no operational information and does not front-load any useful content for tool selection or invocation.
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?
With 4 parameters (one nested with 3 fields), no output schema, no annotations, and a large set of sibling tools, the description is grossly incomplete. It fails to explain the request/response shape or the tool's place in the Huawei Cloud LTS API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes generic override descriptions for region and project_id, but the tool description adds no parameter meaning. The body object's source, language, and templates fields are opaque, and with only 50% schema coverage the description should compensate but fails to do so.
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 is a tautology: 'Huawei Cloud LTS operation ListNotificationTemplate' restates the tool name and only adds the vendor/service context. It lacks a specific verb (e.g., list/get), does not describe what the tool returns, and cannot be distinguished from the sibling ListNotificationTemplates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 instead of alternatives like ListNotificationTemplates or ShowNotificationTemplate. No context, prerequisites, 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?
With no annotations, the description should disclose behavior but only repeats the name. No information about side effects, permissions, or data returned is given.
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 brief, it is under-specified and merely restates the tool name. The sentence does not earn its place because it adds no 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?
The tool has a complex schema with many parameters and no output schema, yet the description provides no context about its purpose, parameters, or expected results, making it inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 50% description coverage, with only region and project_id described. The description adds nothing about the body parameters (period, start_time, end_time, resource_id, search_type, resource_type) or timezone, failing to compensate.
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 'Huawei Cloud LTS operation ListTimeLineTrafficStatistics' merely restates the tool name without explaining what it does. It does not specify the action or resource in a way that distinguishes it from 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 about when to use this tool versus alternatives like ListTopnTrafficStatistics or ListLogHistogram. There is no mention of appropriate scenarios, prerequisites, or exclusions.
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. It does not mention whether the operation is a read-only listing, any authentication requirements, pagination behavior, or return format. The single-sentence description reveals nothing about the tool's behavior beyond its 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?
The description is extremely short, but this is under-specification rather than conciseness. A single sentence that only restates the name does not earn credit for brevity because every word is redundant with the title. It provides no useful structure or front-loaded 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?
This is a listing tool with five optional parameters, no output schema, and no annotations. The description provides almost no context, making it impossible for an agent to understand what data is returned, what filters are available, or how this fits into the broader LTS API. It is completely 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds zero information about the five parameters. Schema coverage is only 40%, leaving log_group_name, log_stream_name, and log_transfer_type completely undocumented in both schema and description. For tools with low schema coverage, the description must compensate, and it does not.
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 merely restates the tool name with a service prefix ('Huawei Cloud LTS operation ListTransfers'), providing no information about what the tool actually does. It fails to specify the verb+resource or distinguish it from related tools like ListLogStreams or ListTransferGroup. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 over alternatives. The description gives no context about typical scenarios, prerequisites, or relationships to sibling tools such as CreateTransfer, UpdateTransfer, or DeleteTransfer. The agent is left without decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides zero behavioral detail such as whether the operation is read-only, what permissions are required, or what side effects occur. The description carries the full burden of disclosure and fails entirely.
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 one sentence long, but it is tautological and provides no substantive information. This is under-specification rather than effective conciseness.
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?
With no output schema, no annotations, and a description that simply restates the operation name, the tool lacks essential context needed for correct invocation, such as what identifiers are required and what the response will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the four parameters. Schema coverage is only 50% and the description does not compensate for the undocumented group_id and stream_id parameters, providing no additional meaning beyond the 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 merely restates the tool name as 'Huawei Cloud LTS operation ShowLogStreamShards' and does not specify what the operation actually does (e.g., retrieving shard information for a log stream). It does not distinguish this tool from siblings that also relate to log streams and cursors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as ShowCursorByTime or ListLogStreams. No context, prerequisites, 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?
With no annotations, the description carries the full burden of behavioral disclosure. It provides none—no mention of read/write nature, side effects, required permissions, rate limits, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. It does not earn its place by conveying useful information; it merely names the tool and domain. This is under-specification, not conciseness.
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 there is no output schema, no annotations, and minimal parameter descriptions, the description should provide substantially more context. It fails to explain what the tool returns, what inputs are expected beyond basic schema, or how this tool fits into the broader API family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters. While the schema covers 'region' and 'project_id' with descriptions, 'member_account_id' is undocumented, and the description does not explain how or why to use these parameters in the context of this operation. Schema coverage is partial (67%), so the lack of parameter explanation is a notable gap.
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 restates the tool name ('ShowMemberGroupAndStream') and only adds the domain 'Huawei Cloud LTS operation'. It does not specify what the tool actually does, such as retrieving member group and stream details. This is essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 the many sibling tools. There is no mention of use cases, prerequisites, or exclusions.
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 discloses no behavioral traits such as read-only nature, return format, pagination, or error behavior. The word 'Show' implies retrieval, but the description itself adds nothing.
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 single sentence is short but tautological and under-specified. It does not earn its place as it provides no useful information beyond 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 4-parameter operation with no annotations, no output schema, and no usage context, this description is completely inadequate. The agent cannot determine what this tool does, how to invoke it properly, or what to expect in the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (region and project_id have descriptions, domain_id and template_name do not). The tool description adds no additional parameter meaning beyond the schema, failing to clarify the role of template_name or other parameters.
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 'Huawei Cloud LTS operation ShowNotificationTemplate.' merely restates the tool name and offers no verb or resource clarification. It fails to distinguish this from sibling tools like ListNotificationTemplate or CreateNotificationTemplate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not explain whether to use Show vs List, or mention any prerequisites or context for retrieving a notification template.
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. It reveals nothing about side effects, required permissions, reversibility, or response behavior. 'Update' implies mutation, but the description adds no tangible 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. For a tool with a complex nested body schema, a single sentence does not earn its place by providing 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 complexity of the nested body object, the lack of annotations, and the absence of an output schema, the description is completely inadequate. It neither explains the update semantics nor the structure of the request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with region and project_id described in the schema but body left undocumented. The tool description mentions no parameter meanings, defaults, or relationships, failing to compensate for the undocumented body 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 'Huawei Cloud LTS operation UpdateAomMappingRules' essentially restates the tool name with vendor context. It does not state what the tool does beyond the name, making it a tautology rather than a clear purpose statement.
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 the many sibling tools (CreateAomMappingRules, DeleteAomMappingRules, ShowAomMappingRules). No context, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It says only 'operation,' so there is no mention of side effects, permissions, idempotency, return values, or any other behavioral aspect. The agent cannot infer what updating a host group entails.
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 one-sentence description is severely under-specified, not concise. It repeats the tool name and provides no actionable content. This is the type of brevity that fails to inform rather than efficiently communicating essential details.
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 an update operation with three parameters (one a nested object), no annotations, and no output schema, this description is drastically inadequate. The agent has no idea what can be updated, required fields, request body format, or response expectations, making correct invocation unlikely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters. Although the schema describes region and project_id (67% coverage), the critical 'body' parameter with its nested properties is completely undocumented. The description could have clarified the body structure or update semantics, but it does not.
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 'Huawei Cloud LTS operation UpdateHostGroup' merely restates the tool name with the generic label 'operation'. It does not specify what the update does (e.g., modify host group name, tags, or members) and does not distinguish it from sibling tools like CreateHostGroup or DeleteHostGroup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool vs alternatives. The sibling list includes CreateHostGroup, DeleteHostGroup, and ListHostGroup, but the description offers no context, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavioral traits, yet it says nothing about update semantics, side effects, permissions, or response behavior. This is a complete absence of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but it is under-specified rather than concise. It lacks substantive content and fails to earn its place in the definition.
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 a nested body object, four parameters, no output schema, and no annotations, this description is severely incomplete. It leaves the agent without any useful context for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about parameters. Schema coverage is only 50% (region and project_id have basic 'Overrides...' descriptions), while body.tags and body.ttl_in_days are completely undocumented, leaving their meaning and usage ambiguous. The overall description does not compensate in any way.
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 'Huawei Cloud LTS operation UpdateLogGroup.' merely restates the tool name with a service prefix, adding no functional meaning. It is tautological and does not distinguish from sibling tools like CreateLogGroup or UpdateLogStream.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as CreateLogGroup or UpdateLogStream. No prerequisites, use cases, or contextual triggers 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, the description carries the full burden of behavioral disclosure, yet it provides none. There is no mention of side effects, permissions, idempotency, return values, or any operational behavior beyond the empty phrase 'operation'.
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 short, but it is under-specified rather than concise. The single sentence repeats the tool name and adds no useful information, so it does not earn its place. Structure is front-loaded with generic phrasing, but content is empty.
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 of the tool with a nested body schema and no output schema, the description is wholly inadequate. It does not explain what the tool does, what the body parameters mean, what the response format is, or any dependencies. This is a complex API operation reduced to a label.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds zero information about parameters. Input schemas have 4 parameters, one of which is a complex nested object ('body'), yet the description does not explain any of them. Schema descriptions cover only region and project_id, leaving body and domain_id undocumented; the description fails to compensate for these 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 is essentially a tautology: 'Huawei Cloud LTS operation UpdateNotificationTemplate.' It restates the tool name with no additional verb or resource clarification. While the name itself suggests an update operation, the description fails to specify what a notification template is or what updating entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool versus siblings like CreateNotificationTemplate, ShowNotificationTemplate, or DeleteNotificationTemplate. The description neither gives context nor exclusions.
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, and the description gives no behavioral details such as side effects, permissions required, or what the operation modifies. The description carries the full burden for transparency and fails to disclose anything 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?
The description is extremely short, but this is under-specification rather than effective conciseness. A single sentence that merely repeats the tool name offers no structural value and fails to earn its place as a meaningful 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?
Given the complexity of the input schema (nested arrays with 14 fields), the absence of annotations and output schema, and the lack of any behavioral or usage information, the description is completely inadequate for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents region and project_id with brief override descriptions, but the body parameter is an undocumented nested object with many fields. The description adds no parameter meaning whatsoever, leaving the semantics of the most complex parameter entirely unclear.
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 merely restates the tool name as 'Huawei Cloud LTS operation CreateAgencyAccess' without defining what the operation actually does. It provides no verb+resource clarity beyond the name itself, making it a tautology rather than an informative purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no context about prerequisites, and no mention of alternative tools for similar operations. The description offers no practical 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. It only says 'operation' and gives no information about side effects, permissions, resource creation, or any impact on LTS configuration. The name implies creation, but the description itself adds no 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 a single sentence but is under-specified rather than concise. It contains no useful information beyond the tool name and product domain, so the brevity is not serving a purpose.
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 create operation with a nested body schema, no output schema, and no annotations. The description fails to provide essential context such as what the tool creates, required fields, or any operational effects, making it inadequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter explanations. The schema has 3 top-level parameters, with only region and project_id having descriptions ('Overrides HUAWEI_REGION' / 'Overrides HUAWEI_PROJECT_ID'). The body parameter and its nested properties like host_group_name and host_group_type are completely unexplained, and the description does not compensate for this gap.
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 'Huawei Cloud LTS operation CreateHostGroup' merely restates the tool name and provides only a vague domain context. It does not state what creating a host group does, what a host group is, or how it differs from sibling tools like UpdateHostGroup or ListHostGroup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. Sibling tools such as DeleteHostGroup, UpdateHostGroup, and ListHostGroup exist, but the description does not mention them or provide any decision 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, the description carries the full burden of disclosing behavioral traits, but it provides none. It does not mention creation semantics, required permissions, side effects, or what happens after a successful call.
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 one-sentence description is under-specified rather than concise. It simply repeats the tool name without adding any useful content, so it does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested input schema and no output schema or annotations. This description is completely insufficient for an agent to understand the operation's purpose, parameter requirements, or expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about parameters. The main 'body' parameter is a complex nested object with many undocumented fields, and the schema coverage is only 67% (only 'region' and 'project_id' have descriptions). The description does not compensate for the undocumented body fields.
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 'Huawei Cloud LTS operation CreateKeywordsAlarmRule' merely restates the tool name with a cloud provider prefix. It does not explain what creating a keywords alarm rule entails or distinguish it from similar tools like CreateSqlAlarmRule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 CreateSqlAlarmRule or UpdateKeywordsAlarmRule. There is no mention of prerequisites, typical scenarios, or when this operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it reveals nothing about side effects, permissions, prerequisites, or what happens when the rule is created. The description is completely opaque about runtime behavior.
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. While it is short, it violates the principle that every sentence should earn its place; this single phrase adds no value beyond the tool name. True conciseness includes informativeness, not just brevity.
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 complex tool with a large nested schema, no annotations, and no output schema. The description provides almost no operational context, leaving the agent without essential information about the purpose, behavior, or parameters of the tool. It is wholly inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the input schema. The schema has complex nested objects (e.g., body.sql_requests, body.frequency) with no property descriptions, and the tool description fails to clarify their purpose or relationships. With 67% schema description coverage but a large undocumented body, the description does nothing to compensate.
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 'Huawei Cloud LTS operation CreateSqlAlarmRule' merely restates the tool name with a generic cloud prefix. It provides no substantive explanation of what creating a SQL alarm rule entails, nor does it distinguish the tool from siblings like CreateKeywordsAlarmRule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 zero guidance on when to use this tool versus alternatives. No context is given about the intended use case, prerequisites, or scenarios where CreateSqlAlarmRule should be preferred over other rule-creation 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it discloses nothing. The term 'operation' is vague and does not state that this is a mutating/create action, nor mention side effects, idempotency, required permissions, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is short, but this is under-specification rather than conciseness. The sentence 'Huawei Cloud LTS operation CreateStructTemplate' provides no substantive information and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested body schema, no required parameters, no annotations, and no output schema. The description is far too minimal to help an agent understand how to invoke the API correctly, what parameters to populate, or what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level meaning. The schema describes only the two override parameters (region, project_id), leaving the nested 'body' object and all its fields undocumented. At 67% schema coverage with a complex nested structure, the description should compensate but does not.
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 essentially a tautology: 'Huawei Cloud LTS operation CreateStructTemplate' restates the tool name without explaining what 'CreateStructTemplate' actually does. It conveys only the cloud provider and service domain, not the specific action or resource affected, and does not differentiate it from siblings like CreateStructConfig or UpdateStructTemplate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. Sibling tools include CreateStructConfig, UpdateStructTemplate, ListStructTemplate, and DeleteStructTemplate, but the description offers no context to choose among them or to indicate prerequisites.
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. However, it says nothing about the destructive nature of the operation, whether the deletion is permanent, requires special permissions, or has any side effects. The tool name implies deletion, but the description itself offers zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than concise clarity. It contains no useful information beyond the tool name, so while there is no verbosity, the single sentence fails to communicate anything substantive.
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 delete operation with no annotations and no output schema, the description should state the affected resource, required identifiers, and likely consequences. It provides none of this, leaving the agent with insufficient context to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documentation covers 67% of parameters (region and project_id as overrides), but the 'id' parameter is undocumented. The description does not clarify what 'id' refers to (e.g., the mapping rule ID), nor does it explain how the parameters relate to the deletion. The description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Huawei Cloud LTS operation DeleteAomMappingRules,' which essentially restates the tool name without explaining what the operation does. It uses the tool name as both subject and action, making it a tautology rather than a clear purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 compared to siblings like CreateAomMappingRules, UpdateAomMappingRules, or ShowAomMappingRules. It does not state that this is the deletion tool for AOM mapping rules or mention any prerequisites.
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 disclosing behavioral traits. It only says 'operation', offering no information about side effects, required permissions, or whether the action is irreversible. The name implies deletion, but the description itself is empty.
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 single sentence is highly concise but this is under-specification, not effective conciseness. It uses the space to restate the name rather than convey any useful information, so the structure does not serve a purpose.
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 delete operation with three optional parameters and no output schema, the description should explain what resource gets deleted, the meaning of fav_res_id, and any irreversible effects. It provides none of this, leaving the tool completely under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters. The schema already describes region and project_id as overrides, but the purpose of fav_res_id remains completely unexplained. Since schema coverage is only 67% and the description provides zero parameter insight, it fails to compensate for the gap.
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 'Huawei Cloud LTS operation Deletefavorite' merely restates the tool name and labels it as an operation. It does not explain what a 'favorite' is, what deletion does, or how it differs from sibling tools like DeleteAccessConfig or Createfavorite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 any alternative. The description gives no context about the favorite lifecycle, prerequisites, or when deletion would be appropriate. Sibling tools are not referenced.
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. It fails to mention the destructive nature of the operation, whether it permanently removes host groups, whether multiple IDs can be deleted at once, or any side effects. The description adds no 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 the description is short, it is under-specified, not concise. The single phrase 'Huawei Cloud LTS operation DeleteHostGroup' provides no useful detail and could be considered a mere label. It does not earn its place with actionable 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 (nested body, multiple delete operations among siblings, no output schema, no annotations), the description is completely inadequate. It fails to clarify what a host group is, what host_group_id_list represents, whether deletion is permanent, or how this differs from UpdateHostGroup or ListHostGroup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with region and project_id having descriptions, but the critical body parameter (host_group_id_list) has no schema description. The tool description does not explain what body contains or how to use it, leaving the agent without understanding the core payload.
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 'Huawei Cloud LTS operation DeleteHostGroup.' merely restates the tool name as an operation. It does not explicitly state that the tool deletes a host group or what a host group is. This is a tautology rather than a clear purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 UpdateHostGroup, ListHostGroup, or other delete tools. The description offers no contextual cues or prerequisites, so 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. It does not confirm that the tool deletes a resource, nor does it mention any side effects, irreversibility, permission requirements, or idempotency behavior. The description is even less informative than the update_drive example, which at least stated 'Update shared drive settings.' Here, the description merely names the operation without any behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A concise description would use a clear verb and state the action, such as 'Deletes a keywords alarm rule in Huawei Cloud LTS.' Instead, it provides a fragment that restates the name, offering no structure or meaningful content.
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 delete operation with three parameters and no output schema, the description is completely inadequate. It does not explain the effect of deletion, whether it is reversible, what happens on success/failure, or how the keywords_alarm_rule_id is used. The description lacks essential context needed to safely invoke the tool, especially given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 67%, meaning region and project_id are partially documented, but keywords_alarm_rule_id has no description. The tool description adds nothing about any parameter, failing to compensate for the undocumented parameter. It does not explain what the parameters mean, how they relate, or provide any additional context beyond the schema. The description offers zero semantic value for 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 is essentially a restatement of the tool name: 'Huawei Cloud LTS operation DeleteKeywordsAlarmRule.' It does not use a specific verb like 'deletes' or provide any functional explanation beyond what the name already conveys. It identifies the service context but fails to clearly state the tool's action, making it tautological rather than informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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, scenarios for deleting a keywords alarm rule, or differentiate it from sibling operations like UpdateKeywordsAlarmRule or DeleteSqlAlarmRule. There is no implied usage context beyond the name 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that the operation is destructive, whether it is reversible, what side effects occur (e.g., data loss), or what authentication is required. This is a complete absence of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, it is under-specified to the point of being tautological. The single sentence adds no information beyond the tool name, so it does not 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?
For a delete operation with four parameters and no annotations or output schema, the description is drastically incomplete. It omits prerequisites, effects, error behavior, and parameter relationships, leaving the agent without the information needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for 'region' and 'project_id' but leaves 'log_group_id' and 'log_stream_id' undocumented. The description adds no additional meaning about these parameters, such as the hierarchical relationship between log groups and streams, or any constraints on their values.
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 'Huawei Cloud LTS operation DeleteLogStream' is a tautology that restates the tool name without specifying what the operation does (e.g., 'Deletes a log stream'). It does not distinguish this tool from sibling delete operations like DeleteLogGroup or DeleteTransfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 context is provided about when to use this tool versus alternatives, no prerequisites are mentioned, and there is no guidance on required parameters or typical scenarios. The description is entirely silent on usage.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does not mention that deletion is irreversible, what permissions are required, or any side effects, leaving the agent with only the name to infer behavior.
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 sentence, but it is under-specified rather than concise. It conveys no useful details about the operation, its parameters, or its 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?
This is a delete operation with no annotations, no output schema, and an unexplained key parameter (sql_alarm_rule_id). The description gives no information about expected inputs, return values, or operational impact, making it wholly inadequate for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond the input schema. Schema coverage is 67%, and the only meaningful descriptions ('Overrides HUAWEI_REGION' and 'Overrides HUAWEI_PROJECT_ID') come from the schema, not the tool description. The sql_alarm_rule_id parameter remains unexplained.
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 'Huawei Cloud LTS operation DeleteSqlAlarmRule' merely restates the tool name with a product prefix. It does not explicitly state that the tool deletes a SQL alarm rule, so it reads as a tautology rather than a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like UpdateSqlAlarmRule or DeleteKeywordsAlarmRule. The description offers no context or exclusions.
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 behavioral details are provided. The description does not disclose that this is a destructive operation, what happens to the transfer, or any error conditions. With no annotations, this is a serious 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 short, the description is under-specified. It adds no informative content beyond the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool requires a log_transfer_id and performs a delete action, but the description gives no context on how to use it, what it returns, or safety considerations. It is incomplete even for a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters. The schema documents 'region' and 'project_id' but not 'log_transfer_id', and the description offers no additional meaning.
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 simply states 'Huawei Cloud LTS operation DeleteTransfer', which restates the tool name without indicating what resource it acts on or what action it performs. It does not differentiate from sibling delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use DeleteTransfer versus other transfer management tools. The description lacks context about prerequisites or use cases.
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, the description is solely responsible for disclosing behavior, but it says nothing about whether this is a safe read-only operation, whether it supports pagination, or what filters it supports. It only states the operation name, leaving the agent without 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, technically concise, but it is under-specified rather than efficiently informative. The sentence 'Huawei Cloud LTS operation ListAccessConfig' does not earn its place because it only repeats 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?
Given the nested body schema, no output schema, and no annotations, this description is far from complete. An agent cannot determine what the tool returns, how to structure the body, or how it relates to other access-config operations. This is a bare-minimum placeholder.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters, and while the schema provides descriptions for region and project_id, the body object and its nested filters remain undescribed. With 67% schema coverage, the description should have compensated but adds no parameter-level meaning.
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 'Huawei Cloud LTS operation ListAccessConfig' merely restates the tool name with vendor context. It does not specify that the tool lists access configurations, nor does it distinguish from siblings like CreateAccessConfig, UpdateAccessConfig, or other List* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools. The description lacks any context about use cases, prerequisites, or alternatives.
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, the description carries full responsibility for disclosing side effects, safety, or permission requirements. It provides none—no indication of mutability, destructive potential, idempotency, or required authorization—making it completely opaque for an update operation.
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 short but under-specified. It is a single vacuous sentence that provides no meaningful information, which is not genuine conciseness but rather a lack of substance. It does not front-load any useful 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?
The tool has a highly complex schema with nested objects and no output schema. The description is completely inadequate, failing to explain what an access config is, what the update operation does, or what the expected result is. This is grossly insufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds zero meaning to the input schema. The key 'body' parameter is a large nested object with no description, while region/project_id have descriptions in the schema. The tool description does not clarify what the body should contain or how parameters relate to the update, so it fails to compensate for the 33% schema coverage gap.
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 merely restates the tool name ('UpdateAccessConfig') with a generic 'Huawei Cloud LTS operation' prefix. It doesn't specify what an AccessConfig is or what updating does, making it a tautology without distinguishing from sibling tools like CreateAccessConfig or DeleteAccessConfig.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives. There is no mention of prerequisites, when update is appropriate, or exclusions, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits. It does not state whether this is a mutating operation, what effects it has on an existing alarm rule, or any permissions required. The name implies update, but the description itself is vacuous.
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 short sentence, but it under-specifies rather than being concise. It adds no information beyond the tool's title, making it ineffective.
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 tool has a complex nested schema with 3 parameters and no output schema, yet the description is practically empty. It fails to provide enough context for an agent to understand what the operation does, what inputs are needed, or what to expect in response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains zero parameter information. It does not explain the 'body' object's fields, the purpose of region/project_id overrides, or any defaults. Schema coverage is 67%, but the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Huawei Cloud LTS operation UpdateSqlAlarmRule' simply restates the tool title with a cloud service identifier. It does not explain what updating a SQL alarm rule entails, nor does it distinguish from sibling tools like CreateSqlAlarmRule or UpdateKeywordsAlarmRule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparisons with sibling operations such as CreateSqlAlarmRule or DeleteSqlAlarmRule.
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 does not mention side effects (e.g., creating or modifying resources), required permissions, or any other behavioral traits. The phrase 'operation' adds nothing about what actually happens, leaving the agent unaware of the tool's mutating nature.
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 short sentence, but this is under-specification rather than concise clarity. Every word merely restates the name and service context, contributing no useful information. While it is front-loaded, it does not earn its place as a functional 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?
The tool has 5 parameters, a nested object, and no output schema, making it moderately complex. Yet the description offers no information about input requirements, return values, or operational context. It is completely inadequate for guiding an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description offers no parameter explanations beyond the shorthand 'Overrides HUAWEI_REGION' etc. The nested 'body' object, 'resource_id', and 'resource_type' are left undocumented. The description adds no meaning to the parameters, failing to compensate for the low schema coverage.
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 'Huawei Cloud LTS operation CreateTags' essentially restates the tool name and title. It provides minimal context (the cloud service) but fails to specify what the operation actually does, such as which resource tags are created on or how tags are applied. This is close to a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use CreateTags versus the many similar sibling tools (e.g., CreateLogGroup, CreateLogStream, CreateAccessConfig). There are no stated use cases, prerequisites, or alternative suggestions. The description leaves the agent without any direction on tool 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?
With no annotations, the description carries the full burden of disclosing behavioral traits such as read-only nature, return values, side effects, or authentication requirements. It provides none of these. The word 'List' in the name hints at read-only, but the description itself adds no behavioral information 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?
The description is one short sentence, but it is under-specified rather than concise. It repeats the tool name and adds no actionable information. It does not earn its place because it conveys almost nothing useful to the agent.
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?
There is no output schema, no annotations, and only two simple optional parameters. The description completely fails to explain what the tool returns, how it behaves, or how it differs from the many similar list/show tools in the sibling list. This is a serious gap for a tool with no other contextual 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 has 100% coverage for both parameters (region and project_id), each described as overriding an environment variable. Since the schema already documents these parameters fully, the description is not required to add more. The baseline of 3 is appropriate; no extra semantics are needed.
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 merely restates the operation name: 'Huawei Cloud LTS operation ListBreifStructTemplate.' It gives no information about what the tool actually does—whether it lists templates, retrieves details, or performs some other action. The generic 'Huawei Cloud LTS operation' does not distinguish it from siblings like ListStructTemplate or ShowStructTemplate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. Given the many sibling tools with similar names, the lack of any guidance leaves the agent uncertain about 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, and the description offers no behavioral details such as whether the operation is read-only, requires auth, or returns a specific result. The description carries no burden of transparency at all.
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 single sentence is short, but it is under-specified rather than concise since it does not earn its place by adding information beyond the tool name. It is not structured or front-loaded with useful content.
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?
With no annotations, no output schema, and a tautological description, the tool is functionally opaque. Even though it has only two optional parameters, an agent cannot determine what ShowAdminConfig does or returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents both parameters with 'Overrides HUAWEI_REGION' and 'Overrides HUAWEI_PROJECT_ID', so the schema covers 100% of parameter meaning. The description adds no parameter information, but the baseline for high schema coverage is 3.
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 merely restates the tool name ('Huawei Cloud LTS operation ShowAdminConfig') without specifying what the operation does. It provides no verb or resource beyond the name itself, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use ShowAdminConfig vs any of the many sibling tools. The description is strictly a domain label and provides no context or exclusions.
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 for behavioral disclosure. It mentions no behavior at all—whether the operation is a read-only list, what it returns, or if any side effects occur. It adds zero value 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?
The description is short but not meaningfully concise—it wastes the only sentence on a restatement of the name. Under-specification is not conciseness; the sentence does not earn its place.
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 absence of annotations, no output schema, and a sibling tool with a similar name, the description is wholly inadequate. It fails to explain what the operation does, what it returns, or how it relates to other mapping rule tools, leaving an agent with no basis for correct selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters ('Overrides HUAWEI_REGION' and 'Overrides HUAWEI_PROJECT_ID'), yielding 100% coverage. The tool description adds no additional parameter context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Huawei Cloud LTS operation ShowAomMappingRules' is a tautology—it simply restates the tool name with a service qualifier. It does not explain what AOM mapping rules are, what 'Show' does (list vs. get), or how it differs from sibling ShowAomMappingRule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like CreateAomMappingRules or ShowAomMappingRule. The description lacks any contextual cues about use cases, prerequisites, or distinctions.
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, and the description adds no behavioral disclosure. It does not indicate that this is a read-only list operation, nor any side effects, permissions, or response characteristics. The name hints 'List', but the description itself discloses nothing.
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 very short (one sentence) but under-specified. It front-loads the name and domain but provides no real content, so it is not effective conciseness—rather, it lacks substance that would earn 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 simple list tool with no output schema and no annotations, the description should at least state that it lists SQL alarm rules and possibly the region/project context. It does neither, leaving the tool's purpose and behavior mostly undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (region and project_id) with clear override semantics, so schema coverage is 100%. The description adds no parameter information, but per the baseline rule, a score of 3 is appropriate when the schema carries the load.
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 restates the tool name as 'operation ListSqlAlarmRules' without specifying any verb or resource. It offers only the context 'Huawei Cloud LTS', but fails to say it lists SQL alarm rules, making it nearly tautological and indistinguishable from sibling tools like ListKeywordsAlarmRules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 or how it differs from alternatives. No context is given for typical use cases, prerequisites, or exclusions, leaving the agent without any basis to prefer it over 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 must disclose behavioral traits. It only states the operation name and does not describe the destructive nature, any side effects, required permissions, or what happens to associated data. This is a significant gap for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it is concise and front-loaded. However, it is under-specified and mostly restates the tool name with minimal added context, so it doesn't make efficient use of the space to convey useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested object parameter, no annotations, and no output schema. The description is too sparse to be complete. It doesn't explain what the deletion does, how to identify the target, or any constraints, leaving the agent without sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter semantics. The schema covers 'region' and 'project_id' with descriptions, but the main parameter 'body.id' is undocumented. With schema coverage at 67% but the key parameter lacking explanation, the description fails to add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as 'Huawei Cloud LTS operation DeleteStructTemplate', which implies deleting a struct template. The verb 'Delete' and resource 'StructTemplate' are present, making the purpose clear. However, it offers no additional details about the scope or effect, and it doesn't explicitly distinguish it from similar delete operations on other resources, though the resource name does that implicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or situations where a different tool like CreateStructTemplate or UpdateStructTemplate should be used. Sibling tools exist but are not referenced.
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

Copy to your README.md:

[![huawei-lts-skill MCP server](https://glama.ai/mcp/servers/jkrandom-sudo/huawei-lts-skill/badges/card.svg)](https://glama.ai/mcp/servers/jkrandom-sudo/huawei-lts-skill)

Score Badge

Copy to your README.md:

[![huawei-lts-skill MCP server](https://glama.ai/mcp/servers/jkrandom-sudo/huawei-lts-skill/badges/score.svg)](https://glama.ai/mcp/servers/jkrandom-sudo/huawei-lts-skill)

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/jkrandom-sudo/huawei-lts-skill'

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