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

No annotations are provided, so the description must carry the full burden of disclosing behavioral traits. The description only lists supported features (color, Markdown, buttons) but does not mention any side effects, requirements (e.g., authentication, group context), potential errors, or what the response looks like. For a send operation, this lack of detail leaves the agent uncertain about outcomes and prerequisites.

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

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

The description is a single, efficient sentence that front-loads the core action and mentions the key capabilities. There is no wasted text, and every phrase contributes to understanding what the tool does. It is appropriately sized for a simple 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?

For a simple send tool with no output schema and no annotations, the description covers the main purpose and features. However, it lacks usage guidance, behavioral details, and any mention of how the target group is determined (since no group parameter exists). It also does not specify any limitations or edge cases. The description is adequate but leaves several operational gaps that an agent might need to know.

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 five parameters. The description adds minimal extra meaning by reiterating that the title bar is colorable, content is Markdown, and buttons are supported. This is redundant with the schema descriptions and does not clarify parameter relationships, format expectations, or defaults beyond what the schema states. 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 a specific action ('send an interactive card message to a Feishu group') and identifies the resource (a card). It mentions key capabilities (colorable title bar, Markdown body, bottom buttons), which distinguishes it from sibling tools like send_text or send_markdown. However, it does not explicitly name or contrast with siblings, so it misses the top score for explicit differentiation.

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 sending interactive cards but gives no explicit guidance on when to choose this tool over send_markdown, send_post, or others. There are no exclusion criteria or alternative recommendations. The context is inferable from the tool name and description but not stated, so it falls at 'implied usage' rather than clear 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 burden of behavioral disclosure. It discloses that a pre-uploaded image_key is required and that arbitrary image URLs are not accepted – a non-obvious behavioral constraint. It doesn't cover rate limits or error behavior, but for a simple send operation the key behavior is covered.

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 short sentence plus a clearly marked '注意' note. It is front-loaded with the action and immediately adds the critical prerequisite without any filler. 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?

For a one-parameter tool with no output schema and no nested objects, the description plus schema cover what the agent needs to invoke it correctly. The missing piece is what happens after sending (response/error), but that's minor given the tool's simplicity. It is 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?

Schema coverage is 100%, so the parameter is already well-described with a format example ('形如 img_xxxxx'). The description adds meaning by explaining how to obtain the value (via the Feishu upload API), which goes beyond the schema's format-only hint. This justifies a score above the 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?

States a clear action: '向飞书群发送图片' (send image to Feishu group). The resource type 'image' differentiates it from sibling tools send_text, send_markdown, send_card, send_post, and send_share_chat. The prerequisite about image_key adds further 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 includes a clear prerequisite: the image_key must come from the Feishu app upload API, which tells the agent what must be done before calling. It doesn't explicitly name alternatives or exclusions, but the image-specific function is obvious from the resource type. This is clear context without explicit when-not-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?

With no annotations, the description carries the behavioral burden. It discloses the key side effect (sending to a Feishu group) and the rendering path (interactive card with lark_md), which is useful. It does not mention failure behavior, permissions, rate limits, or how successful delivery is reported, but these are not critical for a basic send action.

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?

A single front-loaded sentence with no filler. The rendering note is compact and relevant, making the description easy to scan.

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 low-complexity with one required parameter and all parameters documented in the schema. The description, combined with the schema, gives enough to invoke it correctly, though it omits return-value and explicit sibling-selection notes.

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 details about text, title, or template beyond what the schema already provides. This is acceptable because the schema is self-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?

The description states a specific action ('向飞书群发送') and a resource/content type (Markdown messages), and adds the rendering mechanism ('通过交互卡片的 lark_md 渲染'). This clearly distinguishes it from siblings like send_text and send_image.

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 when-to-use or when-not-to-use guidance is given, and none of the sibling tools are named. The intended use for Markdown content is implied by the name and description, but an agent is not told how to choose between this and send_card or send_post.

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

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

No annotations are provided, so the description carries full burden. It only explains the message structure and tags, but does not disclose side effects (e.g., immediate posting), permission requirements, or response behavior. It also does not describe any error conditions.

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

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

The description is a single, front-loaded sentence that states the purpose first and then the structure. It is concise with no redundant information.

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

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

Given the absence of annotations and output schema, the description is adequate but not comprehensive. It explains the core concept and structure, but does not mention usage conditions, prerequisites, or expected outcomes. The schema covers parameter details, so the description is sufficient for a basic 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?

Schema coverage is 100%, so the baseline is 3. The description adds a concise summary of the paragraph and inline-element hierarchy, but the schema already documents this structure and the tag enums. The description adds limited value 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 states a clear action ('send rich text message') and resource (Feishu group), and describes the message structure (paragraphs with inline elements). This differentiates it from siblings like send_text and send_image, 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 implies usage for rich-text messages with structured paragraphs, but it does not explicitly state when to use this tool over send_text or send_markdown, nor any exclusions. The context is 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 full responsibility for behavioral disclosure. It only says 'send', implying a side effect, but does not mention permissions, reversibility, error conditions, or the nature of the sent card. This is a significant gap for a mutation tool.

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

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

The description is a single, efficient sentence with zero waste. It front-loads the primary action and leaves nothing extraneous.

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 annotations and no output schema, the description is minimal. It fails to explain prerequisites (e.g., group existence), potential errors, or what the recipient sees. For a side-effectful action, this is inadequate.

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 the parameter shareChatId clearly described as the open_chat_id of the shared group. The description adds no additional meaning beyond the schema, so a 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 'Send a group business card sharing card to a Feishu group' states a specific verb and resource (group card). It is distinguishable from siblings like send_text or send_image because it targets a specific content type, though it doesn't 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 usage is implied: use this when you need to share a group card. There is no explicit guidance on when to choose this over other send_* tools, and no exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only states the action (send plain text) without any information about side effects, authentication requirements, rate limits, failure behavior, or return values. For a mutation tool, this is a significant gap; the description adds nothing beyond the basic action.

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

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

The description is a single sentence with no filler words. It is appropriately sized for a simple tool with one parameter. The action is front-loaded, making it immediately clear what the tool does. Every word serves a purpose.

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

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

For a simple tool with one parameter and no output schema, the description is minimal but provides the core functionality. However, it lacks any mention of when to use it versus sibling tools, and it does not describe return values or error conditions. Given the presence of five siblings, additional context on selection 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?

The schema describes the single parameter 'content' as '消息文本内容' (message text content), which covers its meaning. The description does not add any additional context about the parameter, such as formatting, length limits, or encoding. With 100% schema coverage, the baseline of 3 applies, but the description adds no extra value.

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 states a specific action: sending a plain text message to a Feishu group. It identifies the resource (Feishu group) and the content type (plain text), which clearly distinguishes it from sibling tools like send_image or send_markdown. The verb 'send' and resource are explicit, making the purpose unambiguous.

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

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

The description implies usage for plain text messages but does not explicitly state when to prefer this tool over alternatives like send_markdown or send_card. There is no mention of exclusions or conditions. While the tool name and description make the intent clear, the lack of explicit guidance on selecting this over siblings leaves the agent to infer.

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