dws-cli-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes across domains like chat, calendar, todo, docs, and attendance. A few overlap (e.g., contact_user_search vs. aisearch_person), but descriptions help differentiate them.
Naming Consistency5/5
All tools follow a consistent dingtalk_<domain>_<entity>_<action> pattern, e.g., dingtalk_calendar_event_create, dingtalk_doc_read. Even edge cases like dingtalk_schema_discover fit the pattern, making it predictable.
Tool Count1/5
With 83 tools, this far exceeds the 50+ threshold for an extreme mismatch. The server attempts to cover nearly every DingTalk API, but the sheer number overwhelms the MCP surface and makes it hard to navigate.
Completeness3/5
The tool surface covers many DingTalk domains (chat, calendar, todo, approvals, docs, drive, minutes, mail, sheets, wiki) with CRUD for several. However, gaps exist, such as no document deletion, no mail reading, and limited report detail operations.
Average 3.3/5 across 83 of 83 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It merely states the action with no mention of permissions, side effects, idempotency, return value, or what happens to the created group. This fails to inform the agent about the tool's behavior beyond the literal 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 does not earn its place as it restates the tool name. While concise, it lacks substantive content, making it under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with two documented parameters and no output schema, the description is insufficient. It does not clarify what the tool returns (e.g., group ID), what constitutes valid users, or any post-creation effects, leaving the agent without critical context for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters (name and users) documented in the schema. The description adds no additional parameter semantics, but the baseline is 3 given high 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 '创建群聊' is a direct translation of the tool name 'dingtalk_chat_group_create', making it tautological. It confirms the action but does not add any distinguishing detail relative to sibling chat 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 usage guidance is provided. The description does not state when to use this tool versus alternatives like dingtalk_chat_group_members_add or dingtalk_chat_send_message, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. '发送邮件' only states the action, offering no details about authentication requirements, sender identity, error handling, or side effects. This is essentially no behavioral transparency beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse at only two Chinese characters, which is under-specification rather than efficient conciseness. There is no front-loaded useful content beyond the basic action, making it minimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a send operation with no output schema and no annotations, the description is insufficient. It does not explain what the tool returns (e.g., message ID), how it handles failures, or any important side effects, leaving a critical context gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage with descriptions for all four parameters (to, cc, subject, body). The description adds no parameter information, so the baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '发送邮件' clearly states the action (send) and resource (email), distinguishing it from sibling tools like dingtalk_mail_message_list (list emails). However, it lacks any additional scope or nuance, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like dingtalk_chat_send_message or dingtalk_ding_message_send. There is no context, exclusions, or mention of scenarios where email sending is preferred.
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 alone is responsible for disclosing behavioral traits. It only says 'create new calendar event' with no mention of side effects, permissions, idempotency, or return behavior. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise, but it is also under-specified. It lacks front-loaded details that would help the agent understand usage, so it is not as effective as it could be while still being brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and any extra context, the description does not fully explain the tool's behavior. It covers the basic action but omits critical details like date/time format specifics, default values, error conditions, or call outcomes, making it incomplete for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all five parameters described (title, start/end times, attendees, description). The description adds no additional parameter meaning, so the baseline of 3 is appropriate since the schema already handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建新日程' clearly states the action (create) and resource (calendar event), which distinguishes it from sibling tools like update, delete, get, and list. It lacks additional scope details but is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or comparisons with related calendar tools such as dingtalk_calendar_event_update or dingtalk_calendar_event_suggest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the search dimensions and does not mention whether the operation is read-only, requires special permissions, has rate limits, or what the response format is. While 'search' implies a read operation, the description lacks explicit context about side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise parenthetical phrase, listing dimensions without fluff. It is front-loaded with the core purpose ('企业人员多维搜索') and immediately enumerates the relevant attributes. However, it is a fragment rather than a complete sentence, which slightly reduces accessibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the informative query schema, the description is mostly adequate for a basic search tool. However, it lacks usage guidance and any indication of expected output structure, and with no annotations, the agent has to infer safety and side effects. The description is not as minimal as a pure tautology but leaves clear gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter 'query' with a clear description and an example (自然语言描述，如：技术部负责前端的同事). The tool description adds the list of searchable fields, which provides context for what kinds of queries are valid, but the schema already does the heavy lifting. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a search tool for enterprise personnel across multiple dimensions (name, department, position, responsibility, superior/subordinate, phone, employee ID). The verb is implicit in '搜索' (search), and the resource is '企业人员' (enterprise personnel). However, it does not explicitly differentiate itself from sibling tools like dingtalk_contact_user_search or dingtalk_contact_user_search_mobile, though '多维' (multi-dimensional) hints at a broader semantic search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 the many contact-related siblings (e.g., dingtalk_contact_user_search, dingtalk_contact_user_search_mobile, dingtalk_contact_dept_search). There is no mention of alternatives, prerequisites, or specific scenarios where an AI-powered multi-dimensional search would be preferred over more targeted tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior on its own; it only says 'search by name keyword' without explaining matching semantics, result format, pagination, or scope. This is insufficient for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler; it efficiently states the core action. However, it is so terse that it omits useful behavioral context, making it concise but not fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should describe what the search returns and any important limitations; it only provides the search criterion. The tool is related to several AITable siblings, but the description does not specify result scope or distinguish search/listing behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter 'keyword' is described as 'Base 名称关键词' (Base name keyword), which largely mirrors the tool description's '按名称关键词'. The description adds no additional examples, syntax, or matching behavior beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb '搜索' (search) with the resource 'AI 表格' and the scope '按名称关键词' (by name keyword), clearly identifying the tool's operation. It distinguishes from sibling base_list by adding the search-by-keyword criterion, though 'AI 表格' is slightly ambiguous and could be confused with tables vs bases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides no guidance on when to use this tool instead of alternatives like dingtalk_aitable_base_list or when a keyword is required; it only states the basic operation. No exclusions or alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits on its own. The verb '查询' implies a read-only operation, but the description does not disclose what the response contains (e.g., whether both busy and free slots are returned), time format requirements, or any permissions needed. This is a minimal reliance on the verb rather than explicit disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundancy, front-loading the core purpose. However, it is so minimal that it skips valuable context, which reduces the score slightly from a perfect 5. It is appropriately size-efficient for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must carry full context. It does not explain the meaning of '忙闲时间段' (busy/free time slots), output structure, time parameter format, or any usage constraints. For a tool that queries multiple users' availability, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters have descriptions in the schema, providing baseline meaning. The tool description itself adds no additional parameter semantics beyond what the schema already states, and the schema descriptions themselves are basic (e.g., '查询起始时间' for start_time) without format details. Thus, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '查询' (query) and identifies the resource as '一组用户的忙闲时间段' (busy/free time slots for a group of users), which clearly indicates a query operation. However, it does not explicitly differentiate from sibling calendar tools like dingtalk_calendar_event_list or dingtalk_calendar_event_suggest, which may also involve calendar availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 guidelines are provided. The description does not mention when to use this tool over alternatives, such as when you need to check availability across multiple users versus listing individual events. There are no stated 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, and the description only states 'delete schedule' without disclosing side effects, permanence, permissions, or error behavior. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single verb-noun phrase with no redundant language. It is appropriately sized for a simple delete operation, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and behavioral details, the description is incomplete for a delete operation. The agent has only the action and a parameter, with no information about return values, error handling, or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter event_id with description '日程 ID' (100% coverage). The tool description adds no additional semantic information about the parameter, such as how to obtain it or any constraints, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除日程' clearly specifies the action (delete) and the resource (calendar event). It is distinct from sibling tools like dingtalk_calendar_event_create/get/update/list, which have different verbs and resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 or alternatives. It does not mention prerequisites, such as whether the user must be the event owner, or when deleting is preferable to updating or canceling an event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it provides none. It does not mention whether results are paginated, what permission is required, whether it is strictly read-only, or any side effects. This is a minimal list operation, but the lack of any behavioral context is a clear gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and easy to parse. However, it omits potentially useful context, so it is efficient but not maximally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list operation with one well-described parameter, so the minimal description is arguably sufficient. However, the lack of output schema and any details about return format or pagination means it is only minimally complete, especially given the risk of confusion with similar listing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'id', which is described as the group's openConversationId. The tool description adds no additional parameter semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出群成员' clearly states the action (list) and resource (group members), which is specific and unambiguous. It aligns well with the tool name and distinguishes from siblings like dingtalk_contact_dept_list_members, though it does not explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or contrast with similar list operations such as dingtalk_contact_dept_list_members. The description is purely a statement of function without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses only the action, not behavioral nuances such as whether the member list is replaced or appended, how duplicates are handled, or whether specific permissions are required. This lack of transparency is a gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short phrase with zero filler or repetition. It is efficiently sized for the simple operation, though it lacks any elaboration that might be helpful for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 required params, no output schema), the minimal description is arguably sufficient. However, it omits any context about expected outcomes or edge cases, such as invalid user IDs or partial failures, making it only marginally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (100% coverage), so the description adds no additional meaning beyond what the schema already provides. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '向群聊添加成员' clearly states the action (add) and resource (group chat members). It is specific and unambiguous, though it does not explicitly contrast with sibling tools like dingtalk_chat_group_create or dingtalk_chat_group_members, the verb 'add' inherently distinguishes it from creating or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It simply states the action without context, leaving the agent to infer usage from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the basic action and does not mention that start/end are required, the search scope, potential limitations, or return format. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero redundancy. Every word contributes to stating the tool's purpose, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the one-sentence description is insufficient. It fails to explain that start/end are required, what the search spans (all chats vs. a specific group), or what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 5 parameters, including required start/end and optional group_id. The description adds no new meaning beyond the query keyword, which corresponds directly to the query parameter, so it adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches message records by keyword, which is a specific verb and resource. It distinguishes from sibling listing tools like dingtalk_chat_message_list by focusing on search, though it omits the time-range scoping that is a core feature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 dingtalk_chat_message_list, list_all, or list_mentions. The description does not mention appropriate use cases 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden. It only says 'search' and gives no information about result format, pagination, permissions, rate limits, or side effects. For a search operation, basic expectations like returning a list of group chats with IDs are not stated, leaving the agent 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and object. It is efficient and avoids redundancy, but it omits important contextual details that would make it more useful. It is not overly verbose, scoring well on conciseness despite lacking completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and no output schema, so the description should compensate by explaining what the search returns (e.g., group names, IDs, member counts). It does not mention return value structure or any limitations. Given the simplicity, a moderate score of 2 is warranted because basic expectations are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description for the single 'query' parameter ('群名称关键词（必填）'), achieving 100% coverage. The tool description repeats the keyword concept but does not add extra detail about format, length limits, or search behavior beyond what the schema documents. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: search group chats by keyword. It clearly targets the resource (group chats) and the operation (search). However, the phrase '用户所在的群聊' could be misread as searching by user rather than by group name, though the parameter description clarifies it is by group name. It does distinguish from sibling search tools like message search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or contrast with related tools such as dingtalk_chat_message_search or dingtalk_chat_group_create. The description is purely declarative 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full transparency burden. It only states 'search developer documentation' and does not disclose return format, pagination, authentication needs, or any side effects. This is insufficient for an agent to anticipate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant words. It is efficiently written and easy to process, though it is minimal. The structure is acceptable for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, no output schema, and no annotations, the description is too sparse. It does not explain what kind of search results to expect (e.g., article titles, links, snippets) or any limitations. An agent would lack critical context for using the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the sole parameter 'keyword' with '搜索关键词', giving 100% coverage. The description adds no extra semantic detail beyond this, so the baseline of 3 is appropriate. The description does not introduce any ambiguity but also does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '搜索钉钉开放平台开发者文档' clearly identifies the action (search) and resource (DingTalk Open Platform developer documentation). It distinguishes from sibling tools like dingtalk_doc_search (likely for general docs) and dingtalk_wiki_space_search, though it does not explicitly mention 'articles' as the target. Slight ambiguity remains but purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as dingtalk_doc_search or dingtalk_devdoc_error_diagnose. There is no mention of scenarios, exclusions, or comparative context, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. However, it only restates the basic action (search by keyword) without adding context about search scope, return format, pagination, or limitations. This is insufficient for a tool that likely needs to handle result interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. There is no redundant information or padding, and the key verb 'search' appears upfront. It is an efficient and well-structured one-liner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description needs to explain what the tool returns or how the result can be used. It doesn't mention whether it returns a list of document IDs, titles, or content snippets, nor does it clarify if the search covers only accessible documents. This leaves a significant gap for an agent trying to invoke and process the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the parameter 'query' described as 'search keyword', and the description essentially repeats the same phrase ('按关键词搜索'). The description does not add new meaning beyond the schema, such as format constraints or examples. Baseline for high schema coverage is 3, and no additional value is provided.
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 'Search DingTalk documents by keyword' uses a specific verb (search) and resource (DingTalk documents), clearly indicating the tool's function. It does not differentiate from similar search tools like wiki_space_search or devdoc_article_search, which might also search documents, so it loses a point for not explicitly distinguishing among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios such as 'Use this to find documents by keyword; use doc_list to list all documents' or exclude any use cases. This leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有注解，描述仅说明“按KQL关键词搜索邮件”，未提及返回内容、分页、排序等行为。没有与注解矛盾，但信息量不足。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述为单句，简洁明了，没有冗余信息，较为高效。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具较简单，但无输出schema，描述未说明返回结构或任何使用限制。对于搜索邮件场景，缺少返回值格式等关键环境信息。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入schema中两个参数均有描述，覆盖率为100%，query参数给出了KQL示例，count参数说明了默认值。描述本身未增加额外的参数语义。
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?
描述使用动词“搜索”和资源“邮件”，并指定了KQL关键词搜索，明确了操作目标和方式。与发送邮件等sibling区分明显，但没有明确提到返回列表，稍有不足。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述没有提供使用场景或替代工具的指引，仅说明功能。没有排除条件或说明何时使用该工具而非其他邮件相关工具。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the one-sentence description carries the full burden. It does not disclose whether rejection is irreversible, what permissions are required, or what happens to the approval process after rejection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no unnecessary words, but it may be too terse to provide adequate context. It is front-loaded with the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 lacks an output schema and annotations, and the description provides no information about return values, side effects, or usage context. For a mutation tool, this is insufficient even though the parameter list is simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are documented in the schema with descriptions, so schema coverage is 100%. The tool description itself adds no parameter-level information, but the schema sufficiently covers meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('拒绝' = reject) and the resource ('一条审批单' = an approval order), distinguishing it from the sibling approve tool. However, it lacks detail about scope or context, making it clear but not rich.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 dingtalk_oa_approval_approve or dingtalk_oa_approval_tasks. The description is a standalone statement with no mention of prerequisites or conditions.
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?
There are no annotations, so the description carries full burden for behavioral disclosure. It names the action (submit) and report types, but omits side effects, permission requirements, reversibility, or response/return behavior, which is important for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no redundant wording; it successfully front-loads the core action. It is not bloated, though it could include more guidance without much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotated safety profile, no output schema, and the description does not mention prerequisites (e.g., fetching template details for JSON structure), invocation flow, or expected result. Given the required template_name parameter, contextual completeness is lacking for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: template_name and contents both have descriptions, including the JSON format requirement for contents. The description adds only general context (daily/weekly) and does not need to add further parameter meaning; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '提交一份日志（日报/周报等）' clearly indicates a submission action for a report/log resource with daily/weekly scope. It distinguishes from sibling list/send tools by the verb 'submit/create', though it does not explicitly contrast with report_sent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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: there is no indication of when to choose this tool over other report-related tools, or that a template must be selected beforehand. The description only states the action and gives no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the listing scope ('sent by self') and does not mention whether the operation is read-only, whether results are sorted or paginated, or what fields/objects are returned. This leaves significant behavioral ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise Chinese sentence with no redundant wording and places the core scope ('own sent logs') upfront. It is efficient and front-loaded, though minimal in content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema and no annotations, the description is under-specified: it does not mention the return format, ordering, pagination behavior, or whether all sent reports are always included. The single parameter is well documented, but the overall behavior and result expectations are not complete enough for reliable autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter 'count' with '数量，默认 20', providing adequate meaning at the schema level. The description itself adds no parameter-specific information, so the baseline score of 3 applies because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the explicit verb '列出' and identifies the resource as '自己发送的日志' (reports sent by the current user), which clearly indicates an operation to list one's own sent reports. This scoping distinguishes it from similar sibling tools like dingtalk_report_list, though it does not explicitly mention the sibling by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as dingtalk_report_list or dingtalk_report_template_list. It does not mention exclusions, prerequisites, or alternative tool names, so the usage context is only implied by the tool name and brief scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only states 'write data' without explaining whether this overwrites the entire range, how it handles partial updates, whether special permissions are needed, or what the response looks like. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action. There is no redundant information or filler. It is appropriately sized for the simplicity of the tool, even though it lacks contextual details that are penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a write/update operation with no annotations or output schema, the description needs to convey overwriting behavior, data format expectations, and possible side effects. It only says 'write data to a specified area,' which is insufficient to distinguish from the sibling append tool. The schema covers parameter meanings but not the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters, covering 100% of them. The description itself does not add any additional parameter context beyond what the schema already offers. Per the rubric, a baseline of 3 is appropriate when schema coverage is high and the description does not supplement it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'write data' and the resource 'specified area of an online spreadsheet'. It conveys the core action, but does not explicitly distinguish itself from sibling tools like dingtalk_sheet_append or dingtalk_sheet_read. The name 'update' implies overwriting an existing range, but the description alone could be confused with appending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is for updating existing cells, while append adds rows, or that read is for retrieval. The agent is left to infer usage from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the creation action, without mentioning any side effects, permissions needed, or what the response contains (e.g., created task ID). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that avoids verbosity. It is front-loaded with the core action. However, it is almost too terse, providing minimal content beyond the name, yet it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is incomplete. It does not clarify return values, required permissions, or parameter format nuances beyond what the schema shows. A more complete description would mention typical usage or examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all four parameters. Since the schema already documents each parameter, the description adds no extra semantic value. Baseline of 3 is appropriate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action clearly: '创建待办任务' (Create to-do task). It specifies a concrete verb and resource, aligning with the tool's name and distinguishing it from sibling operations like update, delete, list, or get. However, it lacks explicit differentiation from the 'done' operation which also mutates task state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 update or done. The context is implied by the name and sibling tools, but there is no explicit mention of prerequisites, exclusions, or alternative choices.
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 only states '创建新的 AI 表格（Base）'. It does not mention authentication needs, potential side effects, whether duplicate names are allowed, or what the response contains, offering no insight beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly conveys the tool's function. It is front-loaded with the action and resource, contains no fluff, and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context such as return values, required permissions, or idempotency. It merely states the creation action without explaining what happens on success, leaving the description incomplete for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'name' parameter with description 'Base 名称', giving 100% schema coverage. The description adds no additional semantic detail about this parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '创建新的' (create new) and the resource 'AI 表格（Base）', making it specific to the AITable Base creation tool. This distinguishes it from siblings like dingtalk_aitable_record_create or dingtalk_aitable_base_list by naming the exact resource and operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as dingtalk_aitable_base_list or dingtalk_aitable_record_create. There is no mention of prerequisites, exclusions, or preferred use cases, leaving the agent without contextual selection 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. It only states the basic action without disclosing behavior such as pagination via the count parameter, the definition of 'received', or any side effects. This is a significant gap for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase (列出收到的他人日志) with no filler or redundant information. It is front-loaded and easy to parse, achieving maximum clarity in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple schema, the tool operates in a complex domain with many report-related siblings. The description does not explain what a 'log' is in this context, how to use the count parameter, or when to prefer this tool over others, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the count parameter with a description ('数量，默认 20') and coverage is 100%. The description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '列出' (list) and the resource '收到的他人日志' (received reports from others), clearly distinguishing it from sibling tools like dingtalk_report_sent (sent reports) and dingtalk_report_template_list (templates). Verb and resource are precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, what 'received' means in practice (e.g., reports submitted to the user), or how it differs from related report tools. There are no alternatives or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states that existing record field values are updated, but does not mention whether this is a partial or full replace, what happens if a recordId does not exist, permission requirements, or any side effects. This is a minimal disclosure 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately communicates the core action and target. There is no wasted wording or fluff. It earns its place by being clear and direct, though it could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with no output schema and no annotations, the description is too sparse. It does not explain expected return values, error conditions, partial vs full updates, or how the 'records' parameter interacts with existing data. This is a significant gap for an update operation, though the tool is part of a larger AITable family where some context is implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (base_id, table_id, records) with 100% coverage. The description itself adds no additional parameter context beyond the operation name. The baseline of 3 is appropriate since the schema does the heavy lifting, and the description does not enhance understanding of parameter usage or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('更新' - update) and the resource ('数据表中已有记录的字段值' - field values of existing records in a data table). This differentiates it from sibling tools like record_create or record_delete, which handle creation and deletion respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool vs alternatives. While the name and description imply it is for updating existing records, there is no explicit mention of prerequisites, exclusions, or when a different tool should be chosen (e.g., record_create for new records, record_query for reading).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'list all data tables' with no mention of pagination, output format, permissions, side effects, or error behavior. Minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that front-loads the action and object without any redundant words. It is appropriately concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain what information is returned for each table (e.g., table ID, name, metadata). It is a simple listing, but the lack of return format, pagination, or error behavior leaves notable gaps, making it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for base_id is 100% with description 'Base ID', and the tool description adds little beyond referencing 'the Base'. Since schema already documents the parameter adequately, the description's contribution is minimal, matching the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all data tables in a Base using the verb '列出' and resource '数据表'. It is specific enough to distinguish from sibling tools like base_list (lists bases) and record_query (queries records), though it does not explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention when to prefer it over other Base/table tools, nor does it give any exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It implies a read-only introspection operation via 'schema 自省', but does not explicitly state that it has no side effects, what it returns, or any permissions needed. The description adds minimal behavioral context beyond what the name suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without excessive detail. However, the undefined 'dws' abbreviation slightly reduces clarity, but overall it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide a clear picture of the return value and scope. It does not explain what 'dws' refers to, what format the tool counts take, or any further details about the introspection results, making it incomplete for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already covers 100% (vacuously). The description adds no parameter information, but the baseline for zero parameters is 4, as there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all available products and tool counts for schema introspection, using the verb '列出' (list) and specifying the resource as schema. It distinguishes from sibling tools as the only schema discovery tool, though the abbreviation 'dws' is somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. It simply gives a one-line definition, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It only states that the tool lists the node tree; it does not mention whether the list is recursive, how pagination works, required permissions, or what the response structure looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose. However, its brevity comes at the cost of missing essential usage and output details, so it is efficient but not fully sufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should at least indicate what the returned node tree contains (e.g., node IDs, names, types, hierarchy). It does not, and it also fails to explain the behavior when parent_node_id is provided. Given the tool's moderate complexity, the description is not sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description does not add any information about the parameters; in particular, the optional parent_node_id parameter's effect on the returned tree is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action ('列出' - list) and the resource ('知识库空间中的节点树' - node tree in knowledge base space), with a clarifying parenthetical about documents and folders. This clearly distinguishes the tool from sibling tools like wiki_space_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as wiki_space_search or doc_search. It does not mention any prerequisites, exclusions, or recommended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does; it does not mention side effects (likely none), required permissions, return format, pagination, or error behavior. For a simple read operation this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the action and resource. However, it is so minimal that it borders on under-specification, but for a simple get operation it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 parameters, full schema coverage, and no output schema, the description is moderately complete. It conveys the core purpose but lacks any context about return data, usage scenarios, or differentiation from similar aitable tools. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (base_id and table_id) with descriptions, providing 100% coverage. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '获取数据表的字段定义列表' (get the field definition list of a data table). It uses a specific verb and resource, clearly distinguishing it from sibling tools like aitable_table_get (table metadata) and aitable_record_query (records).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or situations where another tool might be more appropriate. The purpose is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden of disclosure. It only states the basic insertion action without detailing behaviors such as field validation, partial failure handling, return values, or permission requirements. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core function. It is front-loaded and contains no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description leaves unclear what the tool returns (e.g., created record IDs, success status) and any error conditions. For a create operation, this is a notable gap. The tool is simple, but the lack of return/error information makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with descriptions (100% coverage), so the baseline is 3. The tool description itself does not add parameter-specific meaning beyond the schema, but the schema already documents base_id, table_id, and records (including the JSON format for records), so no additional description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '向数据表插入一条或多条记录' clearly states the action (insert) and the resource (data table records), explicitly mentioning that one or more records can be inserted. This distinguishes it from sibling tools like query, update, and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 the many sibling tools for Aitable records (query, update, delete) or other resources. The description does not mention exclusions, prerequisites, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It says 'delete' which implies destructive action, but does not disclose irreversibility, permission requirements, potential cascade effects, or any post-conditions. Minimal additional 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently states the operation and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse. It does not explain side effects, safety caveats, or when to use this over other record operations. For a destructive tool, more context is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (base_id, table_id, record_ids) described. The tool description adds no extra parameter meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('删除' = delete) and clearly identifies the resource ('数据表中的一条或多条记录' = one or more records in a data table). It distinguishes this from sibling record tools like create/update/query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, no exclusions. The description simply states what it does without contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. '获取日程详情' implies a read-only operation but does not explicitly disclose behavior such as needing an event_id, error cases, or what details are returned. This is a minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, extremely concise and front-loaded with the core purpose. It could be more complete as a full sentence, but it earns its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one parameter and no output schema, the description provides basic understanding but fails to describe the return format or any specifics about the 'details'. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single parameter event_id is fully documented as '日程 ID'. The description adds no additional parameter semantics, but the schema is sufficient, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取日程详情' (get event details) clearly states a specific action (get) and resource (calendar event details), distinguishing it from sibling tools like dingtalk_calendar_event_list (list) and dingtalk_calendar_event_create (create). It is unambiguous and precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context about retrieving a single event by ID. The agent must infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as whether it is read-only, pagination behavior, time range interpretation, authentication requirements, or what fields are returned. The description adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the action and scope. No filler or redundancy, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is severely incomplete. It does not explain the return format, how limit and group_id affect results, potential errors, or rate limits. For a listing tool, more detail is expected to help the agent understand invocation and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description does not add any extra meaning beyond the schema, but it does not need to since parameters are well-described. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb '获取' (get) and resource '消息列表' (message list), scoped to '当前用户被 @ 的' (current user's @mentions), which clearly distinguishes it from sibling tools like list_unread or general list. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as dingtalk_chat_message_list_unread, dingtalk_chat_message_list, or dingtalk_chat_message_search. The description only implies usage via the mention scope, with no explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It only states the action and mechanism, without any mention of authentication requirements, rate limits, failure behavior, or the nature of the message (e.g., whether it supports markdown). This leaves significant gaps for an agent deciding whether to invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key action and mechanism, and contains zero wasted words. It is appropriately concise for its low complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 100% schema coverage and no output schema, the description omits important context such as when to use this tool versus sibling send tools, and what the caller should expect on success or failure. The lack of annotations makes this gap more severe, so the description is incomplete for an agent to confidently select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a clear description (e.g., 'Webhook token (access_token 的值, 必填)'). The tool description itself adds no extra meaning to parameters, but since the schema already covers them, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a group chat message using a custom robot webhook token, specifying both the resource (group chat) and the method (webhook token). However, it does not distinguish from sibling tools like dingtalk_chat_send_by_bot or dingtalk_chat_send_message, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a custom robot webhook token, but provides no explicit context about when to prefer this over other send-message tools, nor does it mention alternatives or exclusions. There is some implied guidance from the 'via webhook token' phrasing, but no clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic get behavior and content type (summary) but does not disclose potential access requirements, return format, or behavior for invalid IDs. The description adds no context beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words, front-loading the action and resource. It is appropriately sized for a simple tool, though so minimal it borders on under-specification, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description provides the essential purpose but lacks contextual completeness. It does not explain when to use this instead of other minutes tools, nor does it describe the summary's contents or any edge-case behavior. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single required parameter minutes_id with description '听记 ID'. The description adds no extra meaning about the parameter. With 100% schema description coverage, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves the AI-generated smart summary of a minutes/recording using the verb '获取' (get) and the specific resource 'AI 听记的智能摘要'. This clearly distinguishes it from sibling tools like dingtalk_minutes_get_transcription (full transcript) and dingtalk_minutes_get_todos (action items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 choosing this for a concise summary rather than the full transcription, nor does it reference any sibling tools, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although the verb 'delete' implies destruction, the description provides no explicit details about irreversibility, permission requirements, or what happens to the task after deletion. With no annotations provided, the description carries the full burden but fails to disclose any behavioral traits beyond the base action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no filler or redundant content. It is appropriately sized for a simple one-parameter delete operation and is front-loaded with the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple, but without annotations or an output schema, the description should still mention context such as whether the task must exist, if the deletion is permanent, or any error conditions. The one-line description is insufficient to fully guide an agent in all situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (task_id) with the description '任务 ID', providing full coverage. The tool description adds no additional meaning to the parameter, so the baseline score of 3 applies as schema already handles the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除待办任务' clearly states a specific verb (delete) and resource (todo task). It distinguishes from sibling operations like dingtalk_todo_task_done (mark done) and dingtalk_todo_task_update (update), leaving no ambiguity about the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as dingtalk_todo_task_done or dingtalk_todo_task_update. The description does not state prerequisites, side effects, or indicate that it is for permanent removal rather than completion.
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. However, it only says '更新待办任务' without mentioning permissions, idempotency, partial vs. full replace, error behavior, or side effects. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and resource. There is no wasted wording, and every part contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a minimal description, the tool is under-specified. It does not explain the result of an update, whether fields can be partially updated, or any prerequisites. The schema covers parameters, but the overall operational context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already having a description. The tool's description adds minimal extra meaning by listing '标题、截止时间等' but does not go beyond what the schema already conveys. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '更新待办任务（标题、截止时间等）' clearly states a specific action (update) on a specific resource (todo task), and the verb '更新' distinguishes it from sibling tools like create, delete, and done. It is unambiguous and direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying existing todo tasks but provides no explicit when-to-use or when-not-to-use guidance compared to alternatives such as dingtalk_todo_task_done or dingtalk_todo_task_delete. The context of it being an update tool is clear, but exclusions and alternative choices are not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the search action. It does not mention result format, matching behavior, pagination, or error handling. This leaves the agent unaware of important runtime characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with zero fluff. It directly states the purpose, making it easy to parse. Sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description is too thin. It does not explain what results look like (no output schema), how results relate to the keyword, or any usage caveats. With no annotations or output schema, the description should carry more weight but only offers a bare statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single parameter 'keyword' is described as '空间名称关键词'. The description adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '按关键词搜索知识库空间' clearly states a specific action (search) on a specific resource (knowledge base space) via keyword. It distinguishes from siblings like dingtalk_wiki_space_list which lists spaces without searching, and from other search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as dingtalk_wiki_space_list or dingtalk_doc_search. It lacks any context about use cases, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden for behavioral disclosure. The verb '查询' implies a read-only operation, but the description does not mention any required permissions, potential pagination, or the format of returned records. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. There is no wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity (3 parameters, no nested objects, no output schema), the description is sufficient but leaves gaps: it does not explain what the returned records look like or when this tool is preferred over the related 'dingtalk_attendance_summary'. It is adequate for a basic query tool but not rich with supporting context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters (user_id, start_date, end_date). The description adds no additional meaning beyond what the schema already provides, making it a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询用户的打卡记录' clearly states the action (query) and the resource (attendance records). It is specific enough to understand the tool's function, but does not explicitly differentiate from the sibling tool 'dingtalk_attendance_summary', which likely provides aggregated attendance data rather than raw records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'dingtalk_attendance_summary'. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action, revealing nothing about potential recursion into sub-departments, pagination, rate limits, authentication requirements, or the structure of returned data. The agent is left without critical safety or expectation-setting information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, front-loaded sentence in Chinese. It communicates the essential purpose with zero wasted words, perfectly appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally viable. However, it omits important context such as whether the member list is paginated, whether it includes sub-departments, and what fields each member object contains. Since no output schema exists, the description should provide more detail about expected results, making this a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter dept_id with '部门 ID' (Department ID), achieving 100% schema coverage. The description adds no extra meaning about the parameter, such as format, where to obtain it, or whether it accepts '0' for the root department. Baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: '列出指定部门的所有成员' (list all members of a specified department). The verb '列出' (list) and resource '指定部门的所有成员' (all members of a department) make the purpose specific and distinct from sibling tools like dingtalk_contact_user_get (single user) and dingtalk_contact_dept_search (search departments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It simply implies usage when listing department members, but without explicit context or alternative comparisons, the agent receives no additional decision-making support.
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 only repeats the general functionality and lists metadata fields, without revealing potential errors (e.g., invalid doc_id), permissions required, whether the path is absolute/relative, or if the tool handles both docs and files uniformly. This is insufficient for an agent to predict behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured Chinese sentence that front-loads the action and resource, then lists the specific metadata fields. Every word contributes; there is no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no output schema), but the description omits important context such as possible error conditions, whether the metadata list is exhaustive or examples, and any relationship to sibling doc/drive tools. It is adequate for basic understanding but leaves gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter doc_id as '文档 ID' (document ID), so coverage is 100%. The description adds minimal extra meaning by clarifying that the ID refers to a document/file and that its metadata is being retrieved, but this is largely redundant with the tool name and schema. Thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('获取' - get) on a specific resource ('文档/文件' - documents/files) and enumerates the returned metadata fields (title, type, owner, path). This distinguishes it from sibling tools like dingtalk_doc_read (which likely retrieves content) and dingtalk_drive_info (which is drive-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as dingtalk_doc_read or dingtalk_drive_info. There is no mention of preferred scenarios, fallback tools, or exclusions. Usage is only implied by the general purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions reading content in Markdown format, but does not disclose permissions, error behavior, response structure, or any side effects. For a read tool this is less critical, but still lacks important context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly and efficiently communicates the tool's purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description is minimal. It does not clarify what the output contains (beyond Markdown), whether it returns full or partial content, or how it differs from similar doc tools. Given no output schema and no annotations, slightly more detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the sole parameter doc_id has a description ('文档 ID'). The description adds no additional meaning about the parameter beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads DingTalk document content in Markdown format. It uses a specific verb ('read') and resource ('document content'), distinguishing it from sibling tools like dingtalk_doc_info (likely metadata) and dingtalk_doc_update (write).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 dingtalk_doc_info or dingtalk_sheet_read. The description only states what the tool does, without specifying use cases or exclusions, which is insufficient given the large number of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It only states 'get metadata' without disclosing return format, whether both files and folders are covered, permission requirements, or error behavior. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence directly stating purpose, front-loaded with the verb, and no unnecessary words. Exactly as concise as needed for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, no output schema), and the description conveys the primary use. However, it does not detail what metadata fields are returned, which could be helpful. Still, it is not severely under-specified for a basic metadata retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with file_id described as '文件或文件夹 ID'. The description adds no new meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses precise verb '获取' (get) and specifies the resource '钉盘文件/文件夹的元数据' (metadata of DingTalk Drive files/folders), clearly distinguishing it from sibling tools like drive_download or drive_mkdir.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose this over related drive tools. It doesn't mention whether it applies to specific file types, when to use instead of dingtalk_doc_info, or any prerequisites for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the basic action (listing files/subfolders) but omits important details such as whether the listing is recursive, whether hidden files are included, pagination behavior, required permissions, or the structure of the return value. This is a minimal description for a read operation, but it lacks the context an agent might need to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core functionality. Every word contributes to understanding the tool's purpose, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 optional parameter, no output schema), and the description clearly indicates the operation. However, it does not specify return value structure, recursion behavior, or any caveats, which could leave the agent uncertain about how to process results. Given the simplicity, the description is minimally sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: parent_id is described as '文件夹 ID（空则列出根目录）' (folder ID; empty lists root). The description itself does not add any parameter-related information, so it relies entirely on the schema. Per calibration, high schema coverage yields a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '列出钉盘文件夹内的文件和子文件夹' (list files and subfolders in the DingTalk Drive folder). It specifies a concrete action (list) and resource (folder contents), distinguishing it from sibling tools like dingtalk_drive_info (retrieve drive info), dingtalk_drive_mkdir (create folder), and dingtalk_drive_download (download file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It only states what it does, leaving the agent to infer usage from the name and context. There are no references to sibling tools or conditions under which this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden of behavioral disclosure. It only says 'create a new folder' and omits important behavioral details such as permission requirements, duplicate name handling, parent folder defaults, or whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct Chinese sentence with no redundant wording or filler. It front-loads the core action effectively and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mkdir tool, the description plus schema is minimally adequate, but it leaves gaps: no return value description, no mention of where the folder is created if parent_id is omitted, and no error or permission context. These gaps are notable given there is no output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (name and parent_id) with descriptions, and the schema description coverage is 100%. The description adds no additional semantic value beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('在钉盘中创建新文件夹' = create a new folder in DingTalk Drive) and distinguishes it from sibling drive tools like list, info, and download. The verb and resource are explicit and match the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention how parent_id behaves (e.g., root folder default). It only gives the bare action, leaving usage context entirely to the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It only says 'list' (a read operation) but gives no detail about what is returned (e.g., full minutes vs. metadata), pagination behavior, or any authorization needs. This minimal disclosure is insufficient for an agent to fully anticipate tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action and scope. It wastes no words, though it could optionally mention the parameters or usage context without becoming verbose. It earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should clarify what the list returns and how it relates to sibling minutes tools. It does neither. The simplicity of the tool (two optional params) helps, but the lack of context about return values and usage boundaries leaves the description incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters (count, keyword). The description adds no parameter-specific information, but per the rubric, when schema coverage is high, the baseline is 3. It does not need to compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and the resource ('AI listening notes (meeting minutes)') with a scope qualifier ('created by me'). This distinguishes it from the sibling tool dingtalk_minutes_list_shared, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope '我创建的' implies this is for the user's own minutes, and sibling names like dingtalk_minutes_list_shared suggest a split between 'mine' and 'shared'. However, the description does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or prerequisites. Usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. The verb 'read' clearly indicates a non-mutating operation, which is the primary behavioral trait. However, it does not disclose any further behaviors such as authentication requirements, output format, or error conditions. Given the simplicity of a read operation, the implicit non-destructive nature earns a moderate score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, immediately front-loaded with the core action (读取) and target (在线电子表格指定区域). There is no filler or redundancy. It is appropriately sized for the tool's simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters and no output schema. The description explains the basic operation but does not specify what kind of data is returned (e.g., whether it's a 2D array, raw values, or formatted) or any edge cases (e.g., empty cells). Since no output schema exists, the description should have compensated with return value details, but it remains minimal yet not entirely inadequate for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides explicit descriptions for both parameters: range ('单元格区域，如 Sheet1!A1:C10') and sheet_id ('电子表格 ID'). The description adds no extra parameter semantics beyond echoing '指定区域', which aligns with the range parameter. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (读取, 'read') and the resource (在线电子表格指定区域, 'specified region of an online spreadsheet'). It is concise and unambiguous, though it does not explicitly differentiate itself from sibling tools like dingtalk_sheet_update or dingtalk_doc_read, the verb 'read' and the focus on 'axls' sheets make the purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or scenarios where a different tool (e.g., dingtalk_doc_read) would be more appropriate. The agent is left to infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry behavioral disclosure. It only states that the tool lists the current user's todo tasks, with no mention of read-only semantics, return format, pagination, sorting, or any side effects. Minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly front-loads the action and resource. There is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is functional but lacks details on return structure, default behavior (e.g., whether incomplete tasks are listed by default), and pagination. Since no output schema exists, the agent would benefit from additional context, making this merely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a complete description of the only parameter 'done' with true/false semantics, achieving 100% coverage. The tool description adds no additional parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses '列出' (list) with a specific resource '待办任务' (todo tasks) and scope '当前用户' (current user), clearly distinguishing it from other todo task tools like create, get, update, done, and delete. This makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While it is implicitly the list counterpart among todo tools, it lacks any direct context or exclusions, and does not mention which sibling tools are alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'recommend available time slots,' but does not disclose whether the tool is read-only, what the return format is, how many suggestions are returned, or any prerequisites or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately states the tool's purpose. No filler, and it is appropriately concise for a straightforward recommendation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description leaves many operational details unaddressed, such as the format of recommendations, whether the tool requires both start_time and end_time, and how errors are handled. This is insufficient for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameter descriptions. The description adds that the recommendation is based on busy/free data and that start/end time define the candidate range, but this is implicit and does not add significant extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: recommend available meeting time slots based on participants' busy/free data. It uses a specific verb ('推荐') and resource ('可用会议时间段'), and it is distinct from sibling tools like event_create or busy_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for scheduling meetings, but it does not explicitly mention when to use this tool over alternatives. There is no comparison to busy_search or event_create, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not mention prerequisites (event must exist), partial vs full update semantics, or error behavior. It also mentions '参与者' (participants) which is not in the schema, creating potential confusion. No return value or permission context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It lacks behavioral context, update semantics, and return expectations. It doesn't explain what happens on partial updates or error conditions, making it insufficient for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% parameter coverage with descriptions for all 5 fields. The description adds minimal value by grouping 'time, title, participants', but 'participants' doesn't correspond to any schema parameter, slightly impairing clarity. Baseline 3 is appropriate since the schema carries the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '更新' (update) and resource '日程信息' (calendar event information), clearly distinguishing it from sibling create/delete/get tools. It explicitly mentions updatable fields (time, title) and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (update existing event) via the verb and required event_id, but provides no explicit when-to-use guidance or alternatives. An agent must infer from the name that this is for modifying existing events, not creating new ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'batch' retrieval and example fields but does not describe behavior for invalid userIds, whether partial success is possible, permission requirements, or error handling. This is a significant gap for a read tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core action. It is concise and to the point, with no filler. While it could additionally mention usage context, it earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is somewhat complete: it states the purpose and provides example return fields. However, it lacks details on return format, error handling, and any constraints (e.g., max number of user_ids), leaving notable gaps for an agent relying solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter (user_ids) as a comma-separated list, providing 100% coverage. The description adds no new parameter syntax details but clarifies the batch nature and example output fields. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it batch-retrieves detailed user information (name, department, email, etc.) based on userId. The verb '获取' (get) is specific, the resource is '用户详细信息' (user detailed info), and the method '根据 userId' distinguishes it from search or self-info tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. Usage is implied by the name and description (when you have userIds and need their details), but there is no comparison with sibling tools like get_self or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the action and gives no information about consequences (e.g., irreversible approval), required permissions, or edge cases like already-approved instances. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct phrase that states the purpose without redundancy or fluff. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no output schema and no annotations, the description is minimal and does not provide enough context about the workflow (e.g., how to obtain the required IDs, what happens after approval). The schema covers parameters but not overall usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds no parameter information beyond the schema, but the schema already provides clear descriptions for instance_id, task_id, and remark, including a helpful hint that task_id can be obtained via tasks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '审批通过一条审批单' clearly states the action (approve) and the object (an approval form), using a specific verb+resource structure. It naturally distinguishes from sibling tools like dingtalk_oa_approval_reject (reject) and read-only tools such as dingtalk_oa_approval_detail or dingtalk_oa_approval_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use or alternatives to other tools. However, the schema's hint that task_id can be obtained via 'tasks' implies a workflow, and the tool's name itself suggests its role. No explicit comparison with reject or other approval actions is given, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the scope (current user) and output type (ID list), but does not mention pagination, ordering, error behavior, or authentication needs. Basic context is present but not rich enough for a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short, front-loaded sentence. Every word contributes meaning and nothing is wasted. Highly concise and well-structured for a 0-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and no annotations, the description gives the essential purpose but omits any detail on how the output list is returned (e.g., pagination, limits) and fails to differentiate from the sibling 'dingtalk_oa_approval_list_pending'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per rubric the baseline is 4. The description correctly avoids adding anything about parameters since there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb '列出' (list) with a specific resource ('当前用户的待审批任务') and output ('ID列表'), making it clear what the tool does. However, it does not distinguish itself from the similarly named sibling 'dingtalk_oa_approval_list_pending', so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the similar sibling tool 'dingtalk_oa_approval_list_pending'. No contextual hints, prerequisites, or alternative comparisons are provided, leaving the agent to guess.
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 must fully convey behavioral traits. While '查看' implies a read-only operation, the description does not disclose return format, pagination, timezone handling, or any side effects. It adds little beyond the tool name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It directly states the tool's function in a compact form, earning high marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and no output schema, the description covers the main purpose but leaves gaps: it does not mention what the return list contains, whose calendar is accessed, or timezone handling. It is adequate but not fully complete for an agent to predict all behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for both parameters, including ISO 8601 format and default value for start_time. The description only generically refers to a 'specified time period' without adding deeper meaning or clarifying the relationship between start_time and end_time.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (查看/list) and the resource (日程列表/calendar event list) with a specific time-range scope (指定时间段). It distinguishes this tool from singular event retrieval (dingtalk_calendar_event_get) and other calendar operations by emphasizing the list aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a list of events in a time period is needed, but it provides no explicit context for when to use this tool versus alternatives like calendar_busy_search or calendar_event_get. There is no mention of exclusions or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It adds useful context about pagination (分页) and chat type coverage, but omits details like max limit, sorting order, return structure, or any side effects (though this is a read-only operation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core function (time-range search), then adds scope (single+group) and pagination. Every element earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description adequately conveys the basic operation. However, it does not mention what the response contains (e.g., message fields) or define 'all' more precisely, leaving an agent with only partial expectation of the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with start, end, and limit all described in the schema. The description adds no parameter-specific meaning beyond reaffirming time range and pagination, so it neither improves nor detracts from the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'search' (搜索) and resource 'historical messages' (历史消息), with explicit scope 'including single and group chats' (包含单聊和群聊). This clearly states what the tool does and differentiates from unread or mention-specific message tools, though it doesn't name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for time-range-based paginated search of historical messages, which is a clear scenario. However, it does not explicitly contrast with similar siblings like 'dingtalk_chat_message_list' or provide when-not-to-use guidance, leaving some ambiguity about which list tool to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool retrieves unread conversations but does not disclose return format, pagination, sorting, or whether unread status is changed after retrieval. This leaves the agent uncertain about side effects or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the essential function without any wasted words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description is the sole source of return-value context. It tells the agent the high-level result (a list of conversations with unread messages), but lacks details on the conversation fields (e.g., IDs, names, unread counts). For a simple read-only list tool, this is acceptable but leaves ambiguity about the exact payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so the baseline score is 4 per the guidelines. The description appropriately mentions no parameters, and no parameter semantics are needed. It does not add extra parameter context, but none is required for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '获取当前用户有未读消息的会话列表' (get the current user's list of conversations with unread messages). It features a specific verb ('获取') and a well-defined resource ('有未读消息的会话列表'). This distinguishes it from sibling tools like dingtalk_chat_message_list or dingtalk_chat_message_search, which focus on messages rather than conversation lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or when to prefer sibling tools like dingtalk_chat_message_list_all or dingtalk_chat_message_list_mentions. The intended usage is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the message is sent as the current user and enforces an exclusivity constraint among the three recipient identifiers. However, it does not mention authentication requirements, error behavior, or what the response contains—clear gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core purpose and then provides parameter selection rules. Every phrase earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema or annotations, the description covers the essential purpose and recipient selection logic. It lacks information about response/return behavior and does not clarify how to obtain group_id or user_id, but the tool is simple enough that these are not fatal omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 5 parameters, so the baseline is 3. The description adds marginal value by summarizing the exclusivity relationship ('三者选其一') and mapping recipient types to parameters, but does not provide any deeper semantics beyond what the schema already gives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('send message') and the resource scope ('to group chat or individual'), with a specific identity context ('as current user'). It does not explicitly name sibling tools like dingtalk_chat_send_by_bot or dingtalk_chat_send_by_webhook, but the identity framing helps distinguish it from bot/webhook sends, so it falls short of a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on which parameter to use for group vs. direct messages ('发群聊用 group_id；发单聊用 user_id...'), which is useful. However, it does not explicitly state when to choose this tool over the sibling sending tools (e.g., bot or webhook), so the when-to-use guidance is incomplete.
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 only states 'search' without revealing return format, pagination, or behavior for no results, which is a significant gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, front-loading the essential action. It is appropriately sized for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the description covers the basic purpose. However, with no output schema, the description should ideally indicate what the search returns; it doesn't, leaving a minor completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the keyword parameter as '部门名称关键词' with 100% coverage. The description adds no extra meaning beyond the schema, meeting the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '按关键词搜索组织架构中的部门' clearly states the action (search) and resource (departments), and implies the organization structure context. It distinguishes itself from sibling tools like user search or dept member list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a department keyword is known, but provides no explicit when-to-use vs alternatives, no exclusions, and no mention of when not to use it. It's acceptable but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only mentions that it searches and returns userId and other info, but omits details like search scope, matching semantics, handling of no results, or response structure. This is minimal for a search tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that front-loads the tool's purpose and key output. It contains no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description lacks depth given the absence of annotations and output schema. It does not clarify the full set of returned fields, whether matching is fuzzy, or how it relates to sibling search tools, leaving some uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the query parameter with 100% coverage, and the description's mention of '按姓名/职位等关键词' simply reiterates the schema's parameter description without adding new meaning. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches DingTalk contact users by keywords such as name/position and returns userId and other information. This specific verb+resource+scope distinguishes it from sibling tools like search_mobile and get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying the search criteria (keyword by name/position), but it does not explicitly state when to use this tool over alternatives like search_mobile or provide exclusions. Guidance is implicit, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic lookup action without mentioning permissions, error behavior, or side effects. There is no explicit statement that this is a read-only operation, though it is implied by '查找' (search).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the essential purpose without any fluff. Every word earns its place, and the structure is appropriate for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description lacks any information about the return value format, behavior when the user is not found, or required permissions. Since there is no output schema, these details would be helpful. However, the minimal description is adequate for a basic search, though gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the 'mobile' parameter as '手机号' (mobile number), and the description repeats this by saying '根据手机号'. Since schema coverage is 100%, the description adds no additional semantic value beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '根据手机号查找钉钉用户' (find DingTalk user by mobile number), using a specific verb (查找/find) and resource (钉钉用户/DingTalk user) with a clear method. It distinguishes itself from sibling tools like 'dingtalk_contact_user_search' by specifying the mobile-number-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives such as 'dingtalk_contact_user_search'. The usage is implied by the name and description (i.e., when you have a mobile number), but no explicit guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. '覆盖更新' indicates an overwrite behavior, which is a key trait, but it does not disclose permission requirements, irreversibility, or return/response behavior. Some value is added, but significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action verb. It contains no fluff and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter update tool, the description is minimally viable but lacks details about return values, error conditions, or side effects. The overwrite semantics are clear, but the lack of any additional context beyond the schema leaves the tool partially underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters described: 'doc_id' as 文档 ID and 'content' as 新内容（Markdown）. The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '覆盖更新钉钉文档的正文内容' clearly states a specific verb (覆盖更新/overwrite update) and resource (钉钉文档的正文内容/DingTalk document body content). It distinguishes from sibling tools like create and read, indicating an update operation on an existing document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent to infer usage solely from the tool name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions that the link is temporary, but does not disclose response format, link expiration details, authentication requirements, or any side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the action and result with no redundant information. It is appropriately sized for the tool's simplicity and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers the core purpose and the fact that the result is a temporary link. However, it lacks details on the response structure or potential errors, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a complete description for the single parameter file_id with '文件 ID', achieving 100% coverage. The description adds no additional parameter semantics, so it meets the baseline for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '获取' (get) and clearly identifies the resource as '钉盘文件' (DingTalk Drive file), specifying the outcome as a '临时下载链接' (temporary download link). This distinguishes it from sibling tools like drive_list or drive_info, which focus on listing or metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The use case is implied by the tool name and the action 'download', but without further context, it only minimally meets the 'implied usage' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb '获取' implies a read-only operation, and '完整' adds a key behavioral trait (returns complete transcript, not partial). However, it doesn't disclose potential side effects, permissions, or output format, which are not obvious without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence in Chinese that starts with the verb and clearly names the resource. It contains no unnecessary words or repetition, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, and the description gives the essential purpose. However, it lacks context about the return format (e.g., plain text vs. structured), potential length, or how it relates to other minutes tools, making it minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, minutes_id, is fully described in the schema with '听记 ID', achieving 100% schema description coverage. The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (获取) and resource (完整语音转文字记录) to clearly state it retrieves the full transcription of AI meeting minutes. It distinguishes itself from sibling tools like get_summary and get_todos by explicitly targeting the transcript content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any conditions, exclusions, or alternative tools, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It only states the retrieval intent but does not disclose output format, error behavior, or any side effects. Minimal behavioral context beyond the tool's core purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description is adequate, but it lacks usage context, relationship to sibling report tools, and any return-structure details, making it minimally viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single param template_name is clearly described with examples; the description adds no extra parameter detail but is not required to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '获取' (retrieve) and resource '日志模板的字段结构' (field structure of report template), clearly distinguishing from sibling tools like listing templates or creating reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when the field structure of a specific report template is needed, but it does not explicitly state when to use it over alternatives like dingtalk_report_template_list or what prerequisites (e.g., template_name must be from an existing template) apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and lacks details about side effects, permission requirements, return values, or how existing data is treated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb and resource, containing no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward append operation with fully documented parameters, the description is minimally viable. However, with no annotations or output schema, it lacks guidance on return behavior, errors, and permissions, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter descriptions, so the baseline is 3. The phrase '末尾' (end) adds some context that values are appended after existing rows, but the description does not deeply enrich parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '追加' (append) and resource '在线电子表格' (online spreadsheet), with scope '末尾' (end), clearly distinguishing it from sibling tools like sheet_read and sheet_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: append data to the end of an online spreadsheet. However, it does not explicitly state when to use this tool versus alternatives such as sheet_update for modifying existing cells.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool marks tasks as completed or not completed, which is a mutation, but it does not specify permissions, side effects, behavior on non-existent tasks, or what happens if the 'done' parameter is omitted. For a mutation tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: '将待办任务标记为已完成或未完成'. Every word contributes to the core purpose, with no fluff or repetition. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema) and the description states the core action. However, without annotations, it leaves gaps: no usage context, no behavioral details (e.g., what constitutes success or failure), and no clarification of the optional 'done' parameter. It is minimally sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any meaning beyond the schema; it essentially repeats the concept of 'done' without referencing parameter names or additional semantics. The schema already fully describes task_id and done, so the description adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states '将待办任务标记为已完成或未完成' — marking a todo task as completed or not completed. This identifies the specific verb (mark) and resource (todo task), and distinguishes it from sibling tools like update (which would modify other fields) and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for setting the done status of a todo task. However, it provides no explicit guidance on when to use this tool versus alternatives like dingtalk_todo_task_update, nor any exclusions or prerequisites. The purpose is clear but not differentiated from update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'get details' and does not mention return format, permissions, side effects, or error handling. This is minimal transparency for a read operation without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function. It is appropriately concise with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description provides a minimal but adequate explanation. However, without an output schema, it doesn't specify what details are returned, and there's no mention of use cases or prerequisites, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with task_id described as '任务 ID', so baseline is 3. The description does not add any additional meaning beyond the schema, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取待办任务详情' clearly states the tool retrieves todo task details. It uses a specific verb (获取/get) and resource (待办任务/todo task), distinguishing it from siblings that create, list, update, or delete tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing details of a specific todo task, but provides no explicit guidance on when to use this vs. sibling tools like list or search. No exclusions or alternative mentions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only restates that it gets personal info, without explaining response format, field contents, authentication prerequisites, or limitations. This is a minimal description that adds no behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that clearly communicates the core purpose without unnecessary words or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should clarify what 'personal information' includes (e.g., name, avatar, user ID). It does not describe return values or any important context, leaving the agent guessing about the tool's output potential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics burden on the description. The schema correctly shows an empty object, so the description does not need to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('获取' = get) and resource ('当前登录用户的个人信息' = current logged-in user's personal info), distinguishing it from sibling tools that get/search other users by ID or mobile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied by the name and description: to retrieve the current user's own profile. It does not explicitly mention when to use other contact tools, but the differentiation is inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states that the tool '排查' (investigates) errors, but does not explain what the tool returns, whether it is read-only, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the tool's purpose. It avoids any unnecessary detail and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 terse description, the agent lacks information about what a diagnosis looks like or how to interpret results. The description does not explain the tool's output or provide examples, making it incomplete for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for each parameter. The tool description merely lists the three parameters without adding extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '排查' (troubleshoot/diagnose) and identifies the resource as DingTalk Open Platform API call errors. It clearly distinguishes from sibling tools since none of the other tools are focused on error diagnosis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you encounter API errors, given the parameters (requestId, error code, error description). It provides clear context without explicit exclusions or alternatives, but the purpose statement inherently tells the user when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the high-priority nature and delivery options, which is useful. However, it does not mention potential costs of SMS/phone, irreversibility, or recipient requirements, leaving gaps for a notification tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the primary action and resource, followed by key attributes. Every word adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward send operation with a fully described schema, the description provides adequate context regarding priority and delivery modes. It does not need to explain return values since no output schema exists, but it could mention response/error behavior for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described (type, users, content, robot_code). The description adds no additional semantic details beyond the schema's own descriptions, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('发送' = send) and the resource ('DING 消息' = DING message), and adds '高优先级通知' (high-priority notification) to indicate its distinct purpose. This differentiates it from generic chat send tools among siblings, though it could be more explicit about the targeting mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for high-priority notifications and lists delivery modes (in-app/SMS/phone), but it does not explicitly state when to use this tool over alternatives like dingtalk_chat_send_message or provide any exclusions. The context is clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic read operation but does not describe the return format, whether the minutes_id must exist, error handling, or any authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is mostly complete: it clearly states the resource and the input. However, the absence of an output schema and any return-value details means the agent must infer the structure of the todo list, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter minutes_id is fully described in the input schema ('听记 ID'), and the schema coverage is 100%. The description itself adds no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('获取') with a clear resource ('从听记中提取的待办事项'), making it obvious that this tool retrieves todo items extracted from meeting minutes. It distinguishes itself from sibling tools like dingtalk_minutes_get_summary and dingtalk_minutes_get_transcription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching todos from a given minutes record, but it does not explicitly state when to use this tool versus alternatives such as todo_task_list or minutes_get_transcription. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only listing operation and scopes to the current user, but does not disclose details such as pagination behavior, ordering, authentication requirements, or whether it returns full template definitions or summaries. The word 'list' implies non-mutating behavior, but the description does not explicitly ensure safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action and scope. Every word earns its place with no redundancy, filler, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does not explain what fields or structure the returned templates contain. It also fails to mention any possible pagination or limits. While the tool is simple, the description leaves the agent without enough detail to fully anticipate the result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty with 100% schema description coverage. There is nothing to explain about parameters, so the baseline of 4 applies as no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '列出' (list) and a clear resource '日志模板' (log templates), scoped to '当前用户可用' (available to current user). This distinguishes it from sibling tools like dingtalk_report_list (which lists reports) and dingtalk_report_template_detail (which gets template detail).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as dingtalk_report_template_detail or dingtalk_report_create. There is no mention of related tools, prerequisites, or scenarios where this tool is preferred, leaving the agent to infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'create' which implies mutation, but does not disclose permissions, side effects, or behavior on invalid inputs. The '指定位置' nuance adds only minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded with the action and object. Every word is useful, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with 3 well-documented parameters, the description is minimally sufficient. However, with no output schema, it could mention what is returned (e.g., document ID) or any prerequisites like authentication, which is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions '指定位置' which maps to parent_id, but the schema already explains each parameter. The description adds no additional parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '创建' (create), the resource '新钉钉文档' (new DingTalk document), and the location constraint '在指定位置' (at specified location). This distinguishes it from sibling tools like doc_update and doc_read, which handle different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new DingTalk document at a specific location, which is clear context. It does not explicitly name alternatives or exclusions, but there is no other doc creation sibling tool, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action (list), without mentioning read-only nature, permissions, pagination, or any side effects. For a list operation, this is minimal but not misleading, yet it lacks sufficient context for an agent to fully understand behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the essential purpose without extra words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is adequate but incomplete. It does not mention return format, recursion, sorting, or other behavior, and does not differentiate from similar list tools like dingtalk_drive_list. Given no output schema, additional detail about the response would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description already covers the parent_id parameter well (optional, empty for root). The tool description adds meaningful context by specifying that parent_id can refer to a folder or knowledge base, going beyond the schema's generic 'parent node ID'. This is valuable for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing files and subfolders within a folder or knowledge base. It uses a specific verb (list) and resource, distinguishing it from siblings like drive list or wiki node list by explicitly covering both folders and knowledge bases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to list contents of a folder or knowledge base) but does not explicitly mention when to use it over alternatives like dingtalk_drive_list or dingtalk_wiki_node_list. There are no exclusions or when-not-to-use guidance, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the listing action without detailing return format, pagination, or any side effects. The action 'list' suggests read-only, but this is implicit rather than explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function with no superfluous words. It is appropriately sized for a zero-parameter list tool and front-loads the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description gives enough to know what it lists, but it lacks information about the return format, pagination, or any filtering behavior. It is adequate but has clear gaps given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description correctly adds no parameter details. Per the rubric baseline, 0 params warrants a score of 4 since there is no parameter semantics needed. The description does not mislead or omit anything relevant to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出他人共享给我的 AI 听记' clearly states the tool lists AI minutes/transcripts shared to the user by others. The verb 'list' and specific resource (shared AI minutes) make the purpose unambiguous and distinguish it from the sibling tool 'dingtalk_minutes_list_mine'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the phrase 'shared to me', indicating it is for minutes from others, but it does not explicitly contrast this with alternatives like 'dingtalk_minutes_list_mine' or provide when-not-to-use guidance. No exclusions or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. However, it only restates the basic action (listing initiated approvals) without revealing any additional behavior such as pagination, ordering, result scope, or required permissions. This adds no transparency beyond what the tool name already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Chinese that directly states the tool's purpose. It is front-loaded with the key action and resource, with no unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description gives a basic understanding of the tool's function but does not explain return values, pagination, or any other contextual details. For a zero-parameter list tool, the description is minimally adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema provides no parameter information. Per the rubric, a 0-parameter tool gets a baseline score of 4 since there are no parameters for the description to elaborate on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出我发起的审批单' clearly states the tool lists approval requests initiated by the user. The verb 'list' and the resource 'initiated approval requests' are specific and distinguish it from sibling tools like dingtalk_oa_approval_list_pending, which lists pending approvals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying '我发起的' (initiated by me), which distinguishes it from pending approvals, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool references are provided beyond the implicit distinction visible in sibling names.
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 only restates the core listing behavior and does not disclose whether the operation is read-only, whether pagination or ordering applies, what fields are returned, or any authentication requirements. This leaves the agent without meaningful safety or behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the action and object. There is no filler, redundancy, or unnecessary ambiguity, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable for a zero-parameter list tool: it identifies what is listed and the target audience. However, the absence of annotations, an output schema, and any clarification about the result format or relationship to sibling approval tools means the context is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully covers parameter semantics. The description adds no parameter-specific details, but none are needed; this aligns with the baseline of 4 for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('列出' = list) and a clearly defined resource ('待我审批的审批单' = approval forms pending my approval), which precisely conveys the tool's function. It also distinguishes itself from the sibling tool dingtalk_oa_approval_list_initiated by explicitly scoping to pending approvals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '待我审批' implies the primary use case: retrieving approvals awaiting the user's action. However, the description does not explicitly state when to use this tool over alternatives like dingtalk_oa_approval_list_initiated, dingtalk_oa_approval_approve, or dingtalk_oa_approval_reject, nor does it provide any exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It communicates that the operation is read-only and scoped to the current user's accessible bases, but it does not disclose pagination, ordering, error behavior, or result format beyond the word 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no filler. It front-loads the operation and scope effectively for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter listing tool, the description is nearly sufficient, naming the action and access scope. However, without an output schema, it does not explicitly describe the returned base objects' key fields or pagination, leaving minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. There are no parameter semantics to document, and the description appropriately implies no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('列出'/'list') and identifies the resource ('当前用户可访问的 AI 表格（Base）'), clearly distinguishing this list operation from siblings like dingtalk_aitable_base_search and dingtalk_aitable_base_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 choose this tool over alternatives; sibling dingtalk_aitable_base_search exists but is never referenced. There are no explicit use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does reveal that the tool returns summary statistics (late, early leave, absence, overtime), which is useful context. However, it does not mention whether the operation is read-only, default behavior for omitted parameters, or any output format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource, with the statistics list in parentheses. Every word contributes value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description covers the core purpose and result scope (late, early leave, absence, overtime). It adequately differentiates from the record-level attendance tool, though it could explicitly mention the default current-user behavior, which is already documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both user_id and year_month, achieving 100% schema description coverage. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '获取用户考勤汇总' (get user attendance summary) with specific statistics listed (late, early leave, absence, overtime). It distinguishes from the sibling tool 'dingtalk_attendance_record_get' by focusing on the summary rather than individual records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining attendance summary statistics but does not explicitly state when to use this tool over alternatives like 'dingtalk_attendance_record_get'. It provides no exclusions or alternative names, so usage context is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation ('list') but does not disclose details such as whether comments include nested replies, ordering, pagination, or any side effects. It is not misleading, but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. No filler words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is fairly complete. It clarifies that the result is a 'comment list', but it does not mention pagination, ordering, or error handling, which could matter for long lists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter doc_id is fully described in the schema ('文档 ID'). The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states '列出文档的评论列表' which clearly means list the comments of a document. The verb 'list' is specific, the resource 'document comments' is precise, and it is distinct from sibling tools since no other tool in the list handles comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when you need the comment list of a document, but it provides no explicit when-to-use guidance or alternatives. It does not mention prerequisites like having document access or whether to use another tool for related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It identifies this as a read operation ('get') and lists expected content, but it doesn't disclose potential errors, permissions, or edge cases. No contradictions with annotations (none present).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the action and key object, with no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description adequately conveys the returned data categories (title, duration, participants). The inclusion of 'etc.' leaves some ambiguity but is acceptable for basic info. Sibling minutes tools are distinguished enough by the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single parameter (minutes_id) with a clear description. The tool description adds no further param details, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves basic information about a minutes item, including title, duration, and participants. This specific scope distinguishes it from sibling tools like get_summary, get_todos, and get_transcription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving basic minutes info, but it doesn't explicitly contrast with alternatives or provide when-to-use guidance. No exclusions or alternative tool references are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds that the list is restricted to the current user's accessible spaces, which is useful context. However, it does not explicitly state that the operation is read-only, nor does it describe the return format or pagination. For a list operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the action. It says everything necessary without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no params, no annotations, no output schema), the description is largely complete. It tells what the tool lists and the scope. It could potentially mention the fields returned, but that is not essential for a list operation. The lack of usage guidance is the main gap, but that is already penalized in its dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered vacuously. Per rubric, 0 parameters receive a baseline of 4. The description adds no parameter details because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '列出' (list) and the resource '知识库空间' (wiki spaces), scoped to '当前用户可访问' (accessible to current user). This distinguishes it from sibling tools like dingtalk_wiki_space_search, which is for searching, and dingtalk_wiki_node_list, which lists nodes within a space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for browsing all accessible spaces whereas search is for finding specific ones, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool supports filtering, sorting, and pagination, implying a read-only operation, but does not elaborate on return format, default limits, or edge cases. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main purpose and immediately lists key capabilities. No redundant information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should clarify the return structure and pagination behavior. It mentions pagination support but does not explain how it works or what the response looks like. The description is adequate for a simple query tool but leaves some gaps for a fully self-contained explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds the high-level concepts of filtering, sorting, and pagination, which map to the existing 'filter', 'sort', and 'limit' parameters, but does not provide additional syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'query' and the resource 'records in a data table', and specifies the supported operations (filter, sort, pagination). This distinguishes it from sibling tools like create, update, and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to query records with filtering, sorting, and pagination. It does not explicitly mention when not to use it or name alternatives, but the read-only nature is evident from the verb 'query'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the burden of behavioral disclosure. It adds the group vs. single chat targeting behavior but omits important aspects such as permission requirements, what happens if both group_id and users are provided, or the return value. It is not misleading, but it only partially discloses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that is front-loaded with the main action and immediately provides the key decision rule for parameter selection. There is no waste, and every word contributes to understanding the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no annotations, and no output schema, the description is quite brief. It covers the primary distinction between group and single chat but does not clarify that at least one of group_id or users is required (schema marks them optional), nor does it mention precedence if both are provided or any response behavior. These gaps make the description only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds semantic value by mapping group_id to group chats and users to single chats, clarifying which parameter to use in which scenario—information not explicitly stated in the schema itself (though implied by field descriptions). This extra guidance elevates the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '以机器人身份向群聊或单聊发送消息' (send messages as a bot to group chats or single chats). It identifies the specific verb (send), resource (chat via bot), and scope (group vs. single), distinguishing it from sibling tools like webhook or general message send.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use group_id vs. users ('发群聊用 group_id；发单聊用 users'), giving clear usage direction. However, it does not contrast with alternative tools (e.g., send_by_webhook) or mention when not to use this tool, only a mild gap from a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns form fields, status, and workflow, which is meaningful behavioral information for a read-only detail retrieval tool. It does not mention permissions or response format, but that is not a critical gap for a simple view operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a parenthetical enumeration of key detail categories. It contains zero redundant words and is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter read tool with no output schema, the description adequately covers both the tool's purpose and the expected return content (form fields, status, workflow). The schema covers the parameter, and the description confirms the return value, making it complete enough for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (instance_id) is already fully described in the schema as '审批流程实例 ID'. The tool description adds no additional parameter semantics, so the baseline of 3 for 100% schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "查看审批单详情（表单字段、状态、流程）" clearly states the action (view) and resource (approval details), and enumerates the specific content dimensions (form fields, status, workflow). This distinguishes it from sibling approval tools that list, approve, or reject.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need the details of a specific approval instance, but it does not explicitly state when to use this tool versus alternatives like list/approve/reject tools. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the scope (group chat only) and that it fetches recent messages, but does not mention return format, ordering, pagination behavior, or any access prerequisites. For a read-only fetch tool, the lack of destructive behavior is implied but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that leads with the verb and resource, then adds the critical scope limitation. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with fully documented parameters, the description adequately conveys purpose and scope. There is no output schema, but the description's 'recent message records' plus parameter definitions give a workable picture, though it could be more complete by noting return value shape or ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (group_id and limit). The description adds no new meaning beyond the schema: group_id is already described as '群聊 openConversationId（必填）' and limit as '消息数量，默认 50'. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches recent message records from a specified group chat. It differentiates itself from single-chat messaging by explicitly saying group chat only and directing users to 'list-direct' for single chats, which 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (group chats) and when not to (single chats, pointing to list-direct). This gives clear usage guidance relative to alternatives, even though it doesn't contrast with other message-list siblings.
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:

[![dws-cli-mcp MCP server](https://glama.ai/mcp/servers/yingcaihuang/dws-cli-mcp/badges/card.svg)](https://glama.ai/mcp/servers/yingcaihuang/dws-cli-mcp)

Score Badge

Copy to your README.md:

[![dws-cli-mcp MCP server](https://glama.ai/mcp/servers/yingcaihuang/dws-cli-mcp/badges/score.svg)](https://glama.ai/mcp/servers/yingcaihuang/dws-cli-mcp)

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/yingcaihuang/dws-cli-mcp'

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