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 reveals that the tool acts as a bot and requires a token, but it does not warn that some methods may have side effects, require specific permissions, or behave unpredictably if misused. This is a generic arbitrary-method caller, so more cautionary context is warranted.

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 and useful examples. It is efficient, though its brevity comes at the cost of missing behavioral and parameter detail.

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 generic tool that invokes arbitrary Telegram Bot API methods, the description is too thin. It omits how the token is used, how params map to the chosen method, and the potential for destructive or state-changing calls. The presence of an output schema reduces the need to describe return values, but the core usage context is still incomplete.

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

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

Schema description coverage is 0%, so the description must compensate, but it only gives example values for 'method'. It does not explain what 'token' should be or how 'params' should be structured to match Telegram Bot API method arguments, leaving two of three parameters mostly unexplained.

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

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

The description clearly states the verb ('Call') and resource ('any Telegram Bot API method'), with concrete examples like 'setMyCommands' and 'sendMessage'. It is distinguishable from the sibling tools because it is a generic passthrough rather than a specialized wrapper, though it does not explicitly name or contrast any sibling.

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 'any Telegram Bot API method' implies this tool is for methods not covered by the specialized sibling tools, and the examples reinforce that. However, it does not explicitly say when to prefer this over siblings or when not to use it, leaving the guidance 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?

No annotations are present, so the description carries the full behavioral burden. It only says 'Get details' and lists entity types, but does not disclose what 'details' includes, how the chat value is resolved, or how authorization failures or invalid references behave.

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 clean, front-loaded sentence with no filler. It is compact and readable, though so terse that important semantic detail about the chat parameter was omitted.

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

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

Despite the simple schema and existing output schema, the definition lacks essential invocation context: what format chat accepts, when to choose this tool over sibling information tools, and what 'details' covers. An agent can guess the broad intent but cannot confidently invoke it correctly.

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

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

The single required parameter, chat, has 0% schema description coverage. The description implies chat can identify a user, bot, group, or channel, but it never states whether the value is an ID, username, or phone number, leaving invocation ambiguous.

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 operation precisely: 'Get details' and enumerates the target resource types: 'user, bot, group or channel.' This is clearly distinct from broad tools like list_chats or get_me, though it does not explicitly name any sibling alternatives.

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

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

There is no guidance on when to use this tool versus list_chats, get_participants, or get_me. The description only announces what the tool does, not when it should be preferred or what prerequisite information the caller needs.

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 bears the full burden. It explains how to identify a button but does not disclose side effects (e.g., triggering a callback), error behavior if the button is not found, or whether the click is reversible. No behavior beyond the identification method is described.

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 entire definition is one front-loaded sentence with zero wasted words. It states the action first, then the selection modes, all without redundancy.

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

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

Despite being a relatively simple tool, the lack of annotations and 0% schema coverage leave the description as the only guidance. It omits the required chat parameter, does not explain the meaning of row/column in the keyboard layout, and provides no behavioral or error context. This is insufficient for an agent to reliably 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 description coverage is 0%, so the description must compensate. It explains text matching ('part of its text') and row/column (0-based), but omits the 'chat' parameter entirely and does not clarify that chat and message_id are required. The phrase 'under a message' only implies message_id.

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

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

The description clearly states the action ('Press a keyboard button under a message') and the resource (a message's keyboard button), with specific identification methods. It is distinct from all sibling tools, 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?

There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites such as the message containing an inline keyboard. Context is implied by the action but not explicitly 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, the description carries the behavioral burden. It discloses the creation mechanism (@BotFather), a validation rule (username must end with 'bot'), and the return value (bot token), which are genuinely useful. It does not mention error cases or token security, but the core behavior 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 a single tight sentence containing the essential action, the key constraint, and the return value. Every clause earns its place 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?

For a simple two-parameter creation tool with an output schema, the description covers the critical information: how the bot is created, the username rule, and the token. Minor gaps like clarifying the 'name' parameter and failure modes remain, but the tool is still actionable.

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 0%, so the description must compensate. It clearly explains the username constraint, but the 'name' parameter is only implicitly understood as the bot's display name. The description adds meaning for one parameter but leaves the other to inference.

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: 'Create a new bot via @BotFather.' It clearly distinguishes this from sibling tools like create_channel and create_group, and the username constraint further reinforces that this is bot creation rather than a general API wrapper.

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 creating a Telegram bot and even mentions @BotFather, which gives useful context. However, it does not explicitly state when to prefer this over related tools like bot_api or talk_to_bot, nor does it give exclusion criteria.

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

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

With no annotations, the description must carry the full behavioral burden. It mentions that megagroup=True creates a supergroup and username is optional, but it does not disclose permissions, reversibility, side effects, or any constraints. It is a create operation, but no further context is given.

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, compact sentence with no redundancy. The main action is front-loaded, and the optional megagroup and username details follow logically.

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

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

The tool has 4 parameters, an output schema, and no annotations. The description leaves gaps: it does not explain the 'about' parameter, the distinction between channel and supergroup beyond the megagroup flag, or expected username format. An agent would need to inspect the schema or guess.

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 0%, so the description must compensate. It explains the megagroup parameter's effect and username optionality, which adds meaning beyond the schema's bare definitions. However, it does not explain the 'about' parameter or clarify username format (e.g., whether @ is included), so coverage is incomplete.

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

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

The description clearly states the action (create a channel) and specifies the resource (channel/supergroup). It distinguishes itself from create_group by focusing on channels, and the megagroup option adds specificity. The optional username is also mentioned.

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

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

No explicit guidance on when to use this tool vs alternatives like create_group or join_chat. The description does not mention any exclusions or conditions for selection, leaving the agent to infer usage from the tool name alone.

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

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

There are no annotations, so the description carries the full burden. It correctly implies a mutating operation, but it does not disclose side effects, permission requirements, failure behavior, or any constraints on the group creation.

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 or redundancy. Every word contributes to the core message, which is appropriate for a simple creation tool.

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

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

The output schema covers return values and the parameter set is small, but the description still lacks usage context and behavioral caveats that an agent would need when deciding to call this tool. It is minimally informative but not complete enough for confident 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 0%, but the phrase 'with the given users' adds meaning by indicating that the users array specifies initial members. However, the title parameter is left entirely implicit and no additional value is provided for it.

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') and a clear resource ('a basic group'), and it identifies the key input ('with the given users'). This is enough for an agent to distinguish it from siblings like create_channel at a glance.

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 about when to use this tool versus alternatives such as create_channel or invite_users. The word 'basic' hints at a scope distinction but does not explain it, leaving the agent to infer usage.

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 partially carries the behavioral burden by explaining that revoke=True deletes for everyone. However, it does not disclose irreversibility, permission requirements, self-only deletion for revoke=False, or potential 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 one focused sentence that front-loads the core action and adds the most important qualifier. 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 destructive multi-parameter operation with no annotations, the description is incomplete. It lacks usage guidance, side effects, permission requirements, and enough parameter detail for the agent to invoke it correctly without additional inference.

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 0%, so the description must compensate. It only clarifies the revoke parameter; chat and message_ids receive no semantic explanation beyond their names and types, and the behavior of revoke=False is only implied.

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 operation and resource: 'Delete messages' and explains the revoke qualifier. It is unambiguous, though it does not explicitly distinguish itself from sibling message-mutation 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?

No guidance is given about when to use delete_messages versus alternatives such as edit_message, pin_message, or leave_chat, nor are prerequisites, exclusions, or limitations mentioned. The agent must infer usage solely from the tool name.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says it downloads and returns a saved path, but doesn't mention whether the media is saved locally, what happens if there is no media, or any permission/auth requirements. For a tool that creates a file side effect, this is a significant gap.

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

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

The description is a single sentence of 12 words, which is very concise. It front-loads the key action and the return value. Though it could benefit from one or two more clarifications, it is appropriately sized without unnecessary fluff.

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

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

Given the output schema exists (likely includes the saved path), the description need not explain the return type further, but for a tool that downloads media, an agent would need to know prerequisites (e.g., does the chat have media? what message types are supported?), error conditions, and how 'directory' is used. The information is insufficient for a reliable call, especially with no annotations. The presence of sibling send_file makes the differentiation gap more important.

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

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

The schema description coverage is 0%, so the description must compensate for the parameters. However, the description only explains the return value, not the meaning of 'chat' or 'message_id' beyond their names. It does not specify the format of 'directory' (e.g., must be absolute path) or behavior when 'directory' is omitted. Since the schema provides titles but no descriptions, the description adds minimal value, resulting in a score 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 action (download) and the resource (media attached to a message), and mentions it returns a file path. It is clear but does not explicitly differentiate from send_file, which is a sibling that also handles files, so it loses one point.

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

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

There is no mention of when to use this tool versus send_file or other media-related operations. No exclusions or alternatives are stated, so the description provides minimal guidance for the agent to choose this tool over 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 behavioral disclosure. It only states that the tool edits a message, without mentioning side effects, permissions, reversibility, or constraints like message age or ownership verification.

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, waste-free sentence, which is concise. However, it is under-specified to the point of providing minimal useful information beyond the tool name, so it is not appropriately sized for the tool's complexity.

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

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

With no annotations and 4 parameters at 0% schema coverage, the description is far from complete. It does not explain required context such as message ownership, edit constraints, or how parse_mode behaves, even though an output schema exists.

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 0%, so the description must compensate by explaining parameters. It does not mention chat, message_id, text, or parse_mode at all, leaving the agent to infer their meanings solely from the schema field names.

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') and a specific resource ('one of your messages'), establishing ownership scope. It implicitly distinguishes from siblings like send_message or delete_messages, though it does not name 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?

The phrase 'one of your messages' implies usage for modifying an existing message you sent, but it does not provide explicit when-to-use or when-not-to-use context, nor does it name alternative tools for comparison.

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 disclose side effects and constraints. It conveys the basic forward action but does not state whether original messages are left intact, whether permissions are needed, what happens on invalid message_ids, or any rate-limit/auth considerations.

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 short, front-loaded sentence states the core operation with no filler or redundant repetition of the tool name. It is easy to parse and wastes no 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?

Although an output schema exists, the description lacks behavioral, usage, and parameter context that an agent needs to invoke the tool confidently. A simple operation, but absent any annotation support it is too sparse to be considered 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 0%, so the description should clarify parameters. It broadly maps 'from one chat' to from_chat, 'another' to to_chat, and 'messages' to message_ids, but it does not define expected ID formats, the relationship between message_ids and from_chat, or ordering/duplication behavior.

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 ('Forward') with a clear resource ('messages') and a directional relationship ('from one chat to another'). This distinguishes it from siblings like send_message or delete_messages, making the tool's purpose immediately unambiguous.

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

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

No guidance is given about when to choose forwarding over send_message or other message operations, and no exclusions or prerequisites are stated. The usage context is left entirely to inference from the tool name.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'Return' implies a read-only operation, but the description does not explicitly state that it has no side effects, requires no arguments, or may require authentication. This is adequate for a trivial getter but leaves some behavioral traits implicit.

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

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

The description is one short sentence that immediately states the tool's action and target. It contains no filler and is perfectly 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 zero-parameter tool with an output schema, the description fully covers what the agent needs: it returns the logged-in Telegram account. There are no hidden arguments, prerequisites, or ambiguous behaviors that would impair correct invocation.

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

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

The tool has zero parameters and the schema already documents this fully. There is nothing for the description to add about parameter meaning, so the baseline score 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 uses a specific verb ('Return') and resource ('logged-in Telegram account'), clearly indicating this tool fetches the current user's identity. It is immediately distinguishable from siblings like chat_info or list_chats, which concern chats rather than the authenticated account.

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 usage context clear: use this when you need the logged-in Telegram account. It does not explicitly discuss alternatives or exclusions, but there is no overlapping sibling tool that retrieves the current account, so the guidance is sufficient for correct 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 provided, the description carries the burden of behavioral disclosure. It mentions a permission caveat (admin rights for channels), which is valuable, but omits other behavioral aspects such as pagination behavior, search semantics, or error cases. Partial disclosure only.

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

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

The description is a single concise sentence with a useful parenthetical. It is front-loaded and free of fluff. It could include more parameter detail without becoming bloated, but it is appropriately compact.

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

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

An output schema exists, so return values need not be explained. However, for a 3-parameter tool with no annotations and 0% schema coverage, the description should at least hint at the optional limit/search parameters and when they matter. It does not, leaving the agent to infer from schema defaults.

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 0%, so the description must compensate. It clarifies that 'chat' refers to a group or channel, but gives no meaning for 'limit' or 'search'. With three parameters and no parametric detail in the description, this is a significant gap.

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

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

The description states a clear verb and resource: 'List members of a group or channel.' It distinguishes from siblings like list_chats or chat_info by focusing on the participant list itself, though it does not explicitly reference alternative 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 parenthetical 'admin rights may be needed for channels' provides a prerequisite/context, but the description does not indicate when to prefer this tool over alternatives or mention any exclusions. Usage is implied but not explicit.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the basic action and does not mention side effects, permission requirements, duplicate handling, or failure behavior. While not misleading, it adds essentially no transparency beyond the operation itself.

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 wasted words. It is appropriately concise for such a simple action, though it is minimal to the point of lacking detail that other dimensions penalize.

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

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

While an output schema exists, the description omits important operational context such as whether the caller must be an admin/owner, whether users must already exist, and what happens with invalid input. Given the tool's mutation nature and lack of annotations, the description is too sparse to be considered complete.

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

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

The schema has 0% description coverage for both parameters. The description maps 'group or channel' to the chat parameter and 'users' to the users array, but does not specify formats (IDs vs names), constraints, or semantics beyond that minimal mapping. This is insufficient given the low schema coverage.

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

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

The description clearly states a specific verb ('Add') and resource ('users') with a target ('group or channel'). It naturally differentiates from siblings like join_chat (self-invite) and create_channel/create_group (entity creation). Although it doesn't name siblings, the action is unambiguous in 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 provides no guidance on when to use this tool versus alternatives, no exclusions, and no conditions. It simply states the action, leaving the agent to infer that it should be used when adding users to an existing chat. No mention of required permissions or comparison with join_chat.

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

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

No annotations are provided, so the description carries the full behavioral burden. It explains what target formats are accepted but does not disclose the membership-changing effect, prerequisites, failure modes, or consequences of joining. This is a noticeable gap for a mutating action.

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

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

The description is a single efficient sentence, front-loaded with the primary verb and resource, and every word adds useful information. There is no filler or redundant repetition 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 one-parameter tool with an output schema, the description is largely sufficient: it specifies the target input forms and the action. It could add a note about prerequisites or side effects, but the low complexity keeps this from being a major gap.

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

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

Schema coverage is 0%, but the description compensates by explaining that target can be a @username or link for public chats, or a t.me/+invite link for private ones. This adds meaningful format semantics that the bare 'target' property name does not convey.

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

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

The description states a clear verb and resource: it joins an existing public or private group/channel, and it details the accepted target forms. It does not explicitly contrast itself with sibling tools like create_channel or leave_chat, but the action and resource are unambiguous.

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

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

No guidance is given about when to use this tool versus alternatives such as create_group, create_channel, or leave_chat. The intended use is implied by the name and description, but there are no explicit exclusions or decision criteria.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys that the operation mutates state ('leave' or 'delete'), but does not mention irreversibility, permissions required, effects on messages, or what happens to the dialog after deletion. This is minimal disclosure for a destructive-looking operation.

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

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

The description is a single concise sentence with no filler or redundancy. The core action and resource types are front-loaded, making it easy to scan and understand 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 mutation tool with no annotations and a single undocumented required parameter, the description is too thin. It does not explain how to identify the chat, what side effects occur, or how the operation differs for private dialogs versus groups/channels. An agent would likely need external knowledge or trial and error to call it correctly.

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

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

The schema has one required parameter, 'chat', with 0% description coverage in the schema, and the tool description adds no explanation of what 'chat' should be (ID, username, URL, etc.). The description fails to compensate for the schema gap, leaving the agent to guess the parameter format and semantics.

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 ('Leave'/'delete') applied to clear resources ('group/channel' and 'private dialog'), which distinguishes it from sibling tools like join_chat, create_group, and get_participants. An agent can immediately understand what the tool does without needing additional 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 guidance on when to use this tool versus alternatives such as join_chat, delete_messages, or chat_info. There are no explicit conditions, prerequisites, or exclusions, so the agent must infer usage from the tool name and the sibling list.

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

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

No annotations are provided, so the description carries the full burden. It discloses ordering ('newest first') and the filter capability, but doesn't mention pagination behavior, whether archived chats are included by default, or what the response shape is. For a read-only listing tool, the lack of behavioral detail beyond ordering is a gap.

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

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

Two sentences, front-loaded with the core action and scope, then the filter hint. No wasted words, though the second sentence could have been more informative about the other parameters.

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

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

The tool has an output schema, so return values are covered. But with 4 parameters at 0% schema coverage and no annotations, the description should explain the key parameters (limit, archived, unread_only) and any default filtering behavior. It's adequate for a simple list tool but leaves meaningful gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It explains `query` ('Filter by title') but says nothing about `limit`, `archived`, or `unread_only`. The description adds some meaning for one parameter but leaves three parameters entirely to the schema, which only provides names and defaults.

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 ('List') and resource ('dialogs'), and enumerates the dialog types (private chats, groups, channels, bots) plus ordering ('newest first'). It distinguishes itself from sibling tools like chat_info and read_messages, though it doesn't explicitly name a sibling 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?

The description implies usage context: it's the listing/exploration tool for dialogs, and the `query` filter is mentioned. However, it doesn't explicitly state when to use this vs. alternatives like search_messages or chat_info, nor does it mention exclusions (e.g., archived chats are hidden by default).

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the primary side effect (marking messages read) but does not disclose whether this affects all chat participants or only the current user, whether the action is reversible, or any permission requirements. This is minimal at best.

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, clear sentence with no redundancy; it is concise and front-loaded with the action. It could carry slightly more useful context without harming brevity, but it does not waste 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 tool with a single parameter and an existing output schema, this description is minimally sufficient to understand the basic action and invoke it correctly. However, it lacks usage context and behavioral caveats, and with a confusable sibling present, an agent might not reliably choose this tool over 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 0%, so the description must compensate for the unidentified 'chat' parameter. The phrase 'in a chat' indicates that the parameter identifies a chat, but it does not specify whether the value should be a chat ID, name, or another identifier, nor the expected format.

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 ('mark') and resource ('all messages in a chat as read'), making the core action clear. However, it does not explicitly differentiate from the sibling tool 'read_messages', which could be interpreted as the same action; a brief note that this tool does not fetch message contents would remove 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?

There is no guidance on when to use this tool versus alternatives like 'read_messages' or 'list_chats'. The description only states what it does, leaving the agent to infer appropriate use cases without any exclusions, prerequisites, or 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects such as notifying participants, permission requirements, reversibility, or idempotency, leaving important behavioral traits undisclosed.

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 conveys the core action and scope efficiently, though the brevity contributes to gaps in other dimensions.

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

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

Given the absence of annotations, zero parameter documentation, and an output schema not elaborated in the description, this tool definition is too sparse. An agent would need additional context about how to supply chat and message_id, and what 'notify' does, to invoke it confidently.

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

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

Schema description coverage is 0%, so the description must compensate, but it only hints at the 'chat' parameter by mentioning 'chat or channel'. It does not explain message_id semantics, how chat should be formatted, or what the 'notify' flag controls, providing minimal added value over the raw 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 uses a specific verb ('Pin') with a clear resource ('a message') and scope ('in a chat or channel'). This distinguishes it from the sibling tools, none of which cover pinning, so an agent can identify the correct operation immediately.

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

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

There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisite conditions. The description relies entirely on the tool name and the single sentence, offering no explicit context or exclusions 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 provided, the description carries the full burden of behavioral disclosure. It does disclose the newest-first ordering and the semantic roles of offset_id/min_id/search, which are important behavioral details. It does not address potential side effects like marking messages read, authentication requirements, or rate limits, leaving some behavioral ambiguity.

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

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

The description is short, front-loaded with the core behavior, and uses a scannable bullet-style list for parameters. Every sentence adds practical information with 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?

The description is largely complete for invoking the tool: it names the resource, provides ordering, and explains the key filtering and pagination parameters. The presence of an output schema covers return values. Minor gaps are the lack of explicit chat/limit semantics and no routing guidance toward sibling tools, but these do not critically impede correct use.

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 0% description coverage, so the description must compensate. It does so effectively for the three most nuanced parameters: offset_id (paging back), min_id (polling for newer messages), and search (text containment). It omits explicit semantics for chat and limit, but the required chat is self-evident from the tool's purpose and limit has a default, so the added value is strong overall.

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

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

The description states a clear verb and resource: 'Read messages from a chat, newest first.' It adds ordering behavior and implies the chat scope. However, it does not explicitly differentiate itself from the sibling search_messages, which may also retrieve matching messages, so it stops short of full sibling distinction.

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 useful contextual instructions for paging back with offset_id and polling for new messages with min_id, which helps an agent choose how to invoke the tool. It does not, however, provide tool-selection guidance versus alternatives such as search_messages, so the when-to-use-vs-alternatives 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?

There are no annotations, so the description carries the burden of behavioral disclosure. It does not state whether the search is read-only, how results are ordered or paginated, whether matching is fuzzy/exact, or what scope limits apply beyond 'all chats'.

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 or redundancy. It is lean and direct, though the brevity comes at the cost of missing detail captured in other dimensions.

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 two undocumented parameters, this description is too sparse to fully prepare an agent to select and invoke it. The output schema may describe return values, but the description still omits usage context, matching semantics, and behavioral expectations.

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

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

With 0% schema description coverage, the description needed to explain `query` and `limit`, but it never mentions them. The schema only offers type names and a default, so the description adds no semantic value for either 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 states the verb ('Search'), the resource ('messages'), and a meaningful scope ('across all chats'), making the tool's basic purpose clear. It does not explicitly contrast with sibling read_messages or other chat-scoped tools, so it falls short of full differentiation.

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

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

No guidance is given about when to prefer search_messages over read_messages, list_chats, or other siblings. The phrase 'across all chats' implies a global-search scenario, but there are no explicit when/when-not conditions.

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 reveals that the operation sends a file and may include a caption, but it does not disclose side effects, required permissions, file size limits, path expectations, or behavior of the force_document flag. This is thin for a mutation tool.

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

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

The description is a single sentence that front-loads the core action and supported file types, with no filler or redundant wording. Every part earns its place, and it remains appropriately sized for the tool's simplicity.

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

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

Although an output schema exists, the tool has no annotations and four parameters with zero schema coverage. The one-sentence description does not explain required parameters like chat, the meaning of path, or the force_document toggle, leaving important context missing for a complete agent decision.

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 0%, so the description must compensate for undocumented parameters. It clarifies that 'path' refers to a local file and that 'caption' is optional, but it leaves 'chat' and 'force_document' unexplained. This is insufficient for the agent to confidently construct a correct call.

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 ('Send'), a resource ('local file'), and enumerates supported content types (photo, video, document, voice), making the tool's purpose immediately clear. It does not explicitly name sibling differences, but 'local file' inherently distinguishes it from message-only or download-oriented siblings.

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

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

There is no explicit guidance on when to use this tool versus alternatives like send_message, forward_messages, or download_media. The description implies media sending, but it never states conditions, exclusions, or prerequisites, leaving the agent to infer the appropriate context.

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

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

With no annotations, the description carries the full burden of disclosing behavioral traits. It only adds the dual-use behavior and parse_mode formatting details, but says nothing about delivery side effects, permissions, reversibility, rate limits, or failure modes.

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?

Extremely short, front-loaded with the core action, and free of filler. The parse_mode detail is compact and useful, earning its place in only two lines.

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 mutating tool with 6 parameters and no annotations, this description is under-specified. It lacks sibling differentiation, parameter semantics, and behavioral caveats. The presence of an output schema covers return values but not selection or usage completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It documents parse_mode values well, but leaves chat, text, silent, reply_to, and link_preview semantically unexplained, forcing the agent to infer meaning from parameter names alone.

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, resource, and dual purpose: sending a text message and publishing a post to a channel. This clearly distinguishes send_message from siblings like send_file, edit_message, and delete_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?

No explicit guidance is given for when to use send_message versus alternatives such as send_file, forward_messages, or bot_api. The phrase 'also used to publish a post to a channel' hints at one use case but does not establish selection criteria or exclusions.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It does reveal a non-obvious trait: the tool returns the bot's replies and includes buttons. However, it does not mention whether the call waits up to the timeout, how failures are handled, or any side effects beyond sending the message.

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

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

The description is a single sentence with no filler. The action, target, and notable output behavior (replies with buttons) are all included in a compact, front-loaded structure.

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 three-parameter tool with an output schema, the description covers the core purpose and return behavior adequately. It is less complete on operational context such as timeout semantics, when to prefer this tool over send_message, and whether the bot identifier should include the '@' prefix or a token from create_bot.

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 0%, so the description must compensate. It clarifies 'bot' with the @BotFather example and 'text' implicitly as the message content, but it says nothing about the timeout parameter or the expected format of the bot identifier. This leaves a required-parameter-related detail and a configurable parameter underexplained.

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 ('Send a message') and a specific resource ('a bot'), and clarifies that the tool returns the bot's replies including buttons. This clearly separates it from the generic sibling send_message, which presumably targets normal chats rather than bots.

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

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

The description implies the use case by specifying 'a bot' and giving @BotFather as an example, so an agent can infer when to choose this over send_message. However, it never explicitly names alternatives or states when not to use the tool, leaving the routing decision largely implicit.

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