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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond the fact that a calendar is created. It does not say whether the calendar is private or shared, what permissions are required, whether the call is idempotent, or what the response returns on success. For a mutation tool with zero annotation coverage this is a substantial 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?

Two short sentences, no filler, with the action statement front-loaded before the trigger phrases. Every sentence 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?

The tool is simple (3 flat params, no output schema) and the schema documents all inputs, so the description is minimally sufficient for invocation. However, with no annotations and no output schema, it should have covered the mutation semantics and success behavior, which are absent.

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% and each of the three fields (color, summary, description) is documented inline, including format hints like hex color. The description adds no parameter meaning of its own, so the baseline of 3 applies — the schema, not the prose, does the work here.

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 pairs a specific verb (创建/create) with a specific resource (飞书日历), so the agent knows exactly what the tool produces. It does not explicitly contrast with siblings like feishu_update_calendar or feishu_delete_calendar, but the create/read/update/delete distinction is unambiguous from the verb alone.

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 gives concrete trigger utterances ('创建日历', '新建日历') that map user intent to this tool, which is genuinely useful routing guidance. It stops short of naming alternatives or stating when NOT to use it (e.g., pre-existing calendar, subscribing to an existing one), so it falls one step short of the top score.

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 behavioral burden. It mentions the required inputs but says nothing about side effects (whether attendees are invited/notified), auth/permission needs, or what the call returns. For a mutation tool with zero annotation coverage and 11 parameters, 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?

Three tight sentences: purpose, trigger phrases, required inputs, in that order. Every sentence earns its place, though the required-inputs sentence is largely redundant given the schema's required list.

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 exists and no annotations, so the description is the only behavioral signal. It adequately covers purpose and trigger conditions but omits side effects and return behavior, leaving the mutation semantics under-specified for an 11-parameter creation 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 description coverage is 100% with bilingual descriptions on every property, so the schema already documents parameters fully. The description only restates the four required inputs (calendar ID, title, start/end time) and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('创建飞书日程/会议' – create a Feishu calendar event/meeting), which is unambiguous. It does not explicitly contrast with siblings like feishu_update_event or feishu_create_calendar, but the verb 'create' plus 'event' cleanly separates it from the update/delete/get tools.

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 concrete trigger utterances ('创建日程', '新建会议', '安排会议', '添加日程', '预约') that map user phrasing directly to this tool, which is strong context. It stops short of naming when NOT to use it or pointing to the sibling for updating/moving an existing event, so it is 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 behavioral burden. 'Delete' implies a destructive, likely irreversible operation, but the description says nothing about permission requirements, reversibility, or whether deleting a calendar also removes its events — significant omissions for a destructive 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 front-loaded phrase with zero waste, which is efficient. It is arguably under-specified rather than verbose, but on pure conciseness and structure it performs well.

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 destructive tool with no annotations and no output schema, the description is too thin — it omits irreversibility, cascading effects on events, and required permissions. An agent has enough to call it mechanically but not to call it safely.

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?

With a single parameter at 100% schema coverage, the schema already documents calendar_id fully. The description adds no meaning beyond the schema, 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 states a specific verb (删除) and resource (飞书日历), which cleanly separates it from the event-oriented siblings like feishu_delete_event and feishu_get_calendar. However, it does not explicitly route the agent among the sibling calendar tools (e.g., update vs. delete), so it falls 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?

There is no guidance on when to use this tool versus alternatives such as feishu_update_calendar or feishu_unsubscribe_calendar, nor any stated prerequisites (permissions, ownership). The agent must infer everything from the name alone.

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

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, and it discloses nothing. For a destructive operation it never states whether deletion is permanent, whether attendees are notified, how recurring events are handled, or what permissions are required.

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?

It is very short with no wasted prose, but the length reflects under-specification rather than discipline, and the bilingual duplication of the same two words adds no information. Nothing is front-loaded because there is nothing to front-load.

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 two-parameter tool with a complete schema and no output schema, the structured fields cover most needs, but the total absence of destructive-operation context (permanence, side effects) leaves an agent under-informed for an irreversible action.

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 both calendar_id and event_id are already documented in the schema and the baseline of 3 applies. The description adds no additional meaning such as format, source, or constraints for either identifier.

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 is a direct restatement of the tool name: '删除日程 (Delete event)' for feishu_delete_event. It identifies the verb and resource only because the name already did, and it offers no differentiation from siblings such as feishu_delete_calendar or feishu_update_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?

No when-to-use, prerequisite, or alternative guidance is given. An agent gets no signal about when deletion is appropriate versus feishu_update_event, or whether the event must first be fetched via feishu_get_event.

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 behavioral burden. It does not state whether this is read-only, how availability is computed, whether existing events/working hours/timezones are considered, or any permission needs.

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 bilingual one-line description is front-loaded and free of filler. It is appropriately concise, though extremely terse and could include a small amount of routing context without becoming bloated.

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 scheduling query with four required parameters and no output schema or annotations, the description is incomplete. It lacks timezone assumptions, availability computation rules, and any indication of what the returned slots represent.

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 all four parameters are documented in the input schema. The description adds no extra meaning beyond the schema, such as inclusive/exclusive time boundaries or duration behavior, making the baseline 3 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?

States a specific verb and resource ('获取可用时间段' / Get available time slots), so the basic action is clear. However, it does not distinguish this from sibling tools like feishu_get_free_busy or clarify the scope of availability.

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 when-to-use guidance, prerequisites, or alternative-tool comparisons. An agent must infer usage entirely from the name and input schema.

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 behavioral burden. It only implies a read operation via '获取' and says nothing about return shape, permissions, or error behavior for an invalid ID — thin for a no-annotation 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?

A single short sentence with the purpose front-loaded and no filler. Efficient, though it could carry a bit more useful context without bloat.

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 single-resource read with 100% schema coverage and no output schema, the description is minimally sufficient. It omits any hint of what the returned detail contains or how to obtain a valid calendar ID.

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 one parameter, and schema description coverage is 100% with the schema documenting 'calendar_id' itself. The description merely restates the requirement ('需要提供日历 ID') without adding format or sourcing detail, 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?

States a specific verb+resource ('获取指定飞书日历的详细信息'), clearly indicating a single-calendar fetch. It does not explicitly name or differentiate from siblings like feishu_get_calendar_list, though '指定' implies one 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?

Provides the prerequisite ('需要提供日历 ID'), which is basic usage context. However, it gives no guidance on when to use this versus feishu_get_calendar_list or other sibling tools, leaving selection to inference.

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 does not mention that the operation is read-only or safe, nor does it describe pagination behavior, rate limits, or what the returned data includes. It only restates the purpose and usage triggers.

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 concise sentences: the first states the purpose, the second gives usage examples. It is front-loaded with the core action and has no unnecessary 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 list tool with well-documented schema parameters and no output schema, the description is adequate but lacks behavioral context such as read-only nature and pagination handling. It covers purpose and usage but leaves gaps that an agent might need to infer safely.

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 fully documents both parameters (page_size and page_token) with descriptions and default values. The description adds no additional parameter details, so 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 it queries all Feishu calendars, giving a specific verb and resource. It distinguishes itself from siblings conceptually by referring to all calendars, though it does not explicitly contrast with feishu_get_calendar (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?

It explicitly states when to use the tool by listing natural user phrases like '查询日历', '查看日历', '我的日历', '有哪些日历'. This provides clear triggers for invocation.

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 behavioral burden, yet it discloses nothing beyond the bare action. It does not state whether authentication or calendar access permissions are required, what happens when the event or calendar ID is invalid, or what the response contains.

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

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

A single short sentence with the verb and resource front-loaded; nothing is padded. It is efficient, though the extreme brevity leaves content gaps that conciseness alone cannot justify.

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 two-parameter read tool with fully documented parameters and no output schema, the description is minimally sufficient to select and invoke it correctly. However, with no annotations and no return-value guidance, an agent gets no hint about permissions or 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%, with event_id and calendar_id both documented in the schema, so the baseline of 3 applies. The description adds no additional semantic detail (e.g., ID formats or where to obtain them) beyond what the schema already supplies.

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 specific verb (获取) and resource (飞书日程详情), which is clearly a read of a single event. It does not explicitly distinguish itself from the sibling feishu_get_event_list, so the agent must infer the singular-vs-list distinction from the name alone.

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?

There is no when-to-use guidance and no mention of alternatives such as feishu_get_event_list or feishu_get_free_busy. The agent must infer usage purely from the tool name and required IDs.

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 mentions the action and a required input, but fails to disclose pagination behavior (despite page_size/page_token params), rate limits, sorting order, or what happens if no events exist. It does not describe what the returned list contains, which matters because there is no output schema.

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

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

Efficient, two-sentence description with the core purpose first, then trigger phrases. No wasted words. Could be slightly more concise on trigger examples, but they add value for intent matching.

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-fetching tool with 5 parameters (including pagination), no output schema, and no annotations, the description is insufficient. It omits pagination guidance, return shape, time-range filtering behavior, and default values. An agent cannot fully anticipate behavior from this description alone.

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 only adds that calendar_id is required, which is already indicated by the required field in the schema. No additional meaning is provided 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?

Clear verb+resource: querying a Feishu calendar/event list. It's a list-fetching tool, distinguishable from feishu_get_event (single event) and feishu_get_calendar_list by the 'calendar ID' requirement. However, it doesn't explicitly name the sibling tools it contrasts with, preventing a full 5.

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

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

Provides natural-language trigger phrases (查看日程, 今天的安排, etc.) which give clear usage context. It states the prerequisite of providing a calendar ID. However, it doesn't state when NOT to use this (e.g., vs get_event for a single event) or explicitly cross-reference alternatives.

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 carry the full burden of behavioral disclosure. It does not state whether this is a read-only operation, what permissions are required, how the busy status is computed, whether it includes all-day events, or what the response format looks like. The description is devoid of any behavioral context beyond the vague purpose.

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 extremely concise (a single bilingual phrase), but it is under-specified rather than efficient. It front-loads the core purpose but lacks any supporting detail that would make it useful. For a tool description, being this short without adding value is a weakness, not a strength.

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 that this is a read tool with no annotations, no output schema, and three required parameters, the description is completely inadequate. It does not explain what the tool returns, whether it aggregates over multiple calendars, how it handles time zones, or any operational constraints. Nothing an agent needs to call it correctly is provided.

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 all three parameters are already well-documented in the schema (calendar_ids, start_time, end_time with types and units). The description adds no additional parameter information, but because the schema is complete, 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 is essentially a translation of the tool name: 'feishu_get_free_busy' -> '查询用户忙碌状态' (query user busy status). It restates the name in Chinese and English but adds no specificity, such as what 'busy status' means in output, whether it returns intervals, or how it differs from the sibling feishu_get_available_time. This is tautological and fails to distinguish it from 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 no guidance on when to use this tool versus alternatives like feishu_get_available_time or feishu_get_event_list. It does not state any conditions, prerequisites, or exclusions, leaving the agent to infer usage entirely from the name.

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 behavioral burden, and it discloses nothing beyond the bare verb. It does not state whether the operation is idempotent, what happens if the calendar is already subscribed, what permissions are required, or what side effects occur.

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?

It is a single short bilingual phrase with no wasted words, but the brevity reflects under-specification rather than tight editing. There is no structure to speak of because there is no substantive content.

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 mutation-like tool with no annotations and no output schema, the description should carry the safety and behavior profile; instead it offers only the name restated. The only element that is complete (the parameter list) is already covered by the 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?

There is a single required parameter with 100% schema description coverage, so the schema already documents calendar_id. The description adds no syntax, format, or sourcing detail beyond the schema, which is the expected baseline when the schema does the work.

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 is a direct bilingual restatement of the tool name ('订阅日历 / Subscribe to calendar') with no added specificity. It tells the agent nothing the identifier did not already convey and does not distinguish it from its closest sibling, feishu_unsubscribe_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?

No guidance on when to subscribe, what precondition must hold (e.g. an existing calendar the caller can access), or how this relates to feishu_get_calendar_list / feishu_unsubscribe_calendar. The agent must infer usage from the name alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, yet it only restates the tool name. It says nothing about whether the operation is destructive, reversible, requires special permissions, or what side effects occur.

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 extremely concise and front-loads the action, with no wasted words. However, it is so minimal that it lacks any structure beyond a direct translation of the tool name.

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 mutation tool with no annotations and no output schema, the description is not complete enough. It omits behavioral context such as side effects, reversibility, and when to use this tool rather than related calendar 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 description coverage is 100%, so the single parameter calendar_id is already fully documented in the schema. The description adds no additional meaning beyond what the schema provides, making the baseline 3 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 states a specific verb and resource: 'Unsubscribe from calendar'. It clearly conveys the action, though it does not explicitly differentiate this from sibling tools like delete_calendar or subscribe_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 no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or the fact that it only removes a subscription rather than deleting the calendar.

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 mentions '更新' (update), which implies a mutation, but it doesn't describe what happens to existing fields, whether the operation is reversible, permission requirements, or the expected response. 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, concise sentence that is front-loaded with the core action. It avoids unnecessary details, though it could be slightly more informative without becoming verbose.

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

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

Given the complexity of a mutation tool with four parameters, no annotations, and no output schema, the description is incomplete. It fails to mention required permissions, the scope of updates, or any behavioral aspects, leaving the agent under-informed 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?

The schema description coverage is 100%, so the input schema already documents all four parameters (color, summary, calendar_id, description) with clear descriptions. The tool description adds no additional meaning beyond what the schema provides, making the baseline score of 3 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 states a specific verb ('更新' / update) and resource ('飞书日历' / Feishu calendar), making the purpose immediately clear. It is distinguishable from siblings like feishu_create_calendar or feishu_get_calendar by the update action, 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 description provides no guidance on when to use this tool versus alternatives, such as feishu_create_calendar or feishu_delete_calendar. It lacks any context about prerequisites (e.g., needing an existing calendar) or scenarios where it should be selected.

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, yet it says nothing about permissions required, whether updates are partial or full, what happens on missing events, or any response behavior. It is a mutation tool with zero behavioral context.

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

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

The description is extremely short and lacks structure, but this is under-specification rather than effective conciseness. It does not front-load any useful information beyond the bare operation name.

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 mutation tool with no annotations and no output schema, the description is completely inadequate. It omits any discussion of usage, behavior, or parameter nuances, leaving an agent without sufficient context to invoke it 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 has 100% description coverage for all 7 parameters, so the schema already documents meanings. The description adds no additional parameter semantics, making the baseline score of 3 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 '更新飞书日程' is essentially a Chinese translation of the tool name 'feishu_update_event', making it a tautology that restates the name rather than elaborating on what the tool does. It gives a verb and resource but adds no specificity beyond the name itself.

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

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

There is no guidance on when to use this tool versus alternatives like feishu_create_event or feishu_update_calendar. The description merely states the operation without any context about prerequisites or appropriate scenarios.

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