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

Since no annotations are provided, the description carries the burden of behavioral disclosure. It discloses the mutation ('Add'), a successful return value ('Returns True on success'), and capacity constraints. It does not cover failure modes or permission requirements beyond the bot-ownership implication, making this adequate but not comprehensive.

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 concise sentences with no filler: the first states the purpose, the second provides relevant capacity limits, and the third gives the success return value. Every sentence earns its place and the main action is front-loaded.

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 core purpose, the bot-ownership prerequisite, capacity bounds, and return value, while the schema handles nested InputSticker details. It lacks explicit alternative routing and failure semantics, so it is not fully complete, but it provides enough context for basic 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 input schema covers 100% of parameters and already provides meaningful descriptions for user_id, name, and sticker. The tool description adds no additional 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 states a specific operation: 'Add a new sticker to a set created by the bot.' It clearly identifies the resource (sticker set) and an ownership constraint. It implicitly distinguishes itself from createNewStickerSet but does not explicitly name sibling alternatives, 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 implies usage context: use this for existing sets created by the bot, and the capacity limits tell the agent when adding is possible. However, it does not explicitly state when not to use it or mention alternatives like createNewStickerSet or uploadStickerFile, so guidance is implied rather than explicit.

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

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

The description discloses the user-visible effect ('displayed as a notification at the top of the chat screen or as an alert') and states that it returns True on success. However, with no annotations provided, it does not address failure behavior, timeout sensitivity, or lack of side effects beyond the acknowledgement.

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 filler. It front-loads the core action, then adds the behavioral outcome and return value, every phrase earning 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 low-complexity tool with a 100%-documented input schema and no output schema, the description covers what the tool does, its visible effect, and its success return. It could be slightly more explicit about when not to use it, but it is otherwise sufficient.

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 parameters are already fully documented. The description does not add meaning beyond the schema; it only repeats the conceptual behavior of showing a notification or alert, which maps to the show_alert and text fields already described.

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 names a specific verb and resource: 'Send answers to callback queries sent from inline keyboards.' This distinguishes it clearly from sibling tools like answerInlineQuery, answerWebAppQuery, answerShippingQuery, and answerPreCheckoutQuery, which handle different query types.

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: this tool is for callback queries originating from inline keyboards, and the answer appears as either a chat notification or an alert. It does not explicitly state when not to use it or name alternatives, but the query type is specific enough to guide selection.

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 present, the description carries the full burden and does disclose behavior beyond the schema: the 50-result cap, that results render in the user's chat, and that it returns True on success. It omits error behavior and timing sensitivity (inline queries expire), but it offers three concrete operational facts useful to an agent.

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

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

Four short sentences, each earning its place: purpose, display effect, hard limit, and return value. The core purpose is front-loaded before constraints, with no filler and no repetition of schema 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 tool with nested result objects, no output schema, and no annotations, the description covers the essentials — purpose, cap, and return value. It leaves gaps an agent would want: the need to respond promptly before the query expires, failure behavior for an invalid inline_query_id, and the valid InlineQueryResult shapes for the nested results array.

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 six parameters; the baseline of 3 applies. The description adds one useful constraint above the schema — 'Maximum 50 results per query' — but does not otherwise enrich the meaning of individual 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 a specific verb+resource pair — 'Send answers to an inline query' — which cleanly distinguishes this from siblings like answerCallbackQuery, answerWebAppQuery, and sendMessage. The clause 'Results are displayed in the user's chat' reinforces the exact scenario 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 wording implies the tool is used in response to an inline query update, but there is no explicit when/when-not guidance or alternative routing. An agent must infer the distinction from the sibling set (e.g., answerCallbackQuery exists for callback queries) rather than being told.

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 discloses the success return value ('True is returned') and the essential 10-second deadline. It does not detail failure behavior beyond schema hints, but the key operational constraints are present.

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 core purpose is front-loaded and the description is mostly concise. The sentence 'Use this method to respond to such pre-checkout queries' is somewhat redundant with the first sentence, but the remaining content about the Update field, return value, and deadline all earn their 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 simple three-parameter method with fully documented schema, the description covers the trigger event, the required action, the return value, and the essential time limit. An agent has enough information to invoke the tool correctly without additional 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?

Schema description coverage is 100%, so the baseline of 3 applies. The description does not add parameter-level meaning beyond the schema; it only provides contextual background about where the query comes from, which is useful but not necessary for 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?

States a specific verb ('Respond') and resource ('pre-checkout queries') and explains the trigger context (an Update with the pre_checkout_query field). It clearly identifies the distinct operation from related siblings like answerShippingQuery, even without naming them explicitly.

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 on when to use the method: after the user confirms payment and shipping details, when the Bot API sends a pre_checkout_query update. It also notes the critical 10-second response window, though it does not mention alternatives or exclusion cases.

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 disclosure burden. It states the trigger context and that True is returned on success, but it does not explain failure behavior, whether a query can be answered only once, or any side effects beyond the reply.

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 core purpose, but it repeats 'reply to shipping queries' in the first and third sentences. This redundancy slightly undermines conciseness without adding 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?

For a straightforward look-and-answer method, the description provides the necessary trigger context and return behavior, while the schema covers parameter details. It is complete enough for an agent to understand when and how to 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?

Schema coverage is 100%, so the schema documents all four parameters. The description adds no extra meaning about the parameters themselves; it only references is_flexible from the invoice context, not any direct parameter.

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 as 'Reply to shipping queries' and references the shipping_query Update field. This distinguishes it well from sibling methods like answerPreCheckoutQuery or answerCallbackQuery.

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 specifies the exact triggering condition: after sending an invoice with is_flexible requesting a shipping address, the Bot API sends a shipping_query Update. This gives clear context for when to use the tool, though it does not explicitly name 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?

With no annotations, the description carries the full burden of disclosure. It directly states the main side effect — sending a message on behalf of the user to the originating chat — and mentions the success return type. It does not cover permission prerequisites or failure behavior, but the core send-on-behalf-of-user behavior is explicit.

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 dense sentence with no filler, front-loading the action and side effect before noting the return value. Every clause contributes useful 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?

For a two-parameter tool with a nested object and no output schema, the description provides essential context: the query originates from a chat, the message is sent on behalf of the user, and a SentWebAppMessage object is returned on success. It could add an explicit note about permission requirements or one-time answering, but it is largely 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%, so the schema already documents web_app_query_id and result. The description adds no parameter-level detail beyond what the schema provides; mentioning 'result' and 'message' is consistent but redundant.

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 a specific verb phrase, 'Set the result of an interaction with a Web App,' and identifies the unique resource: a Web App query. It also clarifies that a message is sent on behalf of the user to the originating chat, which distinguishes it from sibling answer*Query tools such as answerCallbackQuery and answerInlineQuery.

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 conveys a clear context: use this tool when a Web App interaction has produced a query that must be answered and the resulting message should be sent to the originating chat. It does not explicitly name alternatives or exclusions, but the context is specific enough to route an agent correctly.

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 required administrator permission and states that the method returns True on success. It does not describe failure behavior or side effects, but for a simple approval action this is reasonably 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 two concise sentences with no filler. The core action is front-loaded, and the prerequisite and return value each earn their 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 low-complexity: two fully documented parameters, no output schema, and no annotations. The description covers the essential authorization requirement and success return value, making it largely complete. A note contrasting it with declineChatJoinRequest would make it 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?

Schema description coverage is 100%, and the input schema already explains both chat_id and user_id clearly. The description adds no parameter-specific information beyond the schema, which fits 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?

The description states a specific verb ('Approve') and a clear resource ('chat join request'), which unambiguously identifies the operation. It is distinct from the sibling declineChatJoinRequest and other chat-management 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?

The description provides clear context for when to use the tool: to approve a chat join request, and it names a concrete prerequisite (bot must be an administrator with can_invite_users rights). It does not explicitly mention the alternative declineChatJoinRequest, 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, the description carries the burden of behavioral disclosure. It does disclose the required can_post_messages permission and the success return value, but it does not explain failure behavior, reversibility, or how send_date affects publishing. This is partial but not full 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?

Two sentences with no wasted words. The action is front-loaded, and both the permission requirement and return value earn their place as essential operational details.

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 three-parameter approval action, the description covers the operation, the required permission, and the return value. It does not mention the relationship to declineSuggestedPost or scheduling implications, but those are minor gaps given the schema covers parameters.

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 three parameters with 100% coverage, so the baseline is 3. The description adds no parameter-specific detail beyond the general action context, but it also does not need to because the schema is complete.

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, 'Approves,' and a precise resource, 'suggested post in a direct messages chat.' This clearly distinguishes it from the sibling tool declineSuggestedPost and leaves no ambiguity about the 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?

It provides useful context by stating where approval happens and the required administrator right, but it never explicitly mentions when to use this tool versus declineSuggestedPost or when not to use it. Usage is implied rather than explicitly contrasted with 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?

With no annotations, the description carries the full disclosure burden, and it does meaningful work: it states the action, the permission prerequisite, and the success return value ('Returns True on success'), which is valuable since there is no output schema. It does not mention that a ban is permanent by default unless until_date is set, nor the message-deletion side effect of revoke_messages — those are left to the schema. For a no-annotation mutation tool, this exceeds the bare minimum.

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 short sentences with zero filler: action+scope, prerequisite, and return value. The action is front-loaded, and every sentence earns its place — the return-value sentence is justified because there is no output schema. This is a model of compact, structured description.

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 core invocation facts are covered (what it does, where, the admin prerequisite, and the return value), and the schema fully documents parameter semantics. The clear gaps are the absence of tool-level guidance on the default-permanent ban behavior (only implied deep inside the until_date schema description) and no positioning against the large moderation sibling family (unban/restrict/banChatSenderChat). Adequate, but an agent would benefit from more orientation.

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% — all four parameters (chat_id, user_id, until_date, revoke_messages) are individually described in the schema, including edge-case semantics like the 366-day/30-second permanent-ban rule. The description itself adds no parameter-level information. Per the rubric, baseline 3 applies when 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 states a specific verb (ban) + resource (a user) + scope (group, supergroup or channel), which fully identifies the operation. It also self-differentiates from the sibling family by action semantics: unbanChatMember is the inverse, restrictChatMember is a lesser restriction, and banChatSenderChat targets a chat rather than a user.

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 supplies a useful precondition ('The bot must be an administrator with the appropriate rights'), which tells the agent when the call can succeed. However, it gives no explicit when-to-use vs alternatives or exclusions — in a sibling list containing unbanChatMember, restrictChatMember, and banChatSenderChat, the agent must infer routing from the names alone. Usage context is present but effectively implied rather than 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 behavioral disclosure burden. It explains the consequence ('owner of the banned chat won't be able to send messages on behalf of any of their channels'), the prerequisite ('bot must be an administrator'), and the return value ('Returns True on success'). It also implies reversibility via 'until the chat is unbanned.'

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 concise, information-dense sentences. The primary action is front-loaded, followed by the key consequence and prerequisite, with no filler or repetition of schema 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?

The description covers the action, effect, prerequisites, and return value. There is no output schema, so the explicit 'Returns True on success' is valuable. Minor gaps such as how to obtain the sender_chat_id or error behavior are not included, but the core calling context 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 description coverage is 100%, so the input schema already documents both parameters fully. The description does not add meaning beyond the schema's field descriptions, which is acceptable given the high 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?

States a specific verb and resource: 'Ban a channel chat in a supergroup or channel.' This clearly distinguishes the operation from banChatMember and aligns with the sibling unbanChatSenderChat. The scope ('channel chat' as opposed to a user) is explicit.

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: it bans a channel chat and requires the bot to be an administrator with appropriate rights. It does not explicitly name alternatives such as unbanChatSenderChat or banChatMember, but the behavior described makes the intended use case evident without ambiguity.

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 behavioral burden. It states the core action and a prerequisite, but it does not disclose expected effects such as return value, reversibility, or what state the bot instance enters afterward.

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 short sentences, with the main action front-loaded. The final two clauses both express the same local-server condition, introducing slight redundancy, but the description remains compact 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?

For a parameterless close operation with no output schema, the description covers what and when sufficiently. It could mention the resulting bot state or distinguish from logOut, but those gaps are minor given the tool's 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?

The tool takes zero parameters and the empty schema fully captures that, so there is nothing for the description to add. The baseline of 4 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 starts with a specific verb and resource: 'Close the bot instance.' It also adds the context 'before moving the bot to a local server,' which helps distinguish it from related sibling methods such as logOut or deleteWebhook.

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 an explicit trigger: 'Use before moving the bot to a local server. Must be called before running locally.' It does not name alternatives or state when not to use it, so it falls just 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 carries the full burden of behavioral disclosure. It adds useful context by specifying the admin permission requirement and stating that it returns True on success. It does not mention failure behavior, side effects, or what happens if the topic is already closed, which would strengthen 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 two short sentences with no wasted words. It front-loads the main action, then adds the essential permission requirement and return value. Every sentence contributes meaningful information, making it 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?

For a simple two-parameter method with no output schema and no annotations, the description covers the essential elements: the action, the target, the authorization requirement, and the success return value. It could be slightly more complete by noting behavior on already-closed topics or explicitly routing to reopenForumTopic, but the core information needed to invoke the tool correctly is present.

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 chat_id and message_thread_id are already documented in the input schema. The tool description adds no additional parameter-level meaning, such as how chat_id relates to supergroups or that message_thread_id identifies the topic. The baseline of 3 is appropriate since the schema does the necessary 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 uses a specific verb ('Close') and resource ('an open topic in a forum supergroup chat'), making the tool's function unambiguous. It implicitly distinguishes itself from siblings like reopenForumTopic and closeGeneralForumTopic by specifying 'open topic' and 'forum supergroup chat'. Even without title information, an agent can identify exactly what this tool does.

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 states a key prerequisite: the bot must be an administrator with can_manage_topics rights. However, it does not explicitly say when to prefer this tool over alternatives such as reopenForumTopic or closeGeneralForumTopic. Usage context is implied by the action described, but explicit when/when-not guidance is missing.

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 discloses that the operation is a mutating close action, requires specific administrator rights, and returns True on success. However, it does not detail side effects (e.g., whether the topic can be reopened, impact on existing messages), which would be useful for an unannotated 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 concise and front-loaded: it immediately states the action and target, then adds the permission requirement and return behavior. Every sentence 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?

For a single-parameter operation with no output schema, the description is complete: it identifies the target, the required permission, and the success return value. An agent has enough information to invoke the tool correctly without additional 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 provides a complete description for chat_id, so schema coverage is 100%. The description adds no extra parameter-level detail. Per the rubric, the baseline is 3 when 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 states a specific verb and resource: 'Close the 'General' topic in a forum supergroup chat.' This clearly identifies the operation and differentiates it from sibling tools like closeForumTopic, which targets a regular topic rather than the special General topic.

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 applies: closing the General topic in a forum supergroup. It also states the prerequisite that the bot must be an administrator with can_manage_topics rights, which helps an agent determine eligibility. It does not explicitly compare to sibling alternatives, but the target resource ('General' topic) makes the usage context clear enough.

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 behavioral disclosure burden. It states the permission requirement, the conversion action, and the return value ('Returns True on success'). However, it does not describe failure behavior, side effects, or the condition of the original gift after conversion, which would be useful for a mutation-like 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 concise sentences. The key action and permission are front-loaded, and the return value is stated clearly with no filler or repetition of schema details.

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 two-parameter tool with a fully described schema, the description provides the essential context: the action, the permission prerequisite, and the success return. It does not specify error conditions or whether the gift is consumed, but given schema completeness and no nested objects, the description is sufficiently complete for correct invocation in most cases.

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 100% of parameters with descriptions, so the baseline is 3. The description does not add parameter-level meaning beyond the schema, but it confirms the overall operation and the required permission, which indirectly clarifies why both parameters are 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 a specific verb ('Converts') and resource ('regular gift to Telegram Stars'), and mentions a required permission ('can_convert_gifts_to_stars business bot right'). This distinguishes it from sibling gift tools like upgradeGift, transferGift, and getBusinessAccountGifts.

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 names a required permission, which indirectly tells an agent the tool can only be used when that right is present. It does not explicitly mention alternatives or when not to use it, but the permission requirement and the verb 'convert' give clear context compared to siblings.

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 responsibility for behavioral disclosure. It explains the lack of a link to the original, the limits on service/paid/giveaway/invoice messages, the quiz poll condition, and the return value. This is a strong disclosure of core behavior, though it does not discuss edge cases like media group behavior or rate limits.

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 sentences, all informative and front-loaded with the core purpose. Every sentence earns its place: the action, the exceptions, the comparison to forwardMessage, and the return type. No filler or redundant restatement 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?

Despite having 17 parameters and no output schema, the description covers the crucial invocation context: what can be copied, what cannot, and what is returned. The schema handles the remaining parameter details, so nothing critical is missing for an agent to correctly select and invoke the tool. It could add examples or integration notes, but none are essential.

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 17 parameters in detail. The description adds little parameter-specific meaning beyond what the schema provides; it does not reiterate or enrich parameter semantics. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description states a specific verb and resource: 'Copy messages of any kind', then precisely scopes exceptions and an analogy to forwardMessage. It clearly distinguishes itself from forwardMessage by noting the copied message doesn't have a link to the original, so an agent can tell them apart without opening the schema.

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 context for when to use copyMessage versus forwardMessage: it is analogous but removes the original-message link, which is a clear decision criterion. It lists unsupported message types and the quiz poll condition, providing important constraints. It does not explicitly mention the sibling copyMessages tool or advise when bulk copying is preferred, so some usage guidance is left implicit.

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, and it does so thoroughly. It states that unfindable/un-copyable messages are skipped, enumerates non-copyable message types, gives the quiz-poll condition, notes that album grouping is preserved, and specifies the success return. This is unusually complete for a tool with no annotation support.

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

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

Each sentence in the description delivers a distinct operational fact: core action, failure behavior, unsupported types, quiz condition, comparison to forwardMessages, album handling, and return format. There is no filler or repetition of schema content, and the core action is front-loaded.

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 8 parameters, no annotations, and no output schema, the description covers the essential non-obvious details: partial failure behavior, unsupported message types, special poll condition, relationship to forwardMessages, album grouping, and return value. The schema handles parameter details, so nothing critical is missing for an agent to invoke this 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 already describes all 8 parameters, including chat_id, message_ids, and remove_caption, so the baseline is 3. The description adds behavioral context such as skipped messages and album grouping, but it does not clarify individual parameter semantics beyond what the schema already states.

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 a clear verb and resource: 'Copy messages of any kind.' It also distinguishes the tool from forwardMessages by noting that copied messages don't retain a link to the original. However, it never explicitly differentiates copyMessages from its sibling copyMessage, and 'any kind' is immediately qualified by a list of non-copyable types.

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 explicitly comparing the method to forwardMessages and calling out the key tradeoff: copied messages lack a link to the original. This lets an agent choose between copying and forwarding in many cases. It does not provide explicit when-to-use guidance relative to copyMessage or the send* family, but the batch nature is strongly implied by the plural name and message_ids parameter.

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 covers the authorization requirement, the fact that the link is revocable, and the return type. It does not mention rate limits or specific failure modes, but the core behavioral profile is 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 three short sentences, each contributing a distinct fact: what the tool creates, required permissions, revocability, and return type. There is no 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 five-parameter mutation tool with no annotations and no output schema, the description covers the essential context: purpose, permission requirement, lifecycle, and return type. It leaves some sibling differentiation implicit, but the schema handles parameter constraints and the description is otherwise complete enough 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?

The input schema covers all five parameters with descriptions, giving 100% schema coverage, so the baseline is 3. The description does not add parameter-level meaning beyond what the schema already provides, but it also does not need to compensate for any schema gaps.

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 resource: 'Create an additional invite link for a chat.' The word 'additional' helps distinguish this from exporting the primary invite link, but it does not explicitly differentiate it from sibling methods like createChatSubscriptionInviteLink or editChatInviteLink.

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 usage context by specifying that the bot must be an administrator with can_invite_users rights, and it notes that the link can later be revoked via revokeChatInviteLink. However, it does not explicitly state when to prefer this tool over related invite-link alternatives, so it stops short of full alternative routing.

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 transparency burden. It discloses the authorization prerequisite, the return type (ChatInviteLink object), and the fact that the link can later be edited or revoked. This is meaningful behavioral context beyond the schema, though it does not mention potential side effects or failure 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 compact: three sentences, each earning its place. It front-loads the primary action, then adds the precondition, lifecycle alternatives, and return type without repeating schema details.

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 appropriately states the return type. It also covers the key precondition and post-creation actions. The schema handles parameter semantics, so nothing critical is missing for an agent to invoke this tool correctly, though a brief contrast with regular invite links would have been slightly more 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%, so the schema already documents all four parameters clearly. The description adds no extra parameter-level meaning, which matches the baseline of 3 when 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 opens with a specific verb and resource: 'Create a subscription invite link for a channel chat.' This clearly distinguishes it from the sibling createChatInviteLink and other invite-link tools by naming the subscription nature and target chat type.

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 stating the required administrator right (can_invite_users) and names the lifecycle alternatives editChatSubscriptionInviteLink and revokeChatInviteLink. It does not explicitly say 'use this instead of createChatInviteLink for regular invite links,' so it stops short of a full when-to-use/when-not-to-use specification.

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 behavioral disclosure burden. It discloses the required administrator permission and the return type (ForumTopic object), adding meaningful context beyond the schema. It doesn't describe failure modes, but the permission requirement is the key behavioral constraint for this creation 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 with no filler. It front-loads the action and target, then follows with the permission requirement and return type. Every clause 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 description covers the essential operational context: target resource, required permission, and return value. The schema covers all parameter details, so nothing critical is missing. A slightly richer note about the returned ForumTopic object's relevance or failure behavior would push it to fully complete, but it is sufficient 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%, so the input schema already documents all four parameters including icon color values and emoji identifier usage. The description adds no additional parameter-level semantics, 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 states a specific action ('Create'), a specific resource ('a topic in a forum supergroup chat'), and is distinct from sibling tools like editForumTopic or deleteForumTopic. The verb+resource combination makes 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?

The description clearly identifies when the tool applies (creating a topic in a forum supergroup chat) and gives a concrete prerequisite (bot must be an administrator with can_manage_topics rights). It doesn't explicitly contrast with alternatives, but the creation context is clear enough that an agent can select it over edit/close/delete siblings.

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 behavior disclosure. It only mentions returning a string on success, but says nothing about side effects, required payment provider setup, whether a user is charged, or what failure behavior looks like. For a financial/create type operation with zero annotation coverage, this is a meaningful gap.

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

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

The description is a single, front-loaded sentence with no filler. It states the primary action and the return value in the fewest possible words. Nothing in the description is redundant or unnecessary.

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 a rich 22-parameter schema, the description does not address key contextual elements: when this should be used instead of sendInvoice, payment-related constraints, or operational requirements. Since there is no output schema, the description is the only place to explain the full call context, and it falls short for a complex payment 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?

Input schema coverage is 100%, so all 22 parameters have descriptions in the schema. The tool description adds no additional parameter semantics, which matches the baseline of 3 when the schema already documents everything.

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: 'Create a link for an invoice'. It clearly distinguishes itself from the sibling sendInvoice by focusing on link creation rather than sending. It also explicitly states the return type, which removes ambiguity about what the tool produces.

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 does not state when to use createInvoiceLink versus sendInvoice or other payment-related tools. It says 'create a link' but gives no explicit context, prerequisites, or exclusions. An agent must infer the use case from the tool name and 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?

There are no annotations, so the description carries the full behavioral disclosure burden. It does state two useful facts: the bot gains the ability to edit the sticker set, and the method returns True on success. However, it does not mention failure behavior, error cases, or any implicit ownership/authorization constraints beyond the phrase 'owned by a user'.

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 short sentences with no filler. The core action is front-loaded, and each sentence contributes distinct information: creation, the bot's future edit permission, and the success return value. Nothing is redundant or missing from a structural standpoint.

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 schema comprehensively documents all six parameters, including enum values and special boolean constraints, and the description supplies the success return value since there is no output schema. The key side effect—bot edit rights—is also disclosed, making the definition usable for correct invocation. It still lacks explicit failure semantics and alternative routing, but these are partially addressed by the schema and sibling tool names.

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?

Input schema coverage is 100%, so every parameter already has a meaningful description in the schema. The tool-level description adds only a loose echo of parameters ('new sticker set', 'owned by a user') but no extra format, constraints, or relationships. This is the appropriate baseline case where 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 uses a specific verb ('Create') and a clear resource ('a new sticker set owned by a user'), so the tool's function is immediately evident. It also adds a distinguishing trait: the bot will be able to edit the sticker set. This is not a tautology and separates it from read/manipulation tools like getStickerSet or addStickerToSet.

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 word 'new' implies this is for creating a set rather than modifying an existing one, but the description does not explicitly compare against sibling tools such as addStickerToSet, setStickerSetTitle, or uploadStickerFile. It gives no explicit when-to-use or when-not-to-use guidance, nor any prerequisites such as the need for a user to have interacted with the bot.

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 behavioral disclosure burden. It reveals the required administrator permission ('can_invite_users rights') and the success return value ('Returns True on success'), which are useful operational traits beyond the schema.

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

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

The description is two short sentences that communicate the action, the prerequisite, and the return value without unnecessary words. All sentences add 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?

For a simple two-parameter tool, the description is complete: it explains what the tool does, the required permission, and the return behavior. The schema fully documents the parameters, so no critical context is missing.

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 for both parameters, chat_id and user_id, with descriptions. The tool description adds no additional parameter semantics, 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 states a specific verb and resource: 'Decline a chat join request.' This is unambiguous and distinguishes the tool from its sibling approveChatJoinRequest, making the operation clear to an agent.

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 clearly identifies the action, but it does not explicitly contrast with approveChatJoinRequest or state when to choose this over alternatives. The usage is implied by the operation name and description rather than explicitly guided.

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 behavioral disclosure burden. It clearly states the required permission, the action performed, and the return value (True on success). It does not describe error cases or whether the action is reversible, but for a simple decline operation the key behavioral traits are 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 composed of three short sentences with no filler: the action, the permission requirement, and the return value. Every sentence serves a distinct purpose, and the most important information is front-loaded.

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 three well-documented parameters and no output schema, the description covers the core action, the required permission, and the return value. It does not mention edge cases or failure modes, but nothing essential for calling the tool correctly is missing given the schema's thorough parameter descriptions.

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 parameter-specific meaning beyond what the schema already provides; it does not clarify comment usage or further detail chat_id/message_id semantics. Each parameter is already well documented 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?

The description clearly states the action ('Declines a suggested post') and the context ('in a direct messages chat'), distinguishing it from the sibling approveSuggestedPost. The verb and resource are specific, leaving no ambiguity about what the tool does.

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 by stating the action, and it provides a clear prerequisite (can_manage_direct_messages administrator right). However, it does not explicitly name alternatives like approveSuggestedPost or describe conditions where the tool should not be used, leaving usage guidance mostly 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, the description carries the burden and uses it well: it discloses the required permission scopes ('can_delete_sent_messages' vs 'can_delete_all_messages') and the success return value. It stops short of mentioning edge cases such as missing messages or deletion age limits, but the core behavioral contract is present.

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 with no filler: the subject-action pair is first, followed by permission requirements and return behavior. Every sentence adds operational 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?

For a two-parameter, no-nested-schema tool, the description covers authorization, target scope, and return value, and the schema covers parameter constraints. It could be slightly stronger by routing to alternatives or noting partial-failure behavior, but nothing essential to invoking it correctly is missing.

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 both business_connection_id and message_ids meaningfully documented. The description adds no parameter-level detail beyond the schema, so the 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 opens with a specific verb and resource: 'Deletes messages on behalf of a business account.' The 'business account' qualifier distinguishes it from siblings like deleteMessage and deleteMessages, which target ordinary chat 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?

The description implies the tool is for business-account message deletion and specifies required permissions, but it does not explicitly contrast it with deleteMessage/deleteMessages or state when not to use it. The usage context is inferable rather than articulated.

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 required permission, a scope limitation (private chats), and the success return value (True). This covers the key behavioral aspects for a simple deletion endpoint, though it doesn't detail failure modes or edge cases like a missing photo.

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 concise sentences, each carrying distinct value: the action, the limitations/prerequisite, and the return value. Front-loaded with the core purpose and 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 one-parameter, side-effect-focused method with no output schema and no annotations, this description covers the essential aspects: what it does, who can use it, where it doesn't work, and what it returns. Nothing critical is missing.

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 single parameter chat_id is already fully documented in the schema with 100% coverage. The description adds no further parameter-specific 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 uses a specific verb ('Delete') with a clear resource ('chat photo'), making the operation unmistakable. It naturally contrasts with sibling setChatPhoto, so an agent can distinguish them without comparing schemas.

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 usage context: the bot must be an administrator with can_change_info rights, and it notes that photos can't be changed for private chats, effectively excluding private chat targets. It doesn't explicitly name alternative tools, but the prerequisite and limitation are useful 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 the required permissions, a way to check eligibility, and the success return value (True). It does not state whether the deletion is irreversible or that the sticker set itself is not deleted globally, but it covers the most critical behavioral aspects.

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 sentences contain only necessary information: the action, the permission requirement, the verification method, and the return value. It is front-loaded with the core purpose and has no 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 low-complexity tool with one parameter and no output schema, the description is complete: it explains what the tool does, prerequisites, how to check them, and what the caller will receive. Nothing essential is missing 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 coverage is 100%, so the single chat_id parameter is already fully documented in the schema. The description adds no parameter-specific detail beyond what the schema provides, 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 the action: deleting a group sticker set from a supergroup. This distinguishes it from sibling tools like deleteStickerSet and setChatStickerSet by specifying the target scope ('from a supergroup').

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 preconditions: the bot must be an administrator with can_change_info rights. It also tells the agent how to verify readiness using the can_set_sticker_set field from getChat, which is practical usage guidance. It does not explicitly mention alternatives, but the context is 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 carries the full burden. It explicitly discloses the destructive scope (topic plus all its messages), the required authorization, and the success return value. It does not mention irreversible consequences or error behavior, but the core behavioral traits are 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 two concise sentences with no wasted words. The core action and scope are front-loaded, followed by the permission requirement and return value. Every sentence provides necessary 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?

For a two-parameter tool with full schema coverage and no output schema, the description covers the essential context: what is deleted, where it applies, what permission is needed, and the success return value. Nothing critical is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already fully documents both chat_id and message_thread_id. The description adds no additional parameter-level meaning, which is acceptable given the baseline; it does not create ambiguity.

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 ('delete') with a precise resource ('forum topic... in a forum supergroup chat') and clearly states the full scope ('along with all its messages'). This distinguishes it from sibling tools like closeForumTopic or editForumTopic without needing to inspect their schemas.

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 prerequisite: the bot must be an administrator with can_delete_messages rights. It does not explicitly name alternatives or state 'use this instead of closeForumTopic', but the destructive scope and required permission make the intended usage 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 carries the full behavioral burden and does so thoroughly. It discloses deletion limitations, the 48-hour window, specific exceptions for dice messages and creation service messages, permission requirements across chat types, and the success return value. This is far beyond the bare operation name.

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

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

The description is long but every sentence adds necessary information about deletion constraints and permissions. It is front-loaded with the core action and the most important qualifier. It could be tightened with bullet points for readability, but there is no wasted 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?

Given a simple two-parameter tool with no annotations and no output schema, this description is unusually complete. It covers all essential edge cases: service messages, time limits, dice messages, bot permissions, channel/supergroup/group behavior, and the return value. An agent has enough information to know when the call will succeed or fail.

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 both parameters fully, including chat_id format and message_id meaning, with 100% schema description coverage. The description adds no extra parameter-level detail beyond what the schema provides, 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 begins with 'Delete a message' which is a specific verb and resource, and adds the key qualifier 'including service messages.' It clearly identifies the tool's function and is distinguishable from the sibling deleteMessages, which targets multiple 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?

The description provides rich context on when deletion is allowed, including time limits, message types, bot permissions, and chat types. However, it does not explicitly compare against the sibling deleteMessages tool or state when to prefer one over the other, so it lacks explicit alternative routing.

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 disclosure burden, and it does add value: the partial-failure behavior (missing messages are skipped) and the return value are both stated. However, for a destructive batch operation it omits permanence/irreversibility and permission requirements (e.g., bots can only delete their own messages in groups), which a no-annotation tool should disclose.

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 sentences, each earning its place: the action, the partial-failure behavior, and the return value. The primary action is front-loaded and there is zero redundant wording.

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 2-parameter tool with no output schema, the description plus rich schema is nearly complete: behavior, partial failure, and return value are covered, and the schema supplies parameter details and points to deleteMessage for deletion limitations. It falls just short of exhaustive because error semantics on total failure (e.g., invalid chat_id) and irreversibility are not stated.

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%: chat_id documents the identifier/channel-username forms and message_ids documents the 1-100 JSON-serialized list plus a cross-reference to deleteMessage limitations. The description adds a genuine semantic bonus by clarifying that message_ids may reference non-existent messages without causing failure, since they are skipped.

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 ('Delete'), resource (messages), and scope ('multiple... simultaneously'), which directly distinguishes it from the singular sibling deleteMessage. An agent can identify this as the batch deletion variant without opening the schema.

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 makes the batch use case explicit ('Delete multiple messages simultaneously'), and the skip-on-missing note tells agents they can pass a set of IDs without pre-validating them. It does not explicitly name alternatives or state exclusions, though the schema's reference to 'See deleteMessage for limitations' partially covers the single-message path.

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 states the destructive action and the 'Returns True on success' outcome, which is useful. However, it does not disclose any side effects, reversibility, or how this interacts with previously set commands, so the behavioral disclosure is only partially complete.

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. It clearly states the action, the scope qualifier, and the return value in minimal words — 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 two-parameter tool with a fully documented schema, the description is adequate. It states the operation and success return, while the schema covers parameter defaults. However, without annotations, it omits any guidance on when to avoid this operation or consequences beyond deletion, leaving some context for the agent to infer.

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 both scope and language_code already explained. The description mentions 'given scope and language' but adds no new parameter-specific 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 uses a specific verb ('Delete'), names the resource ('list of bot commands'), and qualifies by scope and language. It clearly distinguishes from siblings like setMyCommands and getMyCommands through the verb, though it does not explicitly name an alternative.

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 given on when to use this tool versus setMyCommands or getMyCommands. The description does not state conditions, exclusions, or prerequisites, leaving the agent to infer usage solely from the tool name and context.

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

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 clearly communicates the destructive action ('Delete') and the 'created by the bot' precondition, and it states the success return value. However, it does not mention irreversibility, failure behavior, or any permissions needed, though for a simple delete operation this is a moderate 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 one concise sentence that front-loads the action and resource, then gives the return behavior. Every word earns its place, with no filler or repetition.

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, the description is complete: it names the operation, restricts it to bot-created sets, and states the return value. The schema covers the parameter fully, and the sibling list does not reveal any missing edge case that would prevent an agent from invoking this 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 description coverage is 100%, and the sole parameter 'sticker' is already documented as 'File identifier of the sticker.' The description adds no additional parameter 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 uses a specific verb ('Delete') and states the exact resource: a sticker within a set created by the bot. It also distinguishes itself from sibling tools like deleteStickerSet by clarifying it removes a single sticker, not the entire set.

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 usage context: use this when you need to remove one sticker from a bot-created sticker set. However, it does not explicitly contrast with alternatives such as deleteStickerSet, replaceStickerInSet, or setStickerPositionInSet, leaving selection partly 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 clearly states the destructive nature ('Delete'), the prerequisite scope ('created by the bot'), and the success return value ('Returns True on success'). This is sufficient for a straightforward deletion operation, though it could hint at irreversibility more explicitly.

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 crisp sentence that front-loads the action and then states the return value. Every word adds value and there is no redundancy, making it easy for an agent to parse quickly.

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 destructive method with no output schema, the description is complete: it identifies the resource, the restriction, and the success return value. An agent has enough information to call the tool correctly without further clarification.

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 provides 100% coverage for the single 'name' parameter with its own description ('Sticker set name'). The tool description adds no additional details about format, length, or usage constraints beyond what the schema supplies, 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 a specific verb ('Delete'), identifies the resource ('sticker set'), and adds a clear scope condition ('created by the bot'). This distinguishes it well from related siblings like deleteStickerFromSet, which operates on a single sticker, and deleteChatStickerSet, which targets a chat's sticker set.

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 'created by the bot' is a useful scoping hint and clearly indicates the intended target. However, the description does not explicitly say when not to use this tool or mention alternatives such as deleteStickerFromSet for removing individual stickers, leaving some routing 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, and it does a solid job: it discloses the required permission (can_manage_stories), limits the operation to bot-posted stories, and states the success return value (True). It does not cover failure behavior or irreversibility in depth, but 'Deletes' already signals destructive intent.

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 with no filler: the main action is front-loaded, followed by the permission requirement and the return value. Every sentence earns its place, and the entire definition can be processed quickly.

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, two-parameter delete operation with no output schema, the description covers the action, scope, authorization, and success response. The only meaningful gap is failure semantics (e.g., what happens when the story does not exist), which is a minor omission given how direct the operation is.

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, but the description adds meaning beyond the schema's generic 'unique identifier' phrasing. It clarifies that story_id refers to a bot-posted story and that business_connection_id belongs to a managed business account, which helps an agent map the parameters correctly.

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 names a specific verb ('Deletes') and a precise resource ('a story previously posted by the bot on behalf of a managed business account'), which clearly separates it from sibling tools like deleteMessage, deleteBusinessMessages, or editStory. Adding the permission requirement further pins down 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 for when the tool applies: the story must be one previously posted by the bot, the account must be a managed business account, and the can_manage_stories bot right is required. It names no explicit alternatives or exclusion cases, but the conditions given are specific enough for an agent to select this tool correctly.

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 transparency burden. It names the destructive target (webhook integration) and reveals a behavioral consequence (updates must be polled via getUpdates afterward). However, it does not disclose what happens to pending updates by default or the success return value, leaving side effects partially opaque.

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 with zero filler. The core action is front-loaded, and the follow-up guidance about getUpdates 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 low-complexity tool with one optional parameter and no output schema, the description is nearly complete: it states the action and the post-action update channel. A note about pending updates default behavior or the boolean success response would make it fully complete, but nothing essential is missing 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 coverage is 100%, and the sole optional parameter already has a clear description in the input schema. The tool description adds no parameter-level detail, but none is necessary here since the schema fully documents the parameter.

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 a specific verb ('Remove') and a clear resource ('webhook integration'), stating exactly what the tool does. This also distinguishes it from siblings like setWebhook and getWebhookInfo without requiring inspection of their schemas.

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 useful post-action routing hint ('Use getUpdates to receive updates after this'), but it gives no explicit condition for choosing deleteWebhook over alternatives such as setWebhook or getWebhookInfo. The main usage context is only implied by the verb 'Remove'.

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 that the operation mutates an existing link, requires can_invite_users permission, and returns the edited ChatInviteLink object. This is more transparent than typical, though it does not discuss side effects like replacement of the previous link.

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 compact sentences, each earning its place: the purpose, the permission requirement, and the return type. No filler or repetition of 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?

For a tool with no annotations and no output schema, the description adequately covers purpose, permissions, and return type. It could be more complete by explicitly contrasting with editChatSubscriptionInviteLink or stating that primary/subscription links are out of scope.

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 6 parameters, so the baseline is 3, but the description adds meaningful semantic constraints: the invite_link parameter must be non-primary and bot-created. These constraints are absent from the schema and help agents select the right link 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 (Edit), a precise target (non-primary invite link), and an ownership constraint (created by the bot). This is enough to distinguish it from create/revoke/export invite-link sibling tools and from subscription-link editing.

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 a clear prerequisite (bot must be administrator with can_invite_users rights) and scopes use to non-primary links created by the bot. It does not explicitly name alternatives or call out when to use editChatSubscriptionInviteLink instead, so it stops short of full routing 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 disclosure burden. It does disclose the permission requirement and that the return value is a ChatInviteLink object, which is helpful. However, it does not mention possible side effects of editing, failure modes, or idempotency for a mutation 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 concise sentences with no filler: purpose first, then prerequisite and return type. Every clause adds useful 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?

For a simple three-parameter tool with fully described schema fields, the description supplies the key missing context: permission requirements and return type. A small gap is the lack of explicit contrast with editChatInviteLink, but the resource name and scope largely cover this.

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 three parameters. The description adds no additional parameter-level meaning beyond noting the return object, so the baseline score of 3 applies.

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

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

The description clearly states a specific action ('Edit'), a specific resource ('subscription invite link'), and scopes it to links 'created by the bot.' The term 'subscription' distinguishes this from the sibling editChatInviteLink for ordinary invite links without needing to open the schema.

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 a useful prerequisite ('bot must have can_invite_users administrator rights') and narrows applicability to subscription invite links created by the bot. However, it does not explicitly contrast with alternatives like createChatSubscriptionInviteLink or editChatInviteLink, so the selection logic is mostly 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. It discloses the required permission, the fact that the operation is a mutation, and the return behavior ('Returns True on success'). This is substantial behavioral context for a small edit 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?

Two sentences with zero redundancy. The main purpose is front-loaded, followed by the permission requirement and return value. 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?

For a simple edit operation with four well-documented parameters, the description covers the essential operational facts: what it does, required permissions, and return value. No critical information is missing for an agent to invoke it correctly.

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

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 four parameters in detail. The description adds minimal parameter-level information beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description states a specific verb ('Edit') and resource ('forum topic'), and narrows the operation to 'name and icon'. This clearly distinguishes it from siblings like createForumTopic, closeForumTopic, and editGeneralForumTopic.

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 usage condition: the bot must be an administrator with can_manage_topics rights. It does not explicitly mention alternatives or exclusions, but the condition and scope make the intended use reasonably 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?

No annotations are provided, so the description carries the behavioral burden. It discloses the permission requirement and the success return value ('Returns True on success'). It does not describe failure behaviors or side effects, but for a simple rename operation these are adequate and the key conditions are 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?

Two terse sentences with zero filler. The action is front-loaded, the required permission follows immediately, and the return value is included. 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?

For a simple 2-parameter tool with no output schema, the description covers the essential operational context: the target resource, the required permission, and the success result. It lacks sibling routing and failure-mode detail, but nothing critical is missing 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 description coverage is 100%, so both parameters are already documented with types and descriptions. The description adds no additional parameter-level detail beyond loosely referencing 'name' and 'forum supergroup chat'. Baseline 3 is appropriate because the schema already carries the semantic load.

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 the exact operation: 'Edit the name of the 'General' topic in a forum supergroup chat.' This clearly identifies the verb, resource, and scope, and inherently distinguishes the tool from sibling editForumTopic which targets regular topics. The quoted 'General' makes the target 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 a clear prerequisite: the bot must be an administrator with can_manage_topics rights. However, it does not explicitly state when to use this tool versus editForumTopic for non-General topics or other General-topic management actions like hideGeneralForumTopic or closeGeneralForumTopic. The usage context is implied, but alternatives are not delineated.

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 disclosure burden. It does surface one genuinely useful behavioral trait — the divergent return value for inline messages (True instead of the edited Message). However, it stays silent on prerequisites (bot must have sent the message or hold edit rights), failure conditions, and the fact that only the caption is modified while media/text remain untouched.

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 with zero filler. The core operation is front-loaded, and the return-value caveat follows immediately; both sentences earn their 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 9-parameter mutation tool with no annotations and no output schema, the description is thin. It omits the conditional addressing requirement (chat_id+message_id XOR inline_message_id), which an agent would only discover by reading schema parameter descriptions, and offers no guidance on supported message types or when editing is not permitted. The return-value disclosure partially compensates, but an agent reading the description alone would miss key invocation preconditions.

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 the parameter descriptions are rich (e.g., 'Required if inline_message_id is not specified', @channelusername format, and the media-type constraint on show_caption_above_media). The tool description adds no parameter-level meaning, but at full coverage the baseline of 3 applies — the schema already 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 opens with the specific operation 'Edit captions of messages' — a precise verb+resource pairing that distinguishes it from the many sibling edit tools (editMessageText, editMessageMedia, editMessageReplyMarkup). It also discloses the return contract (edited Message vs True for inline messages), removing ambiguity about what the caller receives.

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 purpose statement implies the use case — changing a message's caption — but it never explicitly routes the agent away from siblings like editMessageText, nor does it flag the mutually exclusive addressing modes (chat_id+message_id vs inline_message_id). No alternatives or exclusions are named; the guidance is only implied.

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

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

No annotations are provided, so the description carries the behavioral transparency burden. It discloses the temporal edit constraint, the stopMessageLiveLocation escape hatch, and the return behavior for inline vs. non-inline messages. It omits permissions and failure modes, but the core side effects and boundaries are clearly 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?

Two compact sentences with no fluff. The core operation is front-loaded, followed by the key boundary condition and return type. 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?

With 11 parameters, a nested reply_markup object, and no output schema, the description supplies essential lifecycle and return-value context that the schema cannot convey. It does not mention every restriction, such as the message having been sent by the bot, but the rich schema plus focused description is largely sufficient.

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 each parameter and its conditional requirements. The description adds no parameter-level detail, which is acceptable given the high schema coverage 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 states a specific verb ('Edit') and resource ('live location messages'), which clearly distinguishes it from sibling edit tools like editMessageText and editMessageMedia. The lifecycle sentence about live_period and stopMessageLiveLocation further anchors exactly which messages this tool targets.

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 usage context by explaining when editing is allowed (until live_period expires or stopMessageLiveLocation is called). It does not explicitly exclude sibling tools like editMessageText or editMessageCaption, but the context strongly implies this is only for live location messages.

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 disclosure burden. It adds meaningful behavioral detail beyond the schema: album editing restrictions and the distinct return type for inline messages (True instead of Message). It does not cover permissions, ownership requirements, or irreversible replacement of old media, so it is not a 5.

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: purpose first, then the key constraint, then the return behavior. Every sentence contributes unique information with no filler or repetition.

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 nested media object, no annotations, and no output schema, the description covers the most important behavior: supported media, album limitations, and return values. The schema handles parameter semantics. Some context is still missing, such as whether only messages sent by the bot can be edited and what happens to the original text when media is added.

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 extra semantic context for the media parameter by defining what media types can be edited, how album membership constrains those types, and the special case of adding media to text messages—details not present in the schema itself.

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: editing the media of existing messages, and explicitly lists supported media types plus the 'add media to text messages' case. This clearly differentiates it from sibling tools like editMessageText, editMessageCaption, and editMessageReplyMarkup.

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 makes clear this tool is for editing media and adds album-specific constraints, but it does not explicitly contrast with sibling tools or state when to use editMessageText/editMessageCaption instead. Usage context is implied rather than explicitly delimited.

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 carry behavioral disclosure. It does disclose the operation ('edit only reply markup') and the return behavior (edited Message or True for inline messages), but it does not mention permission requirements, the effect of passing an empty reply_markup (removing the keyboard), or reversibility.

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?

One compact sentence front-loads the action and scope, then gives the return behavior. Every clause contributes essential information with no 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 covers the tool's purpose and return values, which is needed since there is no output schema. Conditional parameter requirements and inline_message_id semantics are already described in the schema, so the main gap is the lack of explicit alternative routing, which is minor.

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 provides full descriptions for all 5 parameters (100% coverage), so the baseline is 3. The description adds no parameter-level detail beyond 'reply markup' and return behavior, which do not enhance the schema's parameter information.

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 ('Edit') and precise resource ('reply markup of messages'), and the word 'only' explicitly narrows scope from sibling edit tools like editMessageText and editMessageCaption. This makes the tool's role 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 limitation 'only the reply markup' implicitly tells the agent to choose this tool when just the inline keyboard needs changing, not text/caption/media. However, it does not explicitly name alternatives or state when not to use it, so the guidance 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?

With no annotations, the description carries the full burden. It discloses the mutating nature of the operation and specifies the return behavior (edited Message vs True for inline messages). But it does not mention constraints such as message ownership, edit time limits, or other side effects that would give an agent a fuller behavioral picture.

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 action, scope, and return behavior without any filler. Every piece of information contributes to an agent's 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?

Although there is no output schema, the description covers the return type, and the schema thoroughly documents parameter requirements like the mutual exclusion of chat_id/message_id vs inline_message_id. Still, with nine parameters and nested options, the description offers no usage scenarios or limitations beyond what is already structured, leaving moderate gaps in 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond the schema, but it does not need to because every parameter is already well documented 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?

The description clearly states the action ('Edit') and the resource ('text and game messages'), which distinguishes it from sibling edit tools such as editMessageCaption, editMessageMedia, and editMessageReplyMarkup. The return-value note further clarifies that it covers both regular and inline 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?

The scope is implied by the resource mention — text and game messages — so an agent can infer this is not for captions, media, or reply markup. However, the description does not explicitly name alternative tools or state when not to use this one, leaving the routing 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?

No annotations are provided, so the description carries the full burden. It discloses the authorization requirement (can_manage_stories business bot right) and the success outcome (returns a Story object), which are useful behavioral facts beyond what the name alone conveys. It does not detail whether the edit irreversibly replaces content, but the action is stated clearly.

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 concise sentences with no filler: the operation is front-loaded, followed by the required permission and the return type. 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?

For a 7-parameter edit operation with nested objects and no output schema, the description supplies the important operational scope, the permission precondition, and the return type. The schema already documents parameter semantics, so the description is sufficiently complete for an agent to call 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 has 100% description coverage: every parameter, including business_connection_id, story_id, content, caption, parse_mode, caption_entities, and areas, has an explanatory description. The tool description adds no parameter-level detail, but the baseline of 3 is appropriate when the schema fully documents 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 a specific verb ('Edits') and a precise resource ('a story previously posted by the bot on behalf of a managed business account'). This clearly identifies the operation and distinguishes it from sibling story tools like postStory, deleteStory, and repostStory without needing to open the schema.

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: use this when editing an existing story that the bot previously posted, and it states a hard prerequisite (can_manage_stories business bot right). It does not explicitly name alternatives or exclusions, so it misses 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?

With no annotations present, the description carries the full behavioral burden. It does disclose the mutating nature of the operation and its success return value ('Returns True on success'), which is useful since no output schema exists. But it does not mention prerequisites (an active subscription period), failure behavior, or side effects of canceling vs. re-enabling beyond what the schema's is_canceled text already states.

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 with no filler. The core action is front-loaded and the return-value note is the only additional sentence, and it earns its place because there is no output schema. Every word contributes.

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 3-parameter mutation with no output schema, the description combined with the rich schema covers the core action and success return, making the tool callable. It is incomplete on usage context relative to payment-related siblings and on failure/prerequisite behavior, which matters for a state-changing operation with no annotations to back it up.

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%: each parameter (user_id, is_canceled, telegram_payment_charge_id) already has a meaningful schema description, including the subtle behavior constraint on is_canceled. The tool description adds useful domain context ('paid in Telegram Stars') that clarifies what telegram_payment_charge_id refers to, but adds no parameter-level detail, so the baseline 3 for high coverage 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 names a specific action pair ('cancel or re-enable extension') and a specific resource ('a subscription paid in Telegram Stars'), and scopes it to the bot. This clearly differentiates it from near-siblings like refundStarPayment (refunding a payment), getStarTransactions (read-only ledger), and sendInvoice/createInvoiceLink (creating new payment flows), so an agent can route correctly without opening the schema.

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 purpose statement implies the usage context: use this when the bot needs to toggle the renewal state of an existing Star subscription. However, it names no alternatives and gives no when-not-to-use guidance, even though the sibling list contains closely related payment tools such as refundStarPayment and getStarTransactions where explicit exclusions would help disambiguate.

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 behavioral burden and does so well. It discloses the destructive side effect (revoking any previously generated primary link), the permission requirement (bot must be admin with can_invite_users), and the success return type (String). This is exactly the kind of behavioral context an agent 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?

Three short sentences, with the core action front-loaded, followed by the side effect, permission prerequisite, and return value. Every sentence contributes necessary information with no 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 has one simple parameter, no output schema, and no annotations, the description is complete enough for correct invocation. It covers what the tool does, what side effects occur, who can use it, and what it returns.

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 only one parameter and its description already covers 100% of the parameter semantics. The tool description adds no additional parameter detail beyond the schema, which is acceptable given the 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 states a specific action ('Generate'), a specific resource ('primary invite link'), and the chat scope. It also notes that the previous primary link is revoked, which clearly distinguishes this tool from siblings like createChatInviteLink and revokeChatInviteLink by its role in the primary-link lifecycle.

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: this tool is for generating the primary invite link, with a revocation consequence and the required admin permission. It does not explicitly name alternatives or say when not to use it, but the 'primary' framing makes the intended use reasonably obvious amid the sibling invite-link tools.

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 discloses two important limitations (service messages and protected content cannot be forwarded) and the success return value. It could go further by noting required permissions or that the message is copied rather than moved, but the core behavioral constraints are present.

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 with no filler. The primary action is front-loaded, and the constraints and return value are stated efficiently. 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 description covers the core action, exceptions, and return value, and the schema documents all parameters. However, with no output schema and 10 parameters, plus closely related siblings like forwardMessages and copyMessage, the description should have provided more guidance on how this tool fits among them. 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?

Schema description coverage is 100%, so the input schema already documents all parameters. The description adds no parameter-level meaning beyond what the schema provides, 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 the action ('Forward messages') and the resource, and it adds meaningful scope ('of any kind') with constraints. However, it does not explicitly distinguish this single-message tool from the sibling forwardMessages, so differentiation is incomplete.

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 given on when to use this tool versus alternatives like forwardMessages, copyMessage, or sendMessage. The only usage-related information is a negative condition (service messages and protected content can't be forwarded), which does not help an agent choose among related forwarding/copying tools.

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 meaningful work by disclosing partial-failure semantics ('if some ... can't be found or forwarded, they are skipped'), restrictions on service messages and protected content, and that album grouping is preserved. This is above-average transparency for a mutation-like tool, though it omits permission or rate-limit 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 information-dense: four sentences, each adding a distinct useful fact. It front-loads the primary purpose and then covers failure behavior, content restrictions, grouping behavior, and return value. There is no redundant phrasing or restatement 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 batch forwarding method with fully documented parameters and no output schema, the description covers the important operational semantics: partial failures, non-forwardable content, album behavior, and the success return type. It does not spend space explaining return values in detail, which is acceptable without an output schema, but it could have noted permission requirements or contrast with copying alternatives.

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 seven parameters. The description adds a little contextual meaning by explaining that unspecified messages are skipped and album grouping is retained, which clarifies message_ids behavior. This meets the baseline but does not go beyond what a well-documented schema plus behavioral notes already provide.

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 core action: 'Forward multiple messages of any kind' and specifies the return type. It distinguishes itself from the singular forwardMessage by emphasizing batch operation and album grouping. However, it does not explicitly name sibling alternatives or contrast with copyMessages, so differentiation is partially left to the tool name and 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 no explicit guidance about when to choose forwardMessages over forwardMessage, copyMessages, or copyMessage. It implies batch usage by saying 'multiple messages' and describes skip behavior, but it never states conditions for selecting an alternative. This leaves the agent to infer usage boundaries from sibling names 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It says the method 'Returns' a list, which suggests a read operation, but it does not explicitly state that there are no side effects, that no authorization is needed, or whether the list has any ordering or other output 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 short and front-loads the primary behavior in the first sentence. The second sentence is mildly redundant because it repeats 'Returns', but it adds the precise object type, so it still contributes 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?

For a simple zero-parameter getter, the description adequately states the purpose and the return type. However, with no output schema and no annotations, it leaves the fine-grained return shape unspecified, such as whether the list is sorted or paginated.

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 and the schema description coverage is 100%, so there is no parameter information missing. Per the rubric, a no-parameter tool receives a baseline score of 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 uses a specific verb ('Returns') and identifies the exact resource: the list of gifts the bot can send to users and channel chats. This clearly distinguishes it from gift-related siblings such as sendGift, getUserGifts, and getChatGifts. It also states the return type, a Gifts object.

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 a clear context for when this tool is appropriate: when you need the bot-sendable gift catalog. However, it does not explicitly contrast it with sibling methods like getBusinessAccountGifts, getUserGifts, or getChatGifts, so an agent has to infer the boundary between them.

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