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 transparency. It only restates the action without disclosing side effects, authentication requirements, idempotency, or how the reaction is displayed to others. This 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.

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

The description is a single short sentence that is front-loaded with the action and contains no unnecessary elaboration. The '[Official API]' prefix is minor metadata but does not detract from the overall conciseness.

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

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

The tool is simple and all parameters are documented in the schema, but the description gives no behavioral context or return value expectations. For a mutation tool with no annotations, this feels under-specified, although the low complexity keeps it from being severely deficient.

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

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

The input schema fully describes both parameters (message_id and emoji_type) with examples, achieving 100% schema coverage. The description adds no additional parameter context, so the baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'Add' and clearly identifies the resource 'emoji reaction to a message'. It is unambiguous and distinguishes the tool from sibling tools like delete_reaction, which performs the opposite operation.

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

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

The description implies when to use the tool ('when you want to add a reaction') but provides no explicit guidance on alternatives, prerequisites, or exclusions. It does not mention related tools like delete_reaction or forward_message, leaving usage context largely implied.

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

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

With no annotations provided, the description carries the full burden and delivers important behavioral details: sequential dispatch with a small anti-rate-limit delay, per-target success/error reporting, and identity behavior (cookie user unless target.via=bot). It doesn't cover permissions or failure continuation, but the core behavioral traits are well disclosed.

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

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

The description is three concise sentences, front-loaded with the main action, and every sentence adds value—no filler or redundancy. It is well-structured and easy to parse.

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

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

The description covers the use case, execution model, identity routing, error reporting, and rate-limit mitigation. While the return format and failure continuation are not explicitly described, the tool's complexity is largely addressed by the detailed input schema and the description's behavioral disclosures.

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

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

Schema coverage is 100% for both targets and delay_ms, so the baseline is 3. The description adds extra meaning by explaining the anti-rate-limit purpose of delay_ms and clarifying the via=bot routing for targets, going beyond the schema's basic parameter descriptions.

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

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

Description clearly states 'Send the same or different content to multiple targets in one call' and explicitly mentions 'Use for broadcast / fan-out scenarios,' making the purpose and scope unambiguous. It also distinguishes this from single-target sibling tools like send_to_user and send_to_group.

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

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

The description says 'Use for broadcast / fan-out scenarios,' providing a clear when-to-use signal. It doesn't explicitly name alternatives or when-not scenarios, but the contrast with single-target send siblings is obvious. This earns a 4 for clear context without exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose that the tool can both complete and uncomplete tasks, and that it delegates to update_task, but it doesn't mention permissions, side effects, or return values.

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

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

The description is two sentences, front-loaded with the core purpose and wastes no words. The version note is brief and adds context without bloating.

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

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

This is a simple 2-parameter mutation tool with complete schema coverage. The description clearly states the behavior and relationship to update_task, but since there's no output schema, it could have mentioned the return value for full completeness. Still, the overall context is adequate.

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

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

Schema coverage is 100%, so the parameters are already fully documented. The description adds no parameter-specific meaning beyond the schema, but the schema's descriptions are sufficient.

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

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

Description states 'Mark a task complete (or uncomplete it)' with a clear verb and resource. It explicitly notes it is a 'Convenience wrapper around update_task with completed_at', distinguishing it from sibling tools like update_task.

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

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

The description explains when to use this tool by framing it as a convenience wrapper around update_task, implying it's for quick completion/uncompletion. It provides clear context but lacks explicit exclusions or named alternatives beyond the implied update_task.

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

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

No annotations are provided, so the description carries the burden. It discloses key behavioral traits: it is a deep copy (not a move), and 'Underlying resource is duplicated' clearly indicates the original remains. However, it omits return behavior, permissions, and edge cases.

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

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

The description is one concise sentence plus one clarifying sentence. It is front-loaded with the core action and resource, and every sentence adds value without redundancy.

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

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

The description adequately explains the core operation and the schema covers all parameters, but with no output schema or annotations, it does not state what the API returns (e.g., new node token) or mention error/edge cases. Adequate for basic invocation but incomplete.

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

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

All five parameters are fully described in the input schema (100% coverage), so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides.

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

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

The description clearly identifies the action ('Deep-copy'), the resource ('Wiki node'), and the destination ('different location (and optionally a different space)'). The phrase 'Underlying resource is duplicated' distinguishes it from sibling move_wiki_node.

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

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

The description implies usage for duplicating a node to another location/space, but does not explicitly state when to use it instead of move_wiki_node or other wiki operations. No exclusions or alternative tool references are provided.

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

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

With no annotations, the description carries the full burden. It discloses scope requirements, permission level, identity constraint, and time field formats. However, it omits other behavioral traits like whether notifications are sent (the need_notification parameter suggests it but doesn't state explicitly), idempotency, error scenarios, or rate limits. Moderate transparency.

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

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

The description is relatively concise and front-loaded with purpose, then prerequisites, then time details. It could be slightly more terse (e.g., 'Official API + UAT' might be redundant), but overall it's well-structured and each section adds value.

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

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

Despite having 12 parameters and no output schema, the description does not explain the return value (e.g., the created event's ID or details) or cover error handling. For a creation tool, this is a significant gap. The description misses completeness by not addressing what the agent should expect after invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the two time object formats (timestamp vs. date) and the scope/permission context. This goes beyond the schema's parameter descriptions, which already cover most but not all nuances.

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

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

The description clearly states 'Create a new calendar event.' It uses a specific verb ('Create') and resource ('calendar event'), effectively distinguishing it from sibling tools like update_calendar_event or respond_calendar_event.

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

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

The description provides prerequisites (scope, permissions, UAT-first identity) and time field formatting, but it does not offer guidance on when to use this tool compared to alternatives, such as when to use respond_calendar_event for responding to events. The prerequisites are helpful but lack comparative usage context.

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

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

With no annotations, the description carries the burden. It discloses the two-step behavior: creating the doc in drive first, then attaching it as a Wiki node. This adds value beyond the name/schema, though it does not cover failure modes or permission requirements.

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

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

Two sentences, front-loaded with the core purpose, then the optional wiki context. Every sentence carries meaningful information with no redundancy or filler.

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

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

Given the moderate complexity (4 params, no output schema) and rich schema descriptions, the description covers the essential nuances of Wiki placement. It doesn't need to explain return values. It lacks explicit alternative guidance, but overall it's sufficiently complete for an agent to invoke correctly.

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

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 restates the wiki placement logic already present in the schema descriptions (folder_id ignored when wiki_space_id set, wiki_parent_node_token defaults to root), adding no new parameter-level meaning beyond the schema.

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

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

Description clearly states specific action: 'Create a new Feishu document.' It also distinguishes from siblings like create_folder or create_wiki_node by explaining the optional Wiki space placement and the drive-to-Wiki attachment flow, which is unique to this tool.

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

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

Provides clear context: you can place the doc directly under a Wiki space using wiki_space_id and optionally nest it with wiki_parent_node_token. However, it doesn't explicitly mention when to use this over alternatives (e.g., create_wiki_node), but the context is sufficiently clear.

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

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

With no annotations provided, the description must fully disclose behavioral traits, but it only states the basic create effect. It omits permissions, duplicate-name behavior, parent_token impact, and response format—critical gaps for a create operation.

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

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

The description is a single concise sentence that front-loads the verb and resource. 'Official API' adds minor context without bloating the text.

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

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

For a simple create tool with no output schema, the description is too sparse. It fails to mention what the caller receives (e.g., folder ID/token) and does not clarify parent_token semantics or error cases, leaving important operational gaps.

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

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

Schema description coverage is 100%, with 'name' and 'parent_token' both described. The tool description adds no extra parameter-level meaning, so the baseline of 3 applies.

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

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

The description clearly states the tool's action ('Create a new folder') and resource ('in Drive'), making its purpose unambiguous. It distinguishes itself from siblings like upload_file or manage_drive_file, though it does not explicitly name alternatives.

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

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 siblings such as manage_drive_file or upload_drive_file. It implicitly suggests folder creation but lacks prerequisites, 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.

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

There are no annotations, so the description carries the full burden for behavioral disclosure. It only states the creation action and the ability to add initial members, but does not disclose side effects, permission requirements, whether the bot is automatically added, or any return values. 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.

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

The description is two short sentences with no redundancy. It front-loads the core purpose and includes a useful optional capability. Every word earns its place.

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

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

Given it is a simple creation tool with three parameters and no output schema, the description covers the basic action but omits usage context, behavioral details, and return expectations. It is minimally viable but leaves clear gaps in guidance and behavioral transparency.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds a minor hint about 'initial members' which maps to the user_ids parameter, but does not provide new meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the action: 'Create a new group chat (as bot).' It uses a specific verb and resource, and the addition 'Can add initial members' further clarifies scope. It distinguishes itself from siblings like create_p2p_chat by explicitly targeting group chats.

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

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

No explicit guidance is given on when to use this tool vs. alternatives such as create_p2p_chat or send_to_group. The 'as bot' phrasing implicitly indicates bot context, but there is no mention of prerequisites, exclusions, or when another tool would be more appropriate.

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

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

No annotations are provided, so the description carries full responsibility. It discloses the auto-wrapping of content_text into the Feishu block format, the requirement for source_title and source_url, and the override behavior when content is passed. It also mentions the API version and UAT environment. It does not discuss permissions, return values, or failure modes, but for a create operation with no annotations, this is adequate.

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

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

The description is only three sentences, front-loaded with the primary purpose, then immediately provides key usage constraints and the content option. Every sentence adds essential information without repetition or filler.

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

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

Given the tool's complexity (11 parameters, nested content object, no output schema), the description adequately orients the agent: it explains the core Feishu requirement, the simple default path, and the advanced override path. It doesn't explicitly state what the tool returns on success, but the purpose and action are unambiguous from the name and description, making this a minor gap.

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

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

Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds meaningful value beyond the schema by explaining the relationship between content_text and content: content_text is auto-wrapped into a single-paragraph block, while content can be passed directly for rich formatting. This helps the agent choose the correct parameter based on the desired output.

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

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

The description clearly states 'Add a progress note to an OKR objective or key result', using a specific verb and resource. It distinguishes the tool from sibling tools like list_okr_progress_records and delete_okr_progress_record by implying it is the creation operation, and adds context about Feishu's content requirements.

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

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

The description gives clear context on when to use the tool (adding progress notes) and provides guidance on choosing between simple content_text and richer content. It mentions Feishu's mandatory fields, implicitly steering the user to provide source_title and source_url. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a full 5.

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

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 idempotent behavior ('Create or get') and the return type ('numeric chat_id'), which adds useful context. However, it does not mention potential side effects, permissions, or error conditions (e.g., invalid user_id). This is a minimal but adequate disclosure for a simple tool.

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

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

The description is a single sentence with 17 words, front-loaded with the core action and result. There is no redundant information or filler. The '[User Identity]' prefix is a minor label but does not detract from conciseness.

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

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

For a tool with one parameter and no output schema, the description is reasonably complete: it states the action (create/get), the resource (P2P chat), and the return value. It does not explain error handling or what to do with the chat_id, but these are less critical given the simplicity. The schema and sibling tools provide enough surrounding context for correct invocation.

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

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

Schema description coverage is 100% (user_id has a description), so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides. It correctly implies the parameter identifies the target user, but the schema already states 'Target user ID from search_contacts'.

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

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

The description clearly states 'Create or get a P2P (direct message) chat' with a specific verb and resource, and it explicitly mentions the return value ('Returns numeric chat_id'). This distinguishes it from sibling tools like create_group (group chat) and send_to_user (sending messages), making its purpose unambiguous.

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

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

The description implies usage for direct messaging by saying 'P2P (direct message) chat', but it does not explicitly state when to use this tool vs alternatives like create_group or send_to_user. There is no mention of prerequisites (e.g., needing to search contacts first) or exclusions, so the guidance is only implied, not explicit.

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

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

No annotations are provided, so the description carries full responsibility. It only mentions required/optional parameters and a version tag; it does not disclose side effects, return values, authentication needs, or idempotency. This is notably thin 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.

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

The description is a single sentence that front-loads the core action and required parameter. The version bracket is minor noise but does not detract from overall efficiency.

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

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

With no output schema, no annotations, and nested object parameters, the description is under-specified. It does not describe what the tool returns, any default behaviors, or contextual prerequisites, making it incomplete for an agent to invoke confidently.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only a restatement that summary is required and others optional, which does not deepen understanding beyond what the schema already provides.

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

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

The description opens with 'Create a new task,' a specific verb+resource that clearly distinguishes this tool from sibling task operations like update_task, delete_task, and complete_task. The action is unambiguous.

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

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

The description implies usage for creating new tasks but provides no explicit when-to-use or when-not-to-use guidance. It does not reference alternatives, despite many sibling task tools being present.

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

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

With no annotations, the description takes on the disclosure burden. It usefully reveals that UAT-first means the resource is owned by the user, but it does not mention that the operation also creates the underlying resource, nor any permissions or side effects beyond ownership.

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

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

The description is compact and front-loaded with the core purpose, followed by a parameter note and ownership context. The phrase '[Official API]' is slightly redundant but does not waste much space.

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

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

The description covers the essential purpose and ownership context, and the schema handles parameter details. But it gives no guidance on return values, shortcut behavior, or how this tool relates to alternative doc/sheet creation tools, leaving an agent to make some inferences.

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

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

The schema covers 100% of parameters (all 6 with descriptions), so the baseline is 3. The description adds marginal value by restating obj_type's role, but does not provide additional detail on defaults or relationships beyond the schema.

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

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

The description clearly states the action ('Create a new Wiki node'), the target ('inside a space'), and adds the key parameter 'obj_type' that selects the underlying resource. This distinguishes it from sibling tools like update_wiki_node, delete_wiki_node, and list_wiki_nodes.

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

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

The UAT-first note gives valuable context about ownership and when this tool is appropriate, and 'inside a space' narrows the context. However, it does not explicitly contrast with alternative creation tools like create_doc or explain when to use shortcut vs origin node types.

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

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

No annotations provided, so description carries full burden. Adds scope but no details on permanence, notification, or side effects.

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

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

Very short but includes non-essential metadata ('[Official API + UAT, v1.3.7]'). Could be cleaner.

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

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

No output schema. Does not explain return values or important behavioral context like notification defaults or irreversibility.

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

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

Schema coverage is 100%, so baseline is 3. Description adds no parameter information beyond what is in the schema.

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

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

Clearly states the tool deletes a calendar event and specifies required scope. However, does not differentiate from siblings like 'create_calendar_event' or 'update_calendar_event'.

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

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

Provides no guidance on when to use this tool vs alternatives. Only states the action and scope requirement.

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

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

With no annotations provided, the description carries the transparency burden. It discloses the important behavioral constraint that only the bot's own messages can be deleted. It does not describe other traits like permanence, error behavior, or effects on replies, but for a simple delete operation, this level is adequate.

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

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

The description is a single, front-loaded sentence that communicates the action and the key constraint without any fluff. The '[Official API]' prefix is minor but does not detract. Every word earns its place.

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

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

This is a low-complexity tool with one well-documented parameter and no output schema. The description covers the essential operational constraint (own messages only), which is arguably the most critical information for correct invocation. It is sufficiently complete for the tool's simplicity, though it could mention success/failure behavior.

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

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

Schema description coverage is 100% (message_id is described as 'Message ID (om_xxx)'). The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's action ('Recall/delete a message') and specifies the resource ('message'). It also includes a key scoping constraint ('bot can only delete its own messages'), which distinguishes it from other message-related tools like update_message or forward_message.

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

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

The description provides a clear limitation ('bot can only delete its own messages'), which implicitly guides when the tool can be used. However, it does not explicitly mention when to use this tool vs alternatives (e.g., update_message for editing) or provide exclusions beyond the ownership constraint.

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

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

No annotations are provided, leaving the description to carry full behavioral disclosure. The description does not mention whether deletion is permanent, if there are permission requirements, or what happens to associated data. This is a notable gap for a delete operation.

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

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. The version bracket is brief and does not detract from clarity. No wasted words.

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

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

For a simple one-parameter delete tool, the description is adequate but not complete. Without annotations or an output schema, it omits important behavioral details such as irreversibility or expected response format, leaving the agent to infer these.

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

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

The input schema already documents progress_id with 100% coverage. The description adds a helpful pointer that the ID should come from list_okr_progress_records, but this is minimal extra value beyond the schema's basic field description.

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

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

The description clearly states the action (Delete), the resource (OKR progress record), and the key (progress_id). It also references the source for the ID (list_okr_progress_records), distinguishing it from create/list siblings.

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

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

The description provides clear context: the ID must come from list_okr_progress_records, implying the appropriate workflow. It does not explicitly exclude alternative sources or mention when not to use it, but the delete verb and ID reference make the usage context clear.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action itself and omits important traits such as whether users can only remove their own reactions, idempotency, or failure behavior when the reaction does not exist.

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

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

The description is a single, concise sentence that is front-loaded with the action and object. The '[Official API]' prefix is minor noise but does not detract significantly.

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

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

For a simple delete operation, the description is minimally adequate but lacks critical context such as ownership requirements (whether the user must have added the reaction), behavior when the reaction is not found, and there is no output schema or annotations to fill these gaps.

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

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

The input schema provides descriptions for both parameters, achieving 100% coverage. The description adds no additional parameter semantics beyond what the schema already provides; the note 'from add_reaction response' is included in the schema, not the description.

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

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

The description uses a specific verb 'Remove' and clearly identifies the resource: 'an emoji reaction from a message'. This distinguishes it from sibling tools like 'add_reaction' and 'delete_message', making the tool's purpose unambiguous.

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

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

No explicit guidance is provided on when to use this tool versus alternatives, nor are prerequisites or permission requirements mentioned. The context is implied by the tool's name and sibling set, but not stated.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It states 'permanently' which indicates irreversibility, a key behavioral trait. However, it does not mention auth requirements, side effects on related data, or what happens to associated task members/progress.

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

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

The description is a single concise sentence that is front-loaded with the action 'Permanently delete a task'. The prefix '[Official API + UAT, v1.3.7]' is low-value noise but does not significantly detract from clarity.

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

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

For a simple 1-parameter destructive operation, the description covers the core action but lacks context on how to retrieve the task GUID, what 'permanently' implies for related data, and any prerequisites or side effects. It is minimally adequate but leaves gaps.

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

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

Schema coverage is 100% with a single parameter task_guid described as 'Task GUID'. The description adds no extra meaning beyond the schema, such as how to obtain the GUID or its format, so the baseline of 3 applies.

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

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

The description clearly states 'Permanently delete a task' with a specific verb (delete) and resource (task). The use of 'permanently' adds important specificity and distinguishes it from related actions like complete_task or update_task.

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

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

The description implies usage for deleting a task but provides no explicit guidance on when to use this tool versus alternatives such as complete_task (non-destructive status change) or other delete tools. It lacks any exclusions or alternative mentions.

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

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

With no annotations, the description carries full burden. It discloses the critical behavior that the underlying drive resource is not deleted, and explains the raw REST implementation due to missing SDK typing. It does not mention whether child nodes are recursively deleted or handle permission failures, which are relevant for a delete operation.

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

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

Four sentences, front-loaded with the primary purpose. The technical note about UAT-first/bot fallback is an implementation detail that may not be needed for all users, but it's compact and valuable for an agent. Slightly verbose but well-structured.

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

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

The description covers the most critical nuance (pointer vs resource deletion) and the necessary follow-up action, but lacks information about recursive deletion of children nodes, error behavior, or auth requirements. Given the moderate complexity and no output schema, it is not fully complete.

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

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

Both parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds the endpoint template but does not provide additional syntax, formats, or constraints beyond the schema.

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

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

The description explicitly states 'Delete a Wiki node' with the HTTP DELETE endpoint, clearly distinguishing it from sibling wiki operations like create/update/move/copy. It also clarifies the pointer semantics, making it clear that this tool only removes the wiki node, not the underlying drive resource.

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

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

It provides clear context for the deletion operation and references `manage_drive_file` as a follow-up for deleting the actual resource, and suggests `get_wiki_node` to retrieve needed tokens. However, it does not explicitly state alternative scenarios (e.g., when to prefer managing the drive file directly), so it's clear but not exhaustive.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does reveal an important constraint: payloads > 2 MiB MUST pass save_path. However, it does not disclose return format, authentication details (beyond the ambiguous 'UAT-first'), or what happens if save_path is omitted for large files, leaving gaps.

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

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

The description is concise and front-loaded with the purpose. It is split into two short paragraphs, with the size cap as a separate note. However, the phrase 'UAT-first' is unclear and may confuse agents, slightly reducing effectiveness.

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

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

For a tool with 3 params and no output schema, the description covers the essential usage and the critical size cap. It does not explain the return format or what exactly the model receives, though 'so the model can see it' implies visual access. Given the absence of an output schema, more detail on the response would improve completeness.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds extra meaning by explaining that image_token comes from get_doc_blocks (block.image.token) and that doc_token scopes the lookup. It also reiterates the save_path requirement for large payloads, reinforcing the schema's constraint.

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

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

The description clearly states the action ('Download an image embedded in a docx document') with a specific verb and resource. It distinguishes itself from sibling tools like download_message_resource by focusing on docx embedded images, using language like 'so the model can see it.'

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

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

Provides explicit guidance on how to use the tool: pass the image_token from get_doc_blocks, and optionally the doc/wiki/URL token to scope the lookup. This implies the workflow and conditions for use, though it does not explicitly mention when not to use it or name alternatives beyond the implicit context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fully explains the response format for both images and files, the size limits and API constraints, the save_path mechanism, and the merge_forward id handling. This is rich, specific behavioral context beyond what annotations would typically provide.

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

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

The description is well-structured with clear sections, uses bold headers for emphasis, and every sentence adds necessary information. It covers complex behavior in a compact, scannable format without fluff.

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

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

For a tool with no output schema and no annotations, this description is remarkably complete. It addresses output format, size constraints, file vs image distinction, and a non-obvious merge_forward edge case. It leaves no critical gap for an agent to invoke the tool correctly.

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

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

Schema coverage is 100%, but the description adds valuable semantic context: it explains the 2 MiB threshold for save_path, the parentMessageId requirement for merge_forward children, and why the size cap exists. This goes beyond the schema's parameter descriptions by linking parameters to real-world constraints and edge cases.

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

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

The description clearly states the tool downloads an image or file attached to a message so the model can see or store it. It distinguishes itself from related tools like download_doc_image and upload_file by specifying the resource type (message attachments) and the dual output modes (image vs file).

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

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

The description provides clear context on when to use the tool and critical operational guidance (size cap threshold, save_path requirement, merge_forward special case). It does not explicitly compare to sibling tools or state when not to use it, but it effectively implies this is the consolidated replacement for download_image and download_file.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention side effects (e.g., that a copy of the message is created in the target chat), any required permissions, or what the API returns. This lack of transparency could lead an agent to make incorrect assumptions about the tool's behavior.

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

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

The description is two sentences, front-loaded with the core action ('Forward a message to another chat or user'), followed by a concise but necessary clarification about receive_id types. Every word earns its place with no waste.

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

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

The tool has 3 parameters, no output schema, and no annotations. The description covers the parameter semantics adequately but omits important contextual details such as return value, side effects, and prerequisites. For a mutation-like operation (forwarding a message), this leaves some gaps, making it minimally complete but not thorough.

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

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

Schema description coverage is 100%, so the baseline is 3. The description largely duplicates the schema's parameter explanations (e.g., receive_id formats and receive_id_type default), adding no new semantic meaning beyond what the schema already provides. Therefore, it meets but does not exceed the baseline.

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

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

The description clearly states the verb 'Forward' and the resource 'a message to another chat or user', making the action specific and distinct from sibling tools like send_message_as_bot or reply_message. It accurately conveys the core functionality without ambiguity.

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

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

The description provides clear context on when to use the tool: to forward an existing message to another chat or user. It does not explicitly mention alternatives or exclusions, but the verb 'forward' implies a distinct operation from sending or replying, so the usage context is adequately clear.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly identifies the output behavior by listing the returned fields (summary, description, start/end, attendees, location, attachments, meeting link), indicating a read-only operation. It does not mention permissions or rate limits, but the get verb and output details provide sufficient transparency for a simple read tool.

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

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

The description is a single, well-structured sentence that front-loads the purpose and lists key output fields. Every phrase 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.

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

Given the tool's simplicity (2 parameters, no output schema), the description is complete. It states what the tool does, what fields it returns, and the schema covers the parameter details. The absence of an output schema is compensated by the field list in the description.

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

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

The input schema has 100% coverage, with both parameters already described ('Event ID from list_calendar_events' and 'Calendar ID'). The description adds no additional parameter meaning, but per the rubric, high schema coverage warrants a baseline of 3.

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

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

The description clearly states the tool's purpose: 'Get full details of a single calendar event' and enumerates the specific fields returned. This distinguishes it from sibling tools like list_calendar_events, create_calendar_event, or delete_calendar_event, which have different actions.

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

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

The description implies usage when you need full details of one event, but it does not explicitly mention alternatives or exclusion cases. Given the many calendar-related siblings, explicit guidance would help, but the phrase 'single calendar event' offers some implied context.

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

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

With no annotations, the description carries the burden for behavioral disclosure. It adds context about dual ID support and a user identity fallback, and lists the returned fields, implying a read-only operation. However, it does not mention permissions, error conditions, or rate limits, which are relevant for a tool with no structured safety signals.

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

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

The description is a single, information-dense sentence. It front-loads the tool's purpose, lists the specific data returned, and covers ID format constraints without any filler or redundancy.

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

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

For a low-complexity tool with one parameter and no output schema, the description adequately covers the return value (name, description, member count, owner) and input format. It lacks explicit error handling or alternative tool references, but these are not critical for such a straightforward getter, making it nearly complete.

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

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

The schema already thoroughly documents the only parameter (chat_id) with 'Chat ID (oc_xxx or numeric)'. The description repeats this support ('Supports both oc_xxx and numeric chat_id'), adding no new semantic detail. Since schema coverage is 100%, 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.

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 chat details: name, description, member count, owner.' It specifies the resource (chat) and the exact data returned, distinguishing it from sibling tools like list_chats or get_user_info. The mention of supporting both oc_xxx and numeric chat_id further clarifies the input scope.

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

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

The description implies usage: it is for retrieving metadata of a single chat, as opposed to listing chats or members. The '[Official API + User Identity fallback]' and 'Supports both oc_xxx and numeric chat_id' provide context about invocation modes, but no explicit when-to-use vs alternatives or exclusions are given.

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

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

With no annotations provided, the description carries full burden but only states what the tool does. It does not disclose behavioral traits like read-only nature, permissions, or error handling.

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

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

Two concise sentences that are front-loaded, no unnecessary words. Perfectly structured for quick understanding.

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

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

Given a simple tool with one parameter and no output schema, the description adequately explains the purpose and return types. Missing behavioral details, but largely complete for its simplicity.

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

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

Schema coverage is 100% with a clear parameter description. The description does not add significant meaning beyond the schema, though it contextualizes the output.

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

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

The description clearly states the tool retrieves a structured block tree of a document, specifying it returns block types, content, and hierarchy. It distinguishes itself from sibling tools like read_doc by focusing on structural analysis.

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

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

The description implies use for precise document analysis, but does not explicitly contrast with siblings like read_doc or read_doc_markdown. Somewhat clear but lacks explicit when-to-use guidance.

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

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 discloses the read-only nature via 'Query' and mentions the required OAuth scope, which is useful. But it does not describe return format, error behavior, or how free/busy results are structured, so it only partially compensates for missing annotations.

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

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

The description is two sentences, front-loaded with the primary purpose. Every word earns its place—purpose, usage hint, and auth requirement are all included without fluff.

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

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

This is a moderately simple query tool with no output schema and no annotations. The description covers the 'why' and 'when' but not the 'what returns'—the agent does not know the response structure. For a query tool, this is a moderate gap, but the schema covers inputs well, so the description is minimally adequate.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra detail beyond the schema; it only summarizes the overall purpose ('one or more users in a time range') which is already evident from required params. It does not clarify formats or semantics beyond the schema.

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

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

The description clearly states the tool's function: 'Query freebusy windows for one or more users in a time range.' The verb 'Query' plus the specific resource 'freebusy windows' distinguishes it from sibling calendar tools like list_calendar_events or get_calendar_event.

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

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

Provides clear context with 'Use to find a meeting slot,' which tells the agent when to apply this tool. It also mentions the required permission scope. However, it does not explicitly state when not to use it or suggest alternative tools, stopping short of a 5.

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

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

With no annotations provided, the description must carry full behavioral transparency. It does disclose that the tool refreshes the session, which is an important side effect beyond merely checking status. However, it does not explain what happens on invalid sessions, whether credentials are re-verified, or any rate limits, leaving gaps.

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

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

The description is two succinct sentences that front-load the primary action. Every word earns its place, and no irrelevant details are included. It is an example of efficient, well-structured writing.

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

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

Despite the tool's simplicity, the description leaves out critical details about the tool's output. There is no output schema, and the description does not state what the agent will receive (e.g., a boolean, status object, or updated session cookie). Additionally, no usage context is provided, so the description is not fully complete for an agent to confidently consume the result.

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

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

The tool has zero parameters, so the schema trivially covers all possible inputs. The description adds no parameter information, but none is needed. Baseline 4 is appropriate given the lack of parameters.

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

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

The description clearly identifies the tool as a session/credential status checker with a specific verb 'Check' and a distinct resource. The additional refresh action is disclosed, which differentiates it from the listed sibling tools that focus on content operations. Though 'app credentials status' is slightly vague, the tool's purpose is unambiguous.

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

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

The description provides no guidance on when to invoke this tool, such as before other authenticated operations or as a health check. No alternatives are mentioned, nor any exclusions. This is a minimal description that does not help the agent decide between this and any other tool.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It does this well by explaining internal storage (~/.feishu-user-plugin/events.jsonl), the global cursor, exactly-once delivery across MCP processes, and default profile filtering. It does not mention whether draining consumes/deletes events or the output format, but the disclosed traits are substantial and useful.

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

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

The description is compact and front-loaded with the core action and resource. The version-history detail adds behavioral context and is not fluff, though it could be considered slightly verbose for a tool description. Overall, it is well-structured and efficient.

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

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

For a 7-parameter tool with no annotations and no output schema, the description is incomplete. It covers event source, storage, and profile filtering, but leaves six parameter meanings and the return/consumption behavior unexplained. This is a significant gap for an event-draining tool that likely requires event_type, max_events, and since_seconds to be used correctly.

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

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

Only the 'profile' parameter receives meaningful description in the text, while the remaining six parameters (peek, chat_id, event_type, event_types, max_events, since_seconds) have no schema description (14% coverage) and no additional explanation. The description fails to compensate for the undocumented parameters.

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

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

The description uses the specific verb 'Drain' and identifies a precise resource: 'machine-level shared event log.' It distinguishes itself from sibling chat/message tools by describing a real-time event stream with exactly-once delivery, and even mentions version-specific behavior.

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

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

The description implies usage when one needs to consume real-time events, and it gives concrete guidance about profile filtering ('Default = current active... pass profile="*"'). However, it does not explicitly state when to use this tool versus alternatives like read_messages or search_messages, nor does it provide exclusion criteria.

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

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

With no annotations provided, the description must disclose behavioral traits. It indicates a read operation via 'fetch' but does not mention auth requirements, rate limits, pagination, or that it is read-only/safe. The extra prefix '[Official API + UAT]' adds no 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.

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

The description is a single, concise sentence that front-loads the primary action and scope. The '[Official API + UAT]' prefix is extraneous and reduces clarity slightly, but overall it is efficient and readable.

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

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

The description lists key response aspects (objectives, key results, progress, alignments) but lacks guidance on prerequisites (e.g., obtaining IDs) or alternatives. Given the absence of an output schema, it could be more complete but covers the tool's core purpose adequately.

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

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

The input schema has 100% coverage with descriptions for all three parameters (okr_ids, lang, user_id_type). The description itself adds little beyond mentioning 'batch' and listing response fields, so it meets the baseline but does not enhance parameter understanding.

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

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

The description clearly states the tool fetches full OKR details by IDs, using the specific verb 'fetch' and resource 'OKR details'. It distinguishes from sibling tools like list_user_okrs by emphasizing batch retrieval by explicit IDs.

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

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

The phrase 'by OKR IDs' implies the need to first obtain IDs (likely from list_user_okrs), providing an implicit usage condition. However, it does not explicitly mention alternatives or when not to use this tool, so guidance is only implied, not explicit.

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

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

With no annotations provided, the description must carry the burden of behavioral disclosure. The verb 'Get' strongly implies a read-only operation with no side effects, but the description does not explicitly confirm read-only status or mention any prerequisites, permissions, or response characteristics. This is acceptable for a simple read 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.

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

The description is a single sentence, front-loaded with the core purpose. The version prefix '[Official API + UAT, v1.3.7]' is unnecessary but does not detract. Every part earns its place, and it is appropriately concise.

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

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

For a simple one-parameter read tool, the description covers the core purpose and parameter source. There is no output schema, so the phrase 'full details' is somewhat vague but acceptable for a task object. Given the low complexity and rich sibling context, the description is sufficiently complete.

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

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

Schema coverage is 100% for the single parameter, but the description adds value beyond the schema by indicating where the GUID comes from (list_tasks, create_task, Feishu URL). This contextual hint helps the agent understand how to populate the parameter effectively.

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

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

The description 'Get full details of a single task by GUID' uses a specific verb (Get), names the resource (single task), and specifies the lookup method (by GUID). This clearly distinguishes from siblings like list_tasks (which lists multiple) and create_task/update_task (which mutate).

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

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

The description implies usage for retrieving one task after obtaining a GUID. The parameter description adds context by listing sources for the GUID (list_tasks, create_task, Feishu URL). It does not explicitly state when NOT to use it or name alternative tools, but the guidance is clear for a simple read lookup.

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

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

With no annotations provided, the description carries the full burden. 'Look up' implies a non-destructive read operation, but it does not disclose error handling, authentication requirements, or exact return behavior (e.g., format, what happens if user not found).

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

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

The description is a single, front-loaded sentence that states the core action and target resource without any filler. It is appropriately concise for a simple lookup tool.

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

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

Given the simple scope (lookup by ID) and full schema coverage, the description is mostly complete. However, with no output schema, it does not explain the return format beyond 'display name', nor does it address error conditions or dependent operations.

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

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

Schema descriptions cover 100% of parameters (user_id as 'User ID', chat_id as 'Chat context (optional)'). The tool description adds no additional information about parameter usage, formats, or dependencies, so baseline 3 applies.

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

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

The description uses a specific verb 'look up' and resource 'display name by user ID', clearly stating what the tool does. It distinguishes itself from sibling tools like search_contacts or list_profiles by focusing on a lookup by user ID.

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

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

The description provides no guidance on when to use this tool versus alternatives such as search_contacts or list_profiles. It neither mentions context nor exclusions, leaving the agent to infer usage from the simple verb.

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

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

With no annotations provided, the description carries the full burden. It discloses the fallback mechanism ('tries the wiki endpoint first and falls back to a synthesized node-shape') and the exact return fields. The word 'Resolve' and 'Returns' imply a read-only operation, and the tool is described as enabling read/write via other tools, not mutating directly. This is substantive disclosure, though it stops short of stating auth requirements or explicit non-mutation.

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

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

The description is three sentences, each earning its place: purpose, output/usage rationale, and input variants/fallback. It is front-loaded with the core action and avoids redundancy or fluff.

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

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

For a single-parameter resolver with no output schema, the description covers accepted inputs, return fields, and the fallback behavior. It doesn't detail the exact JSON structure or error handling, but the tool's simplicity and the given information make it reasonably complete. It fits well among sibling wiki tools.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context beyond the schema by explaining that obj_token can come from search_wiki, mentioning the 'synthesized node-shape' fallback, and clarifying the resolution flow. This provides practical meaning to the parameter beyond its type definition.

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

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

The description clearly states a specific verb ('Resolve') and resource ('Wiki node token') and explains what it returns ('obj_type + obj_token + space_id'). This distinguishes it from sibling tools like list_wiki_nodes or search_wiki, which list/search rather than resolve a single token.

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

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

The description indicates when to use this tool: to resolve a wiki token into an underlying object so you can 'read/write the real resource via the usual docx / bitable tools.' It also notes accepted input types (bare wiki token, obj_token, full URL) and the fallback behavior, providing clear operational context. It doesn't explicitly name alternatives but the intended use case is evident.

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

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

With no annotations, the description carries the full burden. It clarifies the time format (Unix seconds) and gives an example range, but does not disclose pagination behavior, sorting, or whether all events are returned when no time range is specified. The read-only nature is implied but not explicitly stated.

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

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

The description is two sentences long, front-loaded with purpose, and every sentence adds essential information. The typical usage example is concise and highly informative, with no wasted words.

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

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

For a list tool with 6 parameters and no output schema, the description covers the core workflow and time range usage, which is sufficient for most cases. However, it does not elaborate on pagination behavior or response structure, leaving some gaps for comprehensive understanding.

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

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

The schema already covers all parameter descriptions, so the baseline is 3. The description adds value by explaining how calendar_id is discovered (via list_calendars) and by providing a concrete example time range ([now, now+7d]), which helps agents construct valid parameter values.

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

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

The description uses a specific verb ('List') and resource ('events in a calendar') and clearly states the optional time range. It also provides a typical usage flow involving list_calendars, distinguishing it from singular event retrieval tools like get_calendar_event.

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

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

The description gives explicit workflow context: first list_calendars to obtain calendar_id, then use this tool with a time range. It does not explicitly state when not to use alternatives like get_calendar_event, but the typical usage strongly implies the appropriate context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals that app identity only sees invited calendars and that the OAuth scope is required—auth and visibility constraints that go beyond the raw schema. However, it does not mention pagination behavior or return format, leaving some gaps.

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

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

The description is two short sentences. The first is front-loaded with the core purpose, and the second adds essential requirements and limitations. Every word earns its place with no redundancy or filler.

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

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 should compensate by explaining return values and behavioral nuances. It provides important auth context but omits the structure of the returned calendar list and does not elaborate on how sync_token affects results beyond the schema's terse 'Incremental sync token (optional)'. This leaves an agent partially unprepared to consume the output.

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

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

The input schema has 100% description coverage for all three parameters, including details like page_size minimum (50) and the sync_token purpose. The description itself adds no parameter-specific meaning, so the baseline score of 3 applies as the schema does the heavy lifting.

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

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

The description clearly states the action ('List the current user's calendars') and enumerates the exact resource types (primary + shared + subscribed). This distinguishes it from sibling tools like 'list_calendar_events' and 'get_calendar_event' by focusing on the calendar list rather than events or a single calendar.

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

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

The description provides clear context for when the tool is applicable: it requires a User Access Token (UAT) and the `calendar:calendar:readonly` scope, and notes that app identity only sees calendars it was explicitly invited to. This implies usage prerequisites and limitations, though it does not explicitly name alternative tools or state when not to use it.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It specifies the return fields ('Returns chat_id, name, type') but does not mention pagination behavior, rate limits, or whether the operation is read-only (though 'List' implies it). The absence of any side-effect disclosure is acceptable for a read operation, but more detail would improve transparency.

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

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

The description is a single concise sentence that front-loads the purpose and includes the key return fields. No unnecessary words or repetition. It earns a perfect score for efficiency.

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

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

For a simple list tool with two optional parameters and no output schema, the description covers the purpose and return format adequately. It lacks usage alternatives and explicit read-only behavior, but the low complexity and good schema coverage make it nearly complete. Slightly below get_calls because it omits alternative tool guidance.

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

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

Schema coverage is 100%, with page_size and page_token described directly in the input schema. The description adds nothing beyond the schema's parameter explanations, so it stays at the baseline of 3. It does not clarify how pagination works or how page_token is obtained, but the schema already provides defaults and limits.

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

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

The description clearly states the tool's function: 'List all chats the bot has joined.' This is a specific verb+resource that distinguishes it from sibling tools like list_user_chats or get_chat_info, which have different scopes (user chats vs. bot's chats).

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

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

No guidance is provided about when to use this tool versus alternatives. It does not mention that this lists only chats the bot is a member of (though that's in the purpose) or that other tools might be more appropriate for filtering or searching. The agent is left to infer usage context from the sibling list.

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

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 does not mention important traits such as recursion depth, pagination, file types included, or permission requirements, leaving significant ambiguity.

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

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

The description is very concise with a single sentence that front-loads the core purpose. No superfluous text, though it could benefit from slightly more detail without becoming verbose.

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

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

With no output schema, the description should explain return values (e.g., list of file objects with properties). It does not, leaving the agent without crucial context for handling results.

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

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

The input schema coverage is 100% and includes a clear description for folder_token. The description adds no additional meaning beyond the schema, so baseline score applies.

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

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

The description clearly states the verb 'List' and resource 'files' within a specific context 'Drive folder', distinguishing it from other list tools like list_calendar_events or list_tasks.

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

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

No guidance on when to use this tool versus alternatives. With many sibling list tools, it fails to specify context like filtering or prerequisites (e.g., whether folder_token is required or how to obtain it).

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It only states the purpose and includes '[Official API]' but does not mention pagination behavior, return format, rate limits, or any safety implications. The term 'all members' could mislead since the schema includes page_size/page_token, implying paged results.

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

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

The description is a single sentence, starting with the action, and is free of unnecessary words. The '[Official API]' prefix adds minimal value but does not harm clarity. It is slightly under-specified but still compact.

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

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

While the schema covers parameters, there is no output schema and no annotations. The description does not explain what the response contains, how pagination works (despite the 'all' wording), or any operational context. For a simple list tool, this is a notable gap that could lead to incorrect expectations.

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

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

Schema description coverage is 100%, with clear descriptions for chat_id, page_size, and page_token. The description adds no extra semantic 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.

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

The description clearly states the action ('List'), the resource ('members'), and the scope ('in a group chat'). It is concise and unambiguous. However, it does not explicitly differentiate from sibling tools like manage_members or list_chats, so it stops short of a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where another tool (e.g., manage_members) would be more appropriate. The only implied usage is for retrieving group chat members, but no explicit direction is provided.

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

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

No annotations are provided, so the description carries the full burden. It implies read-only behavior via 'List' and reveals that the output contains period_ids. However, it does not describe pagination behavior or the full response structure. For a simple list tool, this is minimal but acceptable.

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

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

The description is two sentences, front-loaded with the core purpose and followed by a practical usage note. No redundant information. The '[Official API + UAT]' prefix is extraneous but does not detract from clarity.

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

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

This is a simple list tool with two optional pagination params and no output schema. The description gives purpose and usage, and hints at an output field (period_ids). It does not fully describe the response shape, but given the tool's simplicity, it is reasonably complete.

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

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

Schema description coverage is 100% for both page_size and page_token, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides, but no compensation is needed.

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

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

The description clearly states the tool lists OKR periods (quarters/years) defined in the tenant, using a specific verb and resource. It distinguishes from sibling tools like list_user_okrs by explicitly noting that period_ids from this tool are used to filter list_user_okrs.

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

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

The description provides explicit usage guidance: 'Use period_ids from this to filter list_user_okrs.' This tells the agent when and why to use this tool. However, it does not mention exclusions or other alternatives beyond that single use case.

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

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

With no annotations provided, the description carries the full burden and does exceptionally well. It openly explains the internal behavior: Feishu has no native list endpoint, so the tool calls get_okrs and walks objective_list / kr_list to extract IDs with target_id and target_type. It also discloses the limitation that full content retrieval requires an unwrapped API, providing valuable 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.

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

The description is compact and front-loaded, consisting of two dense sentences. Every part contributes: the version/app context, the exact listing purpose, the non-obvious implementation detail, and the follow-up limitation. No wasted words.

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

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

Given there is no output schema, the description adequately explains what the tool returns (progress_record IDs with target_id and target_type). It also notes the need for progressRecord.get for full content. However, it omits details like pagination, error behavior, or the response structure beyond the extracted fields, which would be useful for a tool with no output schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces that okr_id identifies the OKR and mentions user_id_type as a pass-through to get_okrs, but it adds little beyond the schema. It does not explain parameter nuances such as how user_id_type affects the internal call or possible constraints on okr_id.

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

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

The description uses a specific verb-resource pairing ('List progress records for an OKR') and clearly distinguishes this tool from siblings by explaining it extracts progress_record IDs via an internal get_okrs call. It uniquely addresses the lack of a native Feishu list endpoint, making its purpose unmistakable.

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

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

It provides clear context for when to use the tool: to list progress record IDs for an OKR. It also gives a follow-up alternative by noting that full record content requires progressRecord.get (not yet wrapped), which helps agents avoid assuming full content is returned. However, it does not explicitly contrast with sibling tools like create_okr_progress_record or delete_okr_progress_record.

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

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

With no annotations provided, the description carries the transparency burden. It discloses that the tool 'Marks the currently active profile' and references a specific storage location, adding context about its data source. However, it doesn't explicitly state whether the operation is read-only or has side effects, leaving slight ambiguity.

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

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

The description is concise but dense, conveying key info in a few sentences with clear structure. The version number and legacy fallback add value, though slightly verbose.

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

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

For a zero-parameter, no-output-schema tool, the description provides comprehensive context: what profiles are, where they live (with legacy fallback), and that it marks the active profile. It is fully adequate 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.

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 (100% coverage). The description adds meaningful context about profile attributes and storage, but there are no parameter details to document. Baseline 4 is appropriate.

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

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

The description uses a specific verb 'List all available identity profiles' and names the resource (identity profiles), clearly distinguishing it from sibling tools like switch_profile which changes the active profile. It also explains what each profile contains, reinforcing its scope.

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

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

The description implies the use case: enumerating available identity profiles and identifying the active one. It provides context about where profiles are stored (SSOT path and legacy fallback), but doesn't explicitly discuss alternatives or exclusions. Clear enough given the tool's simple role.

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

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

With no annotations, the description carries the full burden. It implies a read-only list operation via 'List', which is safe. However, it does not disclose pagination behavior, default page size, or any potential limits, which are relevant given page_size and page_token parameters.

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

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

The description is very concise, with the main purpose front-loaded. The prefix '[Official API + UAT, v1.3.7]' is extra clutter that does not aid the agent, slightly reducing the score from a perfect 5.

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

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

For a simple list tool with good schema coverage, the description covers the essential functionality: listing current user's tasks with filters. It could mention pagination or that it returns a list of tasks, but the schema already handles parameter details. The absence of an output schema means the description could clarify return format, but it's not a major gap.

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

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

The input schema already describes all four parameters with 100% coverage. The description only restates 'Filter by completion or type', which adds no new meaning beyond what the schema provides. It does not explain page_size or page_token behavior, 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.

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

The description clearly states 'List the current user's tasks' with a specific verb and resource. It also mentions filtering by completion or type, and the plural 'tasks' distinguishes it from sibling tools like get_task, create_task, etc.

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

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

The description gives clear context by specifying 'current user's tasks' and filter options, implying when to use it. However, it does not explicitly mention alternatives or when not to use it, such as pointing to get_task for a single task or complete_task for updates.

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

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

No annotations are provided, so the description carries the burden. It adds meaningful behavioral context: the tool only returns groups, excludes P2P chats, and requires OAuth setup. This goes beyond the schema and gives the agent insight into limitations and auth needs. However, it does not mention pagination behavior or return format, which are relevant but not critical for a simple list operation.

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

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

The description is two sentences, front-loaded with the main purpose, and every sentence adds value: scope, limitation, alternative, and prerequisite. There is no redundancy or filler.

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

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

For a simple list tool with 2 optional params and no output schema, the description covers the essential points: what it lists, its limitation, an alternative path, and a prerequisite. Slightly missing is what the returned data looks like (e.g., chat metadata vs. messages), but the name and context make this reasonable. Overall, it is sufficiently complete for an agent to use correctly.

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

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

The input schema provides 100% coverage with both 'page_size' and 'page_token' having descriptions. The tool description does not add additional parameter semantics beyond what the schema already documents, so the score matches the baseline for high schema coverage.

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

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

The description clearly states the tool's function: 'List group chats the user is in.' It uses a specific verb and resource, and explicitly distinguishes from P2P chats, which sets it apart from sibling tools like 'list_chats' and 'read_messages'.

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

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

Provides explicit when-to-use ('List group chats the user is in'), what it does NOT do ('only returns groups, not P2P'), and a clear alternative workflow for P2P chats ('use search_contacts → create_p2p_chat → read_p2p_messages'). It also notes prerequisite 'Requires OAuth setup.' This is exemplary guidance.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the need for open_id and the optional period_ids filter, but it does not describe the response format, pagination behavior, access permissions, or potential errors. 'Official API + UAT' hints at environment status but is vague. For a list operation, it is adequate but not exhaustive.

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

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

The description is three concise sentences, front-loaded with the core purpose. Each sentence adds value: the first states the function, the second gives a prerequisite and how to fulfill it, and the third explains optional filtering. No fluff or redundancy.

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

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

For a list tool with a fully documented schema, the description covers the primary use case, required input, and filtering. It could be more complete by differentiating from get_okrs or mentioning any output structure (though there is no output schema). The 'UAT' reference is ambiguous but overall the context is sufficient for a typical agent to invoke the tool correctly.

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

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

The input schema covers all six parameters with descriptions (100% coverage), so the baseline is 3. The description adds cross-tool guidance by pointing to get_login_status and search_contacts for obtaining user_id, and list_okr_periods for period_ids, which provides additional context beyond the schema. However, it does not add deeper semantics for parameters like limit or offset.

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

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

The description clearly states the tool's function: 'List a user's OKRs.' It uses a specific verb and resource, and the mention of 'a user's' distinguishes it from sibling tools like get_okrs (which likely targets the current user) and list_okr_periods. The requirement for open_id further clarifies its scope.

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

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

The description provides clear context on how to use the tool: 'Requires the user's open_id (get yours via get_login_status or search_contacts)' and 'Filter by period_ids to narrow to a specific quarter.' It does not explicitly exclude alternatives or state when not to use it, but it gives actionable prerequisites and filtering advice.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only states 'list nodes,' implying a read operation but does not explicitly confirm read-only, rate limits, pagination, or any side effects. The lack of detail forces the agent to assume behavior.

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

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

The description is very short and front-loaded, but the '[Official API]' prefix is unnecessary noise. It conveys the core purpose concisely but sacrifices detail. Overall, it is efficiently short but not optimally informative.

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

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

For a list operation with two parameters and no output schema, the description is incomplete. It omits details about pagination, sorting, response structure, or whether the parent_node_token filters results. The agent lacks sufficient context to use the tool reliably.

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

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

Schema description coverage is 100%, with each parameter having a basic description in the input schema. The tool description adds no extra meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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 nodes in a Wiki space.' The verb 'list' and resource 'nodes' are specific, and the scope 'in a Wiki space' differentiates it from sibling tools like 'get_wiki_node' (single node) or 'list_wiki_spaces' (spaces).

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for retrieving all nodes in a space versus other operations like creating, updating, or getting a single node. No context about prerequisites or exclusions.

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

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

With no annotations, the description must convey behavioral traits. It only states 'Official API' and 'list all accessible', implying read-only but fails to disclose rate limits, authentication needs, or other constraints.

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

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

The description is a single concise sentence. The '[Official API]' prefix is slightly redundant but not detrimental. It could be more structured but is efficient.

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

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

Given no output schema, the description should hint at return structure (e.g., list of spaces with IDs). It does not, leaving the agent uninformed about the output format. However, the tool is simple enough that this may be acceptable.

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

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

The input schema has no parameters, so schema coverage is 100%. The description adds no parameter info, which is acceptable since none exist. Baseline for zero parameters is 4.

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

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

The description clearly states the tool lists all accessible Wiki spaces, specifying the resource (Wiki spaces) and scope (accessible). It effectively distinguishes from sibling tools like list_wiki_nodes, which list 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.

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 conditions or prerequisites. It lacks explicit context for selection among similar list functions.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explains what each action does (create new app, duplicate, read metadata) and mentions optional wiki_space_id attachment. However, it does not cover side effects, permissions, or whether operations are asynchronous, leaving some transparency gaps.

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

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

The description is a single, compact sentence that front-loads the tool's purpose and then lists actions. Every word contributes, with no fluff or redundancy. It is efficiently structured for quick comprehension.

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

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

The tool has multiple actions and 6 parameters, but the description is minimal. The schema fully documents parameters, which raises the completeness baseline. Still, the description does not mention return values, error handling, or nuances like copy behavior, leaving some context gaps for a multi-action tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds a small amount of meaning by mapping actions to parameters (e.g., wiki_space_id for create) but does not go beyond what the schema already states for most parameters. The added value is marginal.

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

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

The description clearly states that the tool manages a Bitable app and enumerates the specific actions (create, copy, get_meta) with a brief explanation of each. This distinguishes it from sibling tools like manage_bitable_table, manage_bitable_field, etc., which target different Bitable components.

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

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

Usage context is implied through the action list: create for new apps, copy for duplicates, and get_meta for metadata. However, the description does not explicitly mention when to use this tool instead of related tools (e.g., manage_bitable_table) or any exclusions. The guidance is sufficient for straightforward selection but lacks alternative references.

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

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

With no annotations provided, the description carries the full burden of behavioral transparency. It adds the useful API quirk that `type` is required for update even when only renaming, and labels itself as an official API. However, it does not disclose permissions, deletion consequences, or return/error behavior, leaving significant gaps for a CRUD tool.

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

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

The description is a single sentence that includes the resource, action list, and a key caveat in parentheses. Every clause contributes useful information without repetition. It is well-structured and easily scannable.

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

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

The tool is a multi-action CRUD API with a nested property object and no output schema. The schema compensates for parameter details, but the description does not explain operational outcomes (e.g., delete irreversibility) or response format. While the type-requirement note provides one behavioral nuance, the overall operational picture is incomplete for an agent to use all actions confidently.

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

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

All parameters have detailed descriptions in the schema, so the baseline is met. The description's note about `type` for updates duplicates what the schema already states ('Required for create AND update — Feishu API rejects update without it'), so it adds no new semantics. Thus a score of 3 is appropriate.

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

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

The description clearly identifies the tool as managing fields/columns in a Bitable table, listing the four actions (list, create, update, delete). This distinguishes it from sibling tools like manage_bitable_table and manage_bitable_record by targeting the column-level resource. The 'Manage' verb is generic but the action enumeration adds specificity.

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

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

The description's opening phrase 'Manage fields (columns) inside a Bitable table' provides clear context for when to use the tool. It also includes a specific usage note about Feishu requiring `type` for updates, which guides parameter selection. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it falls short of the highest bar.

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

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

The description states that create/update/delete accept arrays up to 500 records, which is useful. However, with no annotations, it fails to disclose behavioral traits like idempotency, error handling, or required permissions. The description provides some transparency but is not thorough.

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

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

The description is short and front-loaded with the tool's purpose. Every sentence is informative and there is no redundant or unnecessary text.

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

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

Given the tool's complexity (9 parameters, nested objects, no output schema), the description covers the core actions and array limits but lacks details on return values, error handling, or prerequisites beyond what is in the schema. It is adequate but not fully complete.

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

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

The input schema has 100% description coverage, so baseline is 3. The description adds value by specifying that create/update/delete accept arrays and the batch limit (up to 500). This provides context beyond the schema's individual parameter descriptions.

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

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

The description clearly identifies the tool as managing records in a Bitable table and lists all possible actions (search, get, create, update, delete). This distinguishes it from sibling tools like manage_bitable_field or manage_bitable_table.

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

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

The description mentions the actions available but does not provide guidance on when to use each action or when to avoid this tool in favor of others. There is no explicit when-not or alternative tools mentioned, leaving the agent to infer usage context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects of delete, whether operations require special permissions, rate limits, or what happens on update beyond renaming. The destructive nature of 'delete' is not flagged.

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

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

The description is a single, densely informative sentence. It front-loads the core purpose ('Manage a table') and efficiently lists the actions without redundancy.

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

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

For a CRUD tool with no output schema and no annotations, the description is somewhat thin. It does not explain return values, prerequisites for delete, or confirm that update only renames (though this is hinted). The schema covers parameter semantics but not behavioral context.

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

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

The input schema already covers all parameters with 100% description coverage. The description adds marginal clarifications like 'update (rename)' and 'create (with optional initial fields)', but these are already implied in the schema. No substantial new information is provided.

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

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

The description clearly identifies the tool as managing a table inside a Bitable app and enumerates the specific operations (list, create, update, delete). This distinguishes it from sibling tools like manage_bitable_record and manage_bitable_field by explicitly targeting 'table'.

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

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

Usage is implied by the action list and the resource type ('table'), but there is no explicit guidance on when to use this tool versus alternatives like manage_bitable_record. No exclusions or alternative suggestions are provided.

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

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

With no annotations, the description carries the burden of disclosing behavioral traits. It does disclose the notable limitation that the Feishu API does not expose view updates, and suggests a workaround. However, it does not warn about the destructive nature of the 'delete' action or mention any side effects, permissions, or return behavior. The disclosed limitation adds value, but safety-critical aspects of mutation are absent.

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

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

The description is compact and effectively structured: it opens with the core purpose, lists supported actions, and then highlights the update limitation with a practical workaround. Every sentence carries information, and there is no redundant or distracting content. The '[Official API]' tag is minor but not harmful.

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

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

For a tool with 6 parameters, no output schema, and no annotations, this description covers the core function and a key limitation, which is helpful. However, it could be more complete by explicitly noting that delete is irreversible and clarifying which parameters are required for each action (though schema covers this). Overall, the description is quite complete for the complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond the schema; it merely lists actions, while the schema already explains each parameter's purpose (e.g., view_id required for delete, view_type options). No additional semantic context is provided, so a baseline score is appropriate.

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

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

The description clearly states the tool manages views in a Bitable table and enumerates the supported actions (list, create, delete). It distinguishes this from sibling tools that target other resources (app, table, field, record) by explicitly naming 'views' and the table context.

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

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

The description gives clear context: use this tool for list/create/delete operations on Bitable views. It also provides a valuable workaround for view updates (recreate with a new name), which is practical guidance. However, it does not explicitly mention when to prefer other Manage Bitable tools for non-view operations, so it lacks explicit 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.

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

With no annotations, the description carries the burden of disclosing behavioral traits. It explains the destructive delete action and the various create modes, but does not mention permissions, reversibility, rate limits, or return values. This leaves gaps in transparency for a complex tool.

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

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

The description is well-structured with a numbered list for create modes, front-loading the main purpose. Each sentence adds value, though it could be slightly more concise. It avoids redundancy with the schema.

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

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

Given the tool's complexity (3 actions, 5 modes, 13 parameters) and no output schema, the description covers input usage well but lacks details on expected output, error handling, or prerequisites (e.g., authentication). This leaves the user guessing about the return format.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters per action/mode (e.g., image_path only for create mode B) and explaining the relationship between parameters, which goes beyond the schema's individual descriptions.

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

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

The description clearly states the tool manages content blocks in a document, listing three actions (create, update, delete) with five create modes, and notes it replaces three older tools. This provides a specific verb and resource, distinguishing it from siblings like get_doc_blocks or create_doc.

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

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

The description gives explicit guidance on each action and mode, including required parameters (e.g., parent_block_id for create/delete, block_id for update). It does not explicitly state when not to use the tool, but the detailed action-mode breakdown makes usage clear. Could be improved by contrasting with get_doc_blocks for read-only operations.

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

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

With no annotations provided, the description carries full burden. It discloses that move and delete return task_id, and that type is always required with specific Feishu error codes (1061002/1062501). However, it does not state whether delete is permanent or whether special permissions are needed.

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