wwebjs-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
Many tools have overlapping or ambiguous purposes. For example, client_markChatUnread and chat_markUnread appear to do the same thing, as do client_sendSeen and chat_sendSeen. client_getChats and post_client_getChats are nearly identical except for HTTP method, and message_forward's description incorrectly says 'Delete a message from the chat', which is a copy-paste error that causes severe confusion.
Naming Consistency3/5
The naming mostly follows an entity_verb pattern (e.g., client_getChats, message_react, groupChat_addParticipants), but there are notable exceptions. post_client_getChats uses a non-standard 'post_' prefix, groupChat uses camelCase while other entities are lowercase, and ping and localCallbackExample lack any entity prefix. These inconsistencies break the otherwise predictable pattern.
Tool Count1/5
With 149 tools, this server has an extreme number of operations. While it reflects a comprehensive WhatsApp Web API, it is far beyond the typical well-scoped range (3-15) and even beyond 25+, making it overwhelming and difficult for an agent to navigate. The sheer volume suggests a lack of curation.
Completeness5/5
The tool surface is remarkably comprehensive, covering client management, chats, messages, contacts, groups, channels, and sessions. It includes lifecycle operations for most entities (create, get, update, delete) and even provides catch-all runMethod tools to execute arbitrary methods. There are few if any significant gaps in the WhatsApp Web API coverage.
Average 3/5 across 149 of 149 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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 not only fails to disclose any behavioral traits but actively misstates the action as deletion, which is incorrect for a forward operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it does not earn its place because it is factually wrong. Brevity without correctness is not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 4-parameter mutation tool with no annotations and no output schema. The description completely fails to explain the forward action, the need for a destination chat, or any other operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters, giving a baseline of 3. However, the description's incorrect 'delete' wording actively misleads parameter interpretation, making the description worse than no description at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a message from the chat' but the tool is named message_forward and the schema includes destinationChatId for forwarding. This directly contradicts the tool's actual purpose and is misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. Sibling tools like message_delete, message_reply, and message_edit exist, but the description does not differentiate between forwarding and other message operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 nothing about side effects, permissions, return format, or any operational traits. The bare phrase 'Get message' provides zero transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single fragment that is under-specified, not concise. It fails to earn its place as it provides no informative content, resembling a placeholder rather than a useful summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and three parameters, the description is grossly incomplete. It doesn't explain what 'class info' means, what the return value contains, or any practical details. This is inadequate for a tool with this complexity and sibling variety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all three parameters. The description adds no semantic value beyond the schema, meeting the baseline of 3, but no extra credit for clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "[Message] Get message" is a tautology that merely restates the tool name. It does not clarify what 'class info' means or distinguish this from sibling tools like message_getInfo or chat_getClassInfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. It does not mention whether to use it for metadata retrieval, debugging, or any specific scenario, nor does it exclude cases handled by other message tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. 'Get the chat' reveals nothing about whether this is read-only, what kind of data is returned, or any side effects. It fails to provide any behavioral context beyond a trivial getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. A single vague phrase 'Get the chat' does not earn its place; it lacks necessary detail and is effectively a placeholder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and a vague name, the description provides almost no context. It is completely inadequate for an agent to understand what 'class info' means or how this differs from similar getters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with descriptions and examples (100% coverage). The description adds no parameter semantics or additional 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get the chat', which is a clear verb+resource but too vague—it doesn't mention that this is specifically about class info (as the name implies) and could apply to any chat getter. This does not distinguish it from sibling tools like client_getChatById or chat_getContact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the many other chat-related getters. There is no mention of alternatives, prerequisites, or context. The description gives no usage context at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It says nothing about read-only nature, session requirements, error handling (e.g., not-found behavior), or any side effects. The description is a bare phrase with zero behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than helpful conciseness. It fails to include any substantive information beyond the tool name, so the brevity does not serve the agent's needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a one-phrase description, the tool is severely incomplete. It does not explain return values, error conditions, or how the contact is identified, leaving the agent without critical execution context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both contactId and sessionId having descriptions in the input schema. The baseline for high schema coverage is 3, and the description adds no additional parameter meaning. It does not clarify relationships or usage, but the schema already provides sufficient semantic grounding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the contact' merely restates the tool name without specifying the resource scope or distinguishing it from sibling contact tools like client_getContacts, client_getContactDeviceCount, or contact_getAbout. It lacks the specificity of a clear verb+resource definition, making it minimally useful for selecting this tool over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. It does not mention conditions like needing a contactId, whether this is for a single contact vs. a list, or any exclusions. The agent is left without context to choose this over other contact-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral details such as side effects, permissions, return format, or edge cases. The description essentially repeats the tool name and provides zero added value beyond the structured schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It lacks crucial information and does not earn its place as a useful guide for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of WhatsApp contact management, the absence of output schema, annotations, and any substantive description makes this tool virtually unusable for an agent. The description is far too sparse for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage (100%) with descriptions and examples for both parameters, so the baseline is 3. The description itself adds nothing beyond the schema, though the unusual fact that contactId is not required is left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the contact' is vague and fails to explain what 'class info' means or how this differs from other contact tools like contact_getChat or client_getContactById. It restates the resource but does not specify the action's scope, making it hard to distinguish from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. With many similar contact-related sibling tools, the absence of usage context leaves the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it reveals nothing about side effects, required permissions, return format, or whether chatId is truly optional. It is completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. It is not meaningful conciseness; it fails to convey essential information, similar to a placeholder. The single sentence does not earn its place as a useful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters, no output schema, and no annotations. The description must explain what the tool returns and any preconditions, but it does neither. It is inadequate for an agent to correctly invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters (chatId and sessionId) with descriptions, achieving 100% schema coverage. The description adds no parameter-level meaning, but per the rubric, baseline 3 applies when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "[Client] Get the chat" is nearly a tautology of the tool name 'client_getChatById'. It does not specify what a chat is, what is returned, or how it differs from sibling tools like client_getChats or chat_fetchMessages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that it is for retrieving a specific chat by ID, nor does it exclude list-based retrieval tools. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the effect of the display name (shown to users who haven't added you as a contact), which is useful context. But it does not disclose that the schema includes picture parameters, nor any side effects, return values, or session requirements. With no annotations, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with a category tag, but the first sentence is vague and arguably redundant with the second. It is concise but not maximally informative, and the content could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the purpose at a high level but fails to reconcile the schema's picture parameters with the display name concept. There is no output schema, no annotations, and no details about the required sessionId or how the picture is used. This is incomplete for a tool with 3 parameters and a confusing parameter set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for its parameters, but the description's emphasis on 'name' conflicts with the actual picture-related parameters (pictureData, pictureMimetype). The description does not add any parameter clarity and actively misleads by implying a name parameter that does not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Set the current user' which is vague, but the second sentence clarifies it sets the display name. However, the schema parameters (pictureData, pictureMimetype) suggest it actually sets a profile picture, creating a conflicting purpose. The tool name 'setDisplayName' does not align with the schema, making the stated purpose misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are siblings like client_setProfilePicture and client_setStatus, but the description does not differentiate or mention when this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 offers no information about side effects, permissions, whether this reads or modifies data, or what the sync operation does. 'Sync' is vague and could imply a range of behaviors, but the description adds no transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), but this is under-specification rather than effective conciseness. It omits essential information and does not front-load any useful detail. Like the 'Process' example, it fails to earn its place as a helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is grossly inadequate for a tool with two parameters, no output schema, and no annotations. It does not explain the purpose, usage, or behavior. The sibling 'chat_syncHistory' and other related tools remain indistinguishable, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter descriptions, so the schema covers the parameters adequately. The tool description adds no additional meaning about parameters, but the baseline is 3 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sync chat history' merely restates the tool name 'client_syncHistory' without providing a specific verb or clarifying what syncing entails. It fails to distinguish this tool from the sibling 'chat_syncHistory', leaving ambiguity about the scope and function. This is closer to a tautology than a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, scenarios, or comparisons with siblings like 'client_getChats' or 'chat_fetchMessages'. The description provides no usage context whatsoever.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details. It doesn't mention what happens in group chats, whether a missing contact returns null, or any auth or error conditions. The description's single sentence leaves all behavioral assumptions implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It omits essential context that could be conveyed in one or two additional sentences, so the brevity is not a virtue here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should explain what the tool returns, how it behaves in edge cases, and how it fits among the many sibling contact/chat tools. It does none of this, making the tool inadequately specified for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for chatId and sessionId, so the structured data carries the parameter meaning. However, the description adds no additional explanation of how these parameters interact or are used to retrieve the contact, so it doesn't exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[Chat] Get the contact' states a getter action on a contact resource, but it is vague: it doesn't clarify which contact or how it relates to the chat. It does not distinguish itself from sibling tools like contact_getChat or client_getContactById, so the purpose is only broadly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no usage guidance at all. The description never indicates when to use this tool versus alternatives, nor any prerequisites or context, leaving an agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 gives no indication of read-only status, required permissions, return data, or side effects, making it impossible to know what the tool actually does beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. The one phrase provides almost no value and does not justify its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no output schema, no annotations, and a vague description, it is inadequate. The description should at least mention what kind of group information is returned (e.g., metadata, permissions, members) but does not, leaving the agent without necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (chatId and sessionId) with clear examples and descriptions, so the description itself adds no parameter-level meaning. Baseline 3 applies because the schema provides adequate coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the group' is vague and essentially restates the tool's category without specifying what 'class info' includes. It does not distinguish this from sibling tools like client_getChatById or groupChat_getInviteCode, which also involve getting group-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not indicate what kind of group information is retrieved or contrast it with other group getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It offers no insight into side effects, required permissions, or the dynamic nature of method invocation. For a tool that can execute arbitrary methods, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains two sentences that are essentially redundant: 'Execute a method on the chat' is repeated. This is under-specification rather than effective conciseness, as the second sentence adds no new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and no explanation of return values, error handling, or available methods. For a generic method execution tool, this description is extremely insufficient and provides almost no useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. However, the description adds no additional meaning beyond the schema, and the schema's own parameter descriptions are minimal (e.g., 'method' just says 'The name of the method to execute').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute a method on the chat' restates the tool name with minimal specificity. It fails to indicate which methods are supported or what concrete action takes place, making it nearly tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this generic method runner versus the many specific chat operation tools (e.g., chat_getLabels, chat_sendSeen). No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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, but it only offers a generic action. It does not state whether this is a read-only operation, what data it returns, or any side effects, making it impossible to anticipate impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but it is under-specified rather than appropriately concise. It restates the tool name without adding useful context, so it does not earn its place as an informative explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
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, this description is wholly inadequate. It fails to explain the sync process, expected inputs, return values, or how to correctly invoke the tool, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 provides detailed descriptions and examples for chatId and sessionId. The description adds no extra meaning beyond what the schema offers, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[Chat] Sync chat history' identifies a verb and resource, but 'sync' is vague and could mean fetch, push, or reconcile. It does not distinguish from sibling tools like client_syncHistory or chat_fetchMessages, leaving the exact scope unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention how it relates to chat_fetchMessages or client_syncHistory, nor any prerequisites or context for invoking it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description 'Get the contact' gives no behavioral details such as return format, side effects, error conditions, or required permissions. The agent receives no transparency about what the tool does beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than genuine conciseness. It omits essential information that should be provided, making it unhelpful despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a 3-parameter tool, the description must explain what the tool returns and under what conditions. 'Get the contact' alone is completely inadequate for an agent to predict output or failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional parameter semantics or context beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the contact' names a verb and resource but is vague about which contact is retrieved (sender, mentioned, etc.) or how it relates to the message parameters. It also does not differentiate from sibling tools like chat_getContact or client_getContactById.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as chat_getContact or client_getContacts. The description provides no context on prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not disclose any behavioral traits such as whether the operation is read-only, what the return value looks like, or any side effects. The phrase 'Get the channel' suggests a read operation but gives no useful detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It lacks structure and fails to provide essential context. A single vague sentence is not an effective use of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotation support. The description does not explain what 'class info' is, what the result contains, whether chatId is optional or required, or any other context. It is incomplete for a tool that likely returns a structured data object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with clear descriptions and examples, so the schema is the primary source of parameter semantics. The description adds nothing beyond this, matching the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get the channel' which is vague and does not clarify what 'class info' means. It could be interpreted as fetching channel metadata, but it doesn't distinguish this from sibling tools like client_getChatById or channel_getSubscribers. It is closer to a tautology since the tool name already implies getting channel class info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. The description does not mention any prerequisites, exclusions, or specific scenarios where this should be preferred over other channel-related tools. It is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, permissions, reversibility, or expected response. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it fails to earn its place by adding no information beyond what the tool name already conveys. It is under-specified, lacking the contextual richness that conciseness should preserve.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and the existence of sibling tools, the description is incomplete. It does not explain when to use this tool, what happens on success/failure, or how it differs from related operations, leaving the agent without sufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions and examples for all three parameters. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies. No contradictions or gaps are present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the subject of the channel' is essentially a paraphrased restatement of the tool name 'channel_setSubject'. It provides no additional scope or differentiation from sibling tools like channel_setDescription or groupChat_setSubject, making it a tautology by the rubric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention channel vs group chat contexts, prerequisites, or any exclusions. Sibling tools exist for similar operations, but no comparative direction is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description gives no behavioral information: it does not say whether the operation is read-only, what the response looks like, whether pagination is involved, or any side effects. For a search tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('[Client] Search channels'), which is not conciseness but under-specification. It conveys the basic action but omits crucial context. While it is front-loaded, the brevity fails to serve the agent's needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a search tool with nested options, no output schema, and no annotations, the description should explain what search criteria can be used, the return format, and any limitations. It provides none of this, making it inadequate for understanding the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter explanations. The schema provides descriptions for sessionId and the nested properties of searchOptions, but the top-level searchOptions property lacks a direct description. With 50% schema coverage, the description should compensate for missing parameter context, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search channels', which is a specific verb and resource. It clearly indicates the tool searches for channels, but it does not distinguish this from sibling tools like client_getChannels or client_searchMessages, so it misses the full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that this is for searching vs listing channels, nor does it provide any context about intended use cases or comparisons with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. 'Changes archive state' is ambiguous and discloses neither the specific action (unarchive) nor any side effects, prerequisites, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is vague and under-specified. Conciseness is not effective when the content omits critical details, making the tool's purpose unclear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 output schema and no annotations, the description still leaves the behavior ambiguous. The presence of the sibling client_archiveChat amplifies the need for explicit clarification, which is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (chatId and sessionId), achieving 100% coverage. The description adds no additional parameter semantics, but the schema already fully documents them, 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'changes' is vague and does not specify the direction of the archive-state change. Although the tool name implies 'unarchive', the description could apply equally to archiving or unarchiving, and it does not distinguish itself from the sibling tool client_archiveChat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention that this reverses client_archiveChat or that it should be used specifically for unarchiving chats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It only states that the result is returned, but does not warn that methods may be mutating, require permissions, fail, or have timing/rate limits. This is a generic dynamic execution tool, so behavioral ambiguity is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, but the second sentence repeats the first with the minor addition 'and return the result'. This redundancy wastes space without adding information; it could be condensed into one sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an open-ended method runner with no output schema, no annotations, and a free-form 'method' string, the description should explain how to discover valid methods and what result shape to expect. The current text gives no such context, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter (sessionId, chatId, method, options) already has a description in the schema. The tool description adds no new meaning to the parameters beyond echoing 'method' and 'options', 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute a method on the group' essentially restates the tool name groupChat_runMethod and is repeated verbatim with only 'and return the result' appended. It provides no examples of valid methods or distinction from sibling tools like chat_runMethod or client_runMethod.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this generic runner versus the many specific sibling methods (groupChat_setSubject, chat_getLabels, etc.). There is no mention of exclusions, prerequisites, or a pointer to documentation for available methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only states the action without mentioning side effects, the meaning of optional parameters, idempotency, or permissions. The optional deleteLocalModels flag is completely unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, but it is so minimal that it borders on under-specification. It earns its place as a concise statement but lacks informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters including an optional nested object, the description is incomplete. It does not clarify why channelId is optional, what deleteLocalModels does, or the consequences of unsubscribing. The absence of an output schema further increases the need for behavioral context that is not provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for channelId and sessionId, covering 67% of parameters, but the description adds no parameter-level meaning. The options object with deleteLocalModels lacks any description in both schema and tool description, so the description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unsubscribe from channel' directly restates the tool name, adding no new information about the operation's scope or effects. It is a tautology rather than an explanatory statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like client_subscribeToChannel or channel_unmute. No context is given about prerequisites or the relationship to other channel-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden of behavioral disclosure. It simply restates the tool name without revealing side effects, permission requirements, parameter interactions, or reversibility. For a mutation tool, this is a severe transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified rather than concise. It merely paraphrases the tool name and provides no additional context. The single sentence does not earn its place because it offers no information beyond the resource and action already implied by the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, a complete description should explain permissions, parameter usage, and behavioral effects. This description does none of that. The presence of a nested object (newProfilePictureMedia) and optional parameters makes the tool non-trivial, and the description is wholly inadequate for guiding correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 itself adds no parameter-level insight, but the schema already provides basic descriptions for each parameter. However, the relationship between newProfilePictureUrl and newProfilePictureMedia remains ambiguous, which the description does not clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and resource (channel profile picture), making its purpose obvious. The '[Channel Chat]' prefix helps distinguish it from similar tools like client_setProfilePicture and groupChat_setPicture. However, it adds little beyond what the tool name itself conveys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention required permissions, whether to use newProfilePictureUrl vs newProfilePictureMedia, or any exclusions that would help an agent decide between competing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must fully disclose behavioral traits. It merely restates the action without mentioning side effects, reversibility, permissions, or return behavior. It provides no additional transparency beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified. It restates the tool's name with little added context, and its brevity is not informative. It lacks structure but does not waste words, placing it below a fully acceptable standard.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is severely incomplete. It does not explain the operation's scope, effects, or any special considerations, leaving the agent without sufficient context to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for both parameters (chatId and sessionId), so the description does not need to add parameter details. The schema descriptions are clear, satisfying the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('chat'), clearly stating the operation as marking a chat unread. However, it does not differentiate from the sibling tool 'chat_markUnread', which likely serves a similar purpose in a different context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'chat_markUnread'. The description offers no context, prerequisites, or exclusions, 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.
Behavior2/5
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, but it only says 'execute a method' without mentioning possible side effects, permissions, or error behavior. It doesn't add context beyond the tool's name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, but the second sentence is nearly identical to the first, creating redundancy without adding information. This is under-specification rather than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic method-execution tool with no output schema and no documented method list, the description is insufficient. It doesn't clarify what methods can be invoked, the format of options, or the result, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (method, options, sessionId) already documented. The description adds no additional parameter-level information, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool executes a method on the client and returns the result, which clarifies the basic action and resource. However, 'method' is generic and it doesn't distinguish from sibling _runMethod tools beyond the 'client' prefix, so it's only moderately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like chat_runMethod or message_runMethod. There's no mention of what methods are appropriate or any context for selecting this generic executor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for behavioral disclosure. It provides no information about side effects, required permissions, session prerequisites, or what happens after subscribing. The description is essentially a tautology of the tool name, offering no added behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. The single sentence merely restates the tool name with a '[Client]' prefix, failing to convey any useful information beyond what is already in the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should compensate by explaining the tool's place in the workflow, but it does not. It leaves the agent without enough context to understand the subscription's effects or relationship to other tools, making it incomplete for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (channelId and sessionId) with examples, and schema coverage is 100%. The description itself adds nothing about parameters, but the schema already handles semantic meaning, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Subscribe to a channel' clearly states the action and target resource, and is distinct from sibling 'client_unsubscribeFromChannel' by being its inverse. However, it lacks specificity about what subscribing entails (e.g., receiving updates) and does not explicitly distinguish from other channel-related tools like channel_getSubscribers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are any preconditions or use cases mentioned. The description simply repeats the tool's purpose without explaining the context in which subscription is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral impact. It only restates the name without revealing any side effects, permission requirements, reversibility, or consequences. It does not even note that this is a mutating operation, leaving the agent without crucial safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is under-specified rather than concise. It fails to provide meaningful content beyond the tool name. There is no structure or expansion to guide the agent, making it insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested object, no output schema), the description is extremely sparse. It does not explain the workflow, what 'membership request' means, the role of 'requesterIds' in options, or expected outcomes. This is inadequate for an agent to use the tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all parameters, achieving 100% coverage, so the baseline is 3. The description does not add any insight into parameter usage, particularly the 'options' nested object, which remains vague in the schema. It neither improves nor detracts from the structured information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Approve membership request' within the '[Group Chat]' context. It distinguishes itself from the sibling 'groupChat_rejectGroupMembershipRequests' by using the explicit verb 'Approve'. However, it lacks detail on what exactly constitutes a membership request or the scope of approval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as rejecting requests or fetching pending requests. No prerequisites or related workflow steps are mentioned. The description simply repeats the tool's purpose without any contextual framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Update,' implying a mutation, but does not explain what 'admins only' means, whether existing messages are affected, if special permissions are required, or if the change is reversible. This is a significant transparency gap for a settings-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified and fails to convey the tool's actual function. It is not concise in a useful way; the vague wording does not earn its place and could confuse rather than clarify.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema, so the description is the main source of context. It does not explain the effect of adminsOnly, when to use this tool, or how it differs from related settings tools. This is incomplete for a setting that likely has important behavioral implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for chatId, sessionId, and adminsOnly. The description adds no parameter-specific meaning, but since the schema handles parameter semantics well, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update the message group settings,' which identifies a verb and resource but is vague about what specific settings are modified. The tool name 'setMessagesAdminsOnly' implies it controls admin-only messaging, but the description does not mention this, leaving purpose ambiguous and not clearly distinguishing it from sibling tools like groupChat_setInfoAdminsOnly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other groupChat settings tools such as groupChat_setSubject, groupChat_setDescription, or groupChat_setInfoAdminsOnly. The description lacks any contextual clues about intended use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the tool name ('Delete a message') without adding any behavioral context. With no annotations, the burden is on the description to disclose effects like permanent deletion, admin/everyone behavior, or media removal—none are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It lacks front-loaded essential details for a 5-parameter mutation tool, making it closer to a placeholder than an informative summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's complexity (5 params including everyone and clearMedia) demands more context. The good schema covers parameters, but the description provides no operational context, such as what happens to media, whether deletion is reversible, or when to set 'everyone'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 5 parameters, so baseline is 3. The description adds no additional parameter meaning beyond the schema, but the schema already documents each field well (e.g., 'everyone' for global deletion, 'clearMedia' for media removal).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action clearly: 'Delete a message from the chat'—a specific verb and resource. It distinguishes from sibling tools like chat_delete (deleting the entire chat) and message_edit, though it lacks nuance about deletion scope (everyone vs. self).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as chat_clearMessages (clearing all chat messages) or chat_delete. The description is too terse to set usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'get,' implying a read-only operation, but does not disclose return format, error behavior, side effects, or session requirements, making the behavioral profile incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler and is front-loaded. However, it is so terse that it sacrifices useful information, crossing from conciseness into under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what the returned country code represents, how the optional number interacts with sessionId, or what happens when number is omitted. The existence of sibling contact_getCountryCode is also unaddressed, leaving the context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (sessionId and number), so the schema already provides the basic meaning. The description adds no extra semantic detail, and the schema's 'Number or ID' for the optional number parameter remains ambiguous, but this is not the description's failure given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get the country code' with a [Client] prefix, naming a clear verb and resource. However, it does not specify what entity the code is for or how this differs from the sibling tool contact_getCountryCode, leaving the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus contact_getCountryCode or other lookup tools. There are no exclusions, prerequisites, or alternative tool mentions, so the agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states a literal action without mentioning side effects (e.g., notifying the sender, changing read state), required permissions, or what 'seen' implies. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundancy. It is concise and front-loaded with the action, though it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits critical context: it does not explain return values, the role of the optional chatId parameter, or how this tool differs from client_sendSeen. With no output schema and minimal behavioral info, an agent would struggle to fully understand invocation expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides clear descriptions for both parameters, achieving 100% coverage. The description adds no additional meaning beyond the schema, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('set') and resource ('the message'), but it is vague about what 'the message' refers to (chat vs individual message) and does not differentiate from similar tools like client_sendSeen or channel_sendSeen. The name itself carries more clarity than the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as client_sendSeen or chat_markUnread. The description provides no context, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'change labels', implying a mutation, but does not explain effects like whether existing labels are replaced, how empty arrays behave, or whether specific permissions are needed. There is no information about response, errors, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words. It is front-loaded and appropriately sized for a simple tool. However, it is so brief that it sacrifices clarity; still, the structure itself is efficient, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inadequate for a tool with 3 parameters, no output schema, and no annotations. It does not explain return values, operational semantics (add vs remove), or expected behavior. The presence of similar sibling tools increases the need for contextual detail, which is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 additional meaning beyond the schema, which itself has minimal descriptions ('Array of chat IDs', 'Array of label IDs'). It does not clarify how these arrays interact (e.g., which action is taken on which chats) or whether the action is additive or destructive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Change labels in chats' identifies a general action (change) and resource (labels), but it is vague and does not specify whether labels are added, removed, or both. The tool name implies add/remove, but the description relies on that inference. It also does not distinguish itself from sibling tools like 'chat_changeLabels', which likely performs a similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No mention of prerequisites, exclusions, or context. Given the presence of sibling tools like 'client_getChatLabels' and 'chat_changeLabels', the lack of any usage direction leaves the agent unsure about choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get', implying a read operation, but does not describe what formatting is applied, whether it depends on locale/country, or what the return value looks like. There is no mention of potential side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it concise and front-loaded. However, it is under-specified, which prevents a perfect score. It is appropriately sized for a simple get operation but lacks necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no nested objects), but there is no output schema, so the description should explain the return value. It does not. The ambiguity around 'formatted number' and lack of sibling differentiation make the description incomplete for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 itself adds no extra meaning beyond the schema fields. Both parameters have brief descriptions in the schema, but the tool description contributes nothing additional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the formatted number' states a clear verb and resource, but the resource is vague—it doesn't specify what number is being formatted or what 'formatted' means. There is a sibling tool contact_getFormattedNumber, and the description does not distinguish itself from that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like contact_getFormattedNumber. The description lacks any context about typical use cases, prerequisites, or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Update,' implying a mutation, but does not disclose whether admin privileges are required, what settings are affected, side effects, or return behavior. This is minimal, non-contradictory but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short, front-loaded sentence with no filler, and the '[Group Chat]' prefix gives useful scope. It is appropriately concise, though it under-specifies content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description must explain the tool's effect and behavior. One vague sentence about updating info group settings is far from sufficient—it omits what the setting does, permissions needed, and expected return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema_description_coverage is 100%, and the schema already provides clear descriptions for all three parameters (chatId, sessionId, adminsOnly). The description adds no additional parameter-level context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a verb ('Update') and identifies a resource ('info group settings'), but the resource is vague and fails to mention that this specifically toggles the admins-only setting for group info. It does not clearly distinguish it from sibling setters like groupChat_setSubject or groupChat_setMessagesAdminsOnly, which also update group settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided—no mention of when to use this tool, prerequisites, or alternatives. The description simply states the action without any contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only states the action ('terminate all sessions') without explaining consequences, reversibility, impact on the current session, or any required authentication/permissions. This is a destructive operation with zero safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but redundant: 'Terminate all sessions. Terminate all sessions.' The second sentence adds no value. It is under-specified rather than genuinely concise, failing to use the available space to convey useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a destructive, terminal action with several closely related siblings (session_terminate, session_terminateInactive). The description provides no distinction between these, no side effects, and no scope clarification. For a tool of this complexity, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially covered and the description adds no parameter-specific meaning. Per rubric, 0 params receive a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool terminates all sessions, with a specific verb and resource. However, it is essentially a restatement of the tool name and does not distinguish itself from sibling tools like session_terminate or session_terminateInactive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many related session tools. There is no mention of alternatives, prerequisites, or situations where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only restates the function's effect ('send seen status') without adding any behavioral traits, side effects, or requirements. It is essentially a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and easy to parse. However, it is almost too sparse, lacking any additional context that could be included without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and parameters are well-documented, the description omits any contextual details such as when to use it, what happens after sending, or how it differs from similar tools. The lack of output schema shifts the burden to the description, which does not fulfill it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (chatId and sessionId) with examples and definitions, so the baseline of 3 applies. The description itself adds no parameter-specific meaning, but the schema covers this dimension adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send seen status') and the target ('to the channel'). The '[Channel Chat]' prefix indicates the scope, distinguishing it from chat_sendSeen. However, it does not explain what 'seen status' means, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like chat_sendSeen or client_sendSeen. There are no prerequisites, exclusions, or context given for when this should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 simply restates the tool's action without disclosing read-only status, potential side effects, or return value details. This is a minimal 'get' operation, but the description adds nothing beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is redundant, saying essentially the same thing twice: 'Get channels from the client' and 'Retrieve a list of channels from the client'. This wastes words and fails to be concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain what qualifies as a channel, whether it returns subscribed channels, or how it differs from client_searchChannels. With no output schema, the description should provide more context about return values and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the sessionId parameter 100%, including an example. The description adds no additional parameter semantics, so the baseline score of 3 applies — the schema already handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get/retrieve) and resource (channels), but it repeats itself and does not differentiate from siblings like client_searchChannels or client_getChats. It is clear enough as a list operation, but lacks specificity about what 'channels from the client' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. There is no mention of other tools, conditions, or exclusions, despite a large sibling list including client_searchChannels and client_getChats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only restates the tool's action and omits any mention of side effects, persistence, scope, or whether it overrides existing settings. This is critical for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is easily parsed. It wastes no words, though it could include more context without becoming verbose. For a simple tool, the length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks behavioral context, usage guidance, and any explanation of what the flag controls in practice. The schema covers parameters, but the description does not address return behavior, side effects, or when this setting is applied, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 additional meaning beyond the schema, which already describes 'flag' as boolean and sessionId as a unique identifier. No compensation for gaps is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as setting the auto-download flag for photos, distinguishing it from sibling tools for audio, videos, and documents. However, the phrase 'auto load download' is awkward and could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or how it differs from other auto-download settings (audio, documents, videos). The description simply states the action without contextualizing its use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only says 'Get the invite code' without mentioning permissions, return format, failure modes, or that it is a read-only operation. Minimal additional transparency beyond the name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is redundant: 'Get the invite code' is repeated with minor addition 'for a specific group'. This wastes a sentence and could be condensed to one clear phrase. The structure is also awkward with the '[Group Chat]' prefix.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the tool returns (e.g., the invite code string) and any caveats. It doesn't. For a simple getter it may be sufficient, but it lacks clarity on results, prerequisites, or error handling, making it incomplete for an agent to fully anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well-described (chatId as 'Unique WhatsApp id for the given chat group' and sessionId as 'Unique identifier for the session'). The description adds no parameter-specific details, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Get' and resource 'invite code', and clarifies 'for a specific group', which distinguishes it from tools like groupChat_revokeInvite or client_getInviteInfo. However, it is redundant, repeating 'Get the invite code' twice, and doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., being a group admin), when not to use it, or that it should be used to share an invite code. Siblings like groupChat_revokeInvite differ, but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'Edit the message'—a mutation—but provides no details on side effects, permissions, reversibility, or response behavior. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but under-specified; it reads as a placeholder rather than a meaningful explanation. It lacks the detail needed to be useful, making it inefficient despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, nested options, no output schema, no annotations), the description is inadequate. It provides no information about return values, side effects, or usage context, leaving too much to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all 5 parameters, including examples and descriptions. The description adds nothing beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('the message'), clearly indicating the tool's action. It distinguishes from sibling tools like message_delete or message_react, though it doesn't elaborate on what aspects can be edited.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description merely states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description gives no behavioral details: no output format, error conditions, side effects, permission requirements, or rate limits. The phrase 'Get the reactions associated' is too vague to inform the agent of expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short with no unnecessary words, earning high marks for conciseness. However, it is a fragment that ends with 'associated', which slightly impairs clarity and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only a fragmented description, the tool context is incomplete. The agent has to infer return values and behavior from the name and parameters, which is insufficient for a confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with clear descriptions and examples, so the baseline is 3. The description adds no additional parameter-related meaning, relying entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('reactions'), with a [Message] prefix indicating the message context. It distinguishes from siblings like message_react and message_getInfo, though the phrase 'associated' is incomplete and leaves 'with what?' implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The usage context is only implied by the tool name and sibling structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states 'send as a reply' without explaining whether messageId is mandatory, what the response contains, what side effects occur, or how replying differs from sending new messages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it is concise but largely restates the tool name. It lacks structure but is not overly verbose, earning a middle score for brevity without added substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, nested objects, and no output schema, the description is severely under-specified. It does not explain behavior, return values, prerequisites, or error conditions, making it inadequate for a complex messaging tool without relying heavily on schema and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 semantic nuance beyond what the schema already provides; it only frames the operation as a reply, which is minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send a message as a reply' clearly identifies the action (send) and resource (a message as a reply), distinguishing it from sending a new message (client_sendMessage) or forwarding (message_forward). However, it could be more explicit about targeting a specific message via messageId.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like client_sendMessage or message_forward. There is no mention of prerequisite context such as requiring chatId and messageId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without explaining consequences (e.g., whether this overrides user settings, persists across sessions, or affects existing downloads). The lack of detail about side effects or requirements is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence, but it is under-specified. While every word is useful, it lacks essential context such as behavior or when to use it. It is not front-loaded with the most critical information beyond the basic action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple flag setter, but with no output schema and no annotations, the description must carry the full contextual burden. It fails to mention session activation requirements, effects on other settings, or how this relates to sibling tools. Given the availability of similar tools for audio/photos/videos, more contextual information is necessary for correct selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: 'flag' is described as 'Flag true/false' and 'sessionId' as 'Unique identifier for the session'. The description adds no additional meaning beyond the schema. While the schema covers both parameters, the flag's semantic meaning (true/false for what?) remains vague, so the description does not compensate for that ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Set auto load download documents flag'. It identifies the specific resource (documents) and differentiates from sibling tools for audio/photos/videos. However, it could be more explicit about the scope (e.g., per-session or global) and the meaning of the flag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or how it differs from alternatives like client_setAutoDownloadAudio/Photos/Videos. The description does not mention any prerequisites, side effects, or recommended scenarios, leaving the agent without context for choosing this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must fully disclose behavioral traits. It only says 'Unpin the chat' without mentioning side effects, error conditions, idempotency, or any requirements. This leaves the agent unaware of important operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence) with no wasted words, but it is under-specified. While it is front-loaded, it lacks substance to fully inform the agent, making it not ideally sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain prerequisites (e.g., chat must be pinned), behavior if already unpinned, or any session requirements. The simple schema doesn't compensate for the absence of operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both chatId and sessionId described with examples. The description adds no parameter-specific meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Unpin the chat' with a specific verb and resource, making the core purpose understandable. However, it doesn't explicitly differentiate from sibling tools like client_pinChat or other chat actions beyond the verb itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives (e.g., client_pinChat), nor any context about prerequisites like whether the chat must already be pinned. It simply states the action without usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It only states the action without explaining reversibility, permissions, or effects on the group or requester. This is minimal but not entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but it is under-specified. It is efficiently brief yet lacks necessary context, making it neither a model of completeness nor bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested options object and no output schema, the description is incomplete. It does not explain how to specify requesters or what the response might contain, leaving the user to infer behavior solely from parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters (chatId, options, sessionId) are fully documented in the schema with descriptions and examples. The tool description adds no additional parameter meaning, but the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action clearly: 'Reject membership request' with a '[Group Chat]' prefix indicating the resource. This distinguishes it from sibling tools like groupChat_approveGroupMembershipRequests, though it lacks explicit scope details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is for rejecting pending requests, nor does it reference the approve or get tools for related actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details on its own. It only says to remove participants by ID, without mentioning permissions, whether participants are kicked, partial failure behavior, or side effects. This is insufficient for a potentially destructive mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the first sentence ('Remove the participants') is redundant with the second and adds little information. It also contains a typo ('to the group' instead of 'from the group'), reducing polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, this mutation tool should explain expected outcomes, prerequisites, and edge cases. The description only gives the basic action, leaving the agent without enough context to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully documented in the schema (100% coverage), so the description does not need to repeat them. The phrase 'by ID' aligns with participantIds but adds no extra semantics about defaults or optional behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: remove participants from a group chat. It uses the specific verb 'Remove' and identifies the resource ('participants' in a group). However, it doesn't explicitly differentiate from sibling tools like groupChat_addParticipants or groupChat_demoteParticipants, though the action itself is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as groupChat_addParticipants or groupChat_demoteParticipants. The description simply repeats the operation without context or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states that the method returns a result, but does not disclose side effects, permissions, error behavior, or whether the method is a read or mutation. This is a significant gap for a generic method runner.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but redundant, repeating 'Execute a method on the message' twice. The second sentence adds only 'and return the result,' which could be merged into the first sentence. It is not grossly verbose but fails to be optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a generic method runner with no output schema, no annotations, and complex siblings. The description does not explain what methods can be invoked, how options are used, or what the result structure looks like, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all five parameters. The description adds no additional parameter semantics or context beyond what the schema already provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (message) and the action (execute a method), distinguishing it from sibling tools like chat_runMethod and groupChat_runMethod. However, it is somewhat vague about which methods can be executed, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention sibling tools or suggest appropriate contexts, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It only states 'Get all sessions' without disclosing whether the operation is read-only, whether it returns active or historical sessions, or any potential side effects. Minimal behavioral 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The phrase 'Get all sessions.' is repeated verbatim in two sentences. This redundancy adds no value and undermines conciseness; a single sentence would suffice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values or contextual behavior. It merely states the operation without any indication of what the agent can expect to receive or how to interpret the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which typically earns a baseline of 4. The description adds nothing about parameters, but none exist, so no additional semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action clearly ('Get all sessions') with a specific verb and resource. It is not a tautology, but it fails to differentiate from sibling tools like session_status or session_start, which could also relate to session-level operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool over alternatives, what prerequisites exist (e.g., an active session), or any session-related context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden for behavioral disclosure. It simply says 'restarts' without explaining side effects (e.g., disconnection, state reset), permissions, or whether the session ID must belong to a running session. This is insufficient for a potentially disruptive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two sentences, but the first sentence ('[Session] Restart session.') is redundant with the tool name and category. The second sentence adds marginal clarity. It is concise but not highly informative, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description still leaves crucial gaps: it does not clarify what 'restart' entails operationally, when it should be used, or its impact on ongoing sessions. This is especially important for a session-control tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents sessionId with a description and example, so schema coverage is 100%. The description's phrase 'with the given session ID' adds no extra meaning beyond the schema, leaving the baseline score at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (restart) and the resource (session), and indicates it uses the provided session ID. It is unambiguous and distinct from sibling operations like session_start or session_stop, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not mention when to use restart versus alternatives, nor does it state prerequisites such as whether the session must already be active or what happens to active connections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it provides none. It does not mention side effects (e.g., whether it creates a new connection, replaces an existing session, or requires a client), authentication needs, or what happens if the session ID already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but redundant: 'Start new session.' and 'Starts a session for the given session ID.' convey the same information twice. This wastes space that could have been used for useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a session lifecycle tool with no annotations and no output schema, the description should explain what starting a session entails (e.g., creates a connection, returns a session status). It only states the basic action and parameter, leaving important contextual gaps 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully covers the single parameter sessionId with a description and example, so the description's reference to 'the given session ID' adds no new meaning. Baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start new session') and the resource ('session'), using a specific verb. It distinguishes itself from sibling tools like session_stop and session_restart by implying a fresh start, though it does not explicitly differentiate from session_restart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as session_restart or session_stop, and no mention of prerequisites or context. The description only states what the tool does without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'accept channel admin invite' without disclosing that this mutates state, requires permissions, or what the outcome/return value is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear phrase with no redundant words, earning its place. However, it is extremely minimal and lacks any structural enrichment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too sparse. It does not explain the acceptance process, side effects, prerequisites, or return value, leaving the agent without enough context for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameter meanings (chatId and sessionId), so the baseline is 3. The description adds nothing about parameters and does not clarify why chatId is optional despite being central to the action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Accept' and the resource 'channel admin invite', which is specific and distinguishes it from sibling tools like send/revoke admin invites. However, it is essentially a restatement of the tool name without additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites such as having a pending invite or compare with channel_sendChannelAdminInvite or channel_revokeChannelAdminInvite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It only states the action 'Sends a message' without mentioning side effects, permissions, return values, or error behavior. There is no contradiction with annotations because none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the tool's purpose without any redundant words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the moderate complexity of five parameters, nested objects, and no output schema, the description provides no extra context about the channel messaging scenario, content types, or expected outcomes. It leaves significant gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all five parameters with 100% coverage, so the description does not need to add parameter details. It also does not add any semantics beyond what the schema already provides, warranting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Sends a message to this channel' with a specific verb and resource. The '[Channel Chat]' prefix helps distinguish it from generic client_sendMessage, though it could be more explicit about the channel-specific context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 client_sendMessage or message_reply, nor any mention of prerequisites or exclusions. The description only states what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only states 'Add or remove labels' without mentioning side effects, permission requirements, idempotency, or the impact on chat labels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single phrase. It is not verbose and gets to the point, though it lacks the structure of a full sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and only a minimal phrase, the description is insufficient for understanding the tool's role in the broader chat label management workflow. It does not clarify the relationship to sibling tools or when this should be used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a clear description (chatId, labelIds, sessionId). The tool description adds no additional parameter context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Add or remove') and resource ('labels'), indicating the tool modifies labels. However, it does not explicitly state that this operates on a chat or distinguish it from the sibling 'client_addOrRemoveLabels'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling 'client_addOrRemoveLabels' suggests overlapping functionality, but the description offers no differentiation or contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Delete the chat' without detailing effects like whether messages are deleted for all participants, whether the action is reversible, or what permissions are required—a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words or repetition. It is front-loaded and easy to parse, though its brevity sacrifices crucial operational context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with two parameters and no output schema, the description is insufficient. It fails to specify the exact scope of the 'delete' operation, the importance of chatId, or the implications for messages, making it incomplete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover both parameters (100% coverage), so the baseline is 3. The tool description does not add any extra meaning beyond the schema; notably, it doesn't clarify the relationship between chatId and sessionId or why chatId is optional despite being seemingly essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete the chat' with a specific resource, distinguishing it from message deletion or clearing. However, it leaves ambiguity about whether it removes the entire chat history or just the chat entry from the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many related chat tools such as chat_clearMessages or client_archiveChat. There is no mention of prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only disclosed behavior is sorting order (earliest to latest). The description omits key details such as whether chatId is optional, what searchOptions controls, pagination behavior, and the return value structure. With no annotations, this is insufficient disclosure for a data-loading tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the purpose ('Load chat messages') and adds the ordering detail, making it highly efficient with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the optional chatId, the nested searchOptions object, and the absence of output schema and annotations, this brief description is inadequate for an agent to reliably invoke the tool. It fails to explain how chatId is used, what the response looks like, or how searchOptions affects results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all three parameters with examples and a coverage of 100%. The description adds no additional parameter context, so the baseline of 3 is appropriate. It does not clarify the optionality of chatId, but the schema itself is self-documenting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Load chat messages' which identifies the action and resource. The '[Chat]' prefix helps distinguish it from channel_fetchMessages, and the sorting note adds specificity. However, it does not explicitly differentiate from client_searchMessages, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like client_searchMessages or channel_fetchMessages. The description lacks context about prerequisites (e.g., whether chatId is needed) or exclusions, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavioral traits. It only states the action without disclosing side effects, whether it changes any other state, or what happens to the chat's unread count. For a state-mutating operation, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the core purpose. It is front-loaded and contains no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations and no output schema, the description is underspecified. It lacks context about usage, effects, or return behavior. The tool has only two parameters, but the description still leaves gaps regarding its behavior and relationship to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of parameters with clear explanations and examples, so the description adds no further parameter nuance. The baseline of 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (mark as unread) and the resource (this chat), using a specific verb and object. However, it does not distinguish itself from the sibling tool client_markChatUnread, which appears to perform a similar operation at a different scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like client_markChatUnread. The phrase 'this chat' implicitly suggests a current chat context, but there is no explicit when-to-use or when-not-to-use explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one behavioral trait: 'This will last for 25 seconds,' which informs the agent that the typing state automatically ends after that duration. However, with no annotations, the description carries full burden and does not disclose side effects, prerequisites, or whether the simulation is continuous or a single event. Some value is added, but major gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but contains a verbatim repetition of 'Simulate typing in chat' twice, which wastes the agent's attention. It should have been a single sentence. This is a clear structural flaw and not an example of efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action tool with no annotations and no output schema, the description gives the core action and duration but omits critical context: when to use it over alternatives, whether a session/chat is required, and what happens if the tool fails. The presence of sibling tools like 'chat_sendStateRecording' makes this lack of differentiation a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both chatId and sessionId have clear descriptions in the input schema (100% coverage). The tool description does not add any parameter-specific information, so the baseline of 3 is appropriate because the schema already handles parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Simulate typing in chat' clearly states a specific action (simulate typing) on a specific resource (chat). It distinguishes from sibling tools like 'chat_sendStateRecording' by naming the typing indicator state. However, the verb 'simulate' is slightly ambiguous as it could be interpreted as a local-only effect rather than sending a real typing indicator to others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The sibling tool 'chat_sendStateRecording' performs a similar state-sending action, but the description does not clarify that typing is for typing indicators and recording is for recording indicators. This absence makes it difficult for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It only says 'Archive the chat' with no mention of effects, reversibility, session requirements, or side effects, leaving the agent to guess the operational implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with no wasted words. However, it is so brief that it borders on under-specification, but for a simple operation it is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has two parameters, no output schema, and no annotations, the single-sentence description is insufficient. It does not explain the relationship between chatId and sessionId, or what archiving entails, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both chatId and sessionId having descriptions. The tool description adds no additional semantic meaning beyond what is already in the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Archive) and the resource (the chat), making the basic purpose evident. However, it does not explicitly differentiate from sibling tools like client_unarchiveChat or clarify that chatId identifies the chat, so it's not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as client_unarchiveChat or other chat management operations. The description simply states the action without context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action 'Create a new group' without explaining side effects, permissions, response format, or how it interacts with the session. This is insufficient for an agent to anticipate the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is immediately clear and contains no filler. However, it is so terse that it may not add enough value beyond the tool name, slightly reducing its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, a nested object (options), and no annotations or output schema, the description is under-specified. It does not explain what the tool returns, prerequisites, or how to use the parameters, leaving important gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with examples and descriptions, so the baseline is 3. The description adds no additional meaning to the parameters, merely restating the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('a new group'), clearly indicating the tool's function. However, it does not differentiate this from other group-related sibling tools like groupChat_addParticipants or groupChat_setSubject, leaving ambiguity about its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as groupChat_* tools. It does not mention requirements like an active session or that this is the correct tool for creating groups as opposed to modifying them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only restates the operation ('Get channel by invite code') without revealing whether it is a read-only operation, what the return format is, or if any side effects occur. The word 'get' implies read-only, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is concise and easy to parse. However, it is more of a title than a helpful description, sacrificing depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the tool returns (e.g., channel object, ID, or error). It does not. It also lacks information about edge cases, such as invalid invite codes or the need for an active session. The tool is simple, but the description leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (sessionId and inviteCode) with descriptions, achieving 100% schema description coverage. The description adds no extra meaning about parameters or their relationships, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('channel by invite code'), which directly matches the tool name. It distinguishes itself by specifying the lookup key ('invite code'), which separates it from generic channel listing tools like client_getChannels, though it does not explicitly contrast with client_getInviteInfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, such as whether the client must be subscribed to the channel, or scenarios where this tool is preferred over client_getInviteInfo or client_getChannels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic action, omitting important details such as whether chatId is required (it is optional in the schema), what the return format is, or any potential side effects. This leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the [Client] scope indicator. There is no redundancy or fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks essential context: it does not specify that labels are returned for a given chatId, does not explain the optional nature of chatId, and does not mention the output. Given the existence of similar sibling tools, this under-specification hinders correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with descriptions for both chatId and sessionId, so the baseline is 3. The description adds no extra parameter semantics beyond what the schema already provides, and notably does not explain why chatId is optional despite being central to the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: get all labels assigned to a chat. However, it does not explicitly indicate which chat (chatId parameter) nor differentiate itself from the sibling chat_getLabels, leaving some ambiguity. The [Client] prefix gives some scope context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling chat_getLabels appears to serve a similar purpose, but the description does not clarify when to prefer one over the other, nor does it mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Get current connection information' but does not state whether this is a read-only operation, what specific data is included, whether authentication is required, or any rate limits. No contradictions exist, but the description is too sparse to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action. It is appropriately sized for a simple one-parameter tool, but lacks any additional context that could make it more useful. It earns its place without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should clarify what 'connection information' includes, such as whether it returns session state, IP, protocol, or other details. The description only offers a vague phrase, and with many sibling classInfo tools, it does not differentiate the client-level specifics. This leaves the agent under-informed about the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter sessionId, including a description and example, so the baseline is 3. The tool description adds no additional meaning about the parameter, but this is acceptable given that the schema already documents it fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current connection information' clearly states a specific action (get) and resource (connection information for the client). It is unambiguous in its intent, though it does not explicitly distinguish itself from sibling tools like client_getState or session_status, which could also involve connection details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of use cases, exclusions, or comparisons to sibling tools. The description simply states what it does, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, safety, or response behavior. It only says 'Return invite information' and 'Return an object'; it does not explicitly state whether this is a read-only operation, what happens for invalid codes, or any permission requirements. It provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, consisting of two sentences. There is slight redundancy in stating 'Return invite information' followed by 'Return an object,' but overall it is concise and contains no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a 2-parameter function with no output schema, so the description should clarify what object is returned, how sessionId relates to invite code, and what displayName is for. It fails to explain the connection between sessionId/displayName and the invite code, leaving significant ambiguity. Sibling tools with clearer semantics exist, increasing the need for specificity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description itself adds no parameter meaning beyond saying 'invite information.' The 'displayName' parameter's relevance to invite info is unclear, but the schema documents it as 'New display name,' so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Return') and resource ('invite information'), and specifies the return is an object about the invite code. However, it does not differentiate from sibling tools like groupChat_getInviteCode or client_getChannelByInviteCode, and it is unclear which invite code is being referenced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as groupChat_getInviteCode or client_getChannelByInviteCode. There is no mention of prerequisites, input context, or exclusions. The usage context is entirely implied by the name and sibling namespace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. 'Get' implies a non-mutating read, but the description provides no details about return format, possible errors, or session requirements, which is insufficient given the lack of annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—five words with no wasted text—but it is a fragment rather than a complete sentence and under-specifies the tool's purpose. It is not as severe as a pure tautology, but it could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with only two fully documented parameters and no output schema, the description is minimally adequate. However, it lacks context about what the returned label contains, when to prefer this over client_getLabels, or any behavior beyond 'get'. More context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both labelId and sessionId with descriptions and examples, achieving 100% schema coverage. The description adds no parameter-level meaning, so it meets the baseline of 3 but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the label' clearly states the operation (retrieving a label) and identifies the resource. However, it does not explicitly say 'by ID' or distinguish among sibling tools like client_getLabels or client_getChatLabels, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as client_getLabels or client_getChatsByLabelId. The description does not mention required sessionId or any exclusions, leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 indicates a read operation but does not explain what 'current connection state' includes, what format the response takes, or whether any prerequisites or side effects exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It is concise and easy to parse, though it could arguably benefit from a bit more detail about the returned state.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one well-defined parameter, but the absence of an output schema and annotations means the description should compensate by clarifying what 'connection state' means. It does not, leaving the tool's behavior underspecified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the sessionId parameter fully described in the schema. The description adds no additional meaning beyond what the schema already provides, thus 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('current connection state for the client'), making it distinct from client_resetState and other mutations. However, it does not explicitly differentiate from session_status or other state-related sibling tools, so a small deduction is applied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like session_status or client_getClassInfo. The description only states what it does, not the context in which it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 simply restates the action without explaining what opening the chat window entails, whether the chat must already exist, or any side effects on the UI or session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded and appropriately sized for the tool's simplicity, though it is extremely terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is minimally adequate but lacks context about use cases, prerequisites, and differences from sibling tools like client_openChatWindowAt. The absence of an output schema and annotations further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for both parameters (chatId and sessionId), achieving 100% coverage. The description adds no additional parameter semantics beyond what the schema already offers, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (open) and the target (chat window), providing a specific verb and resource. However, it does not differentiate from the sibling tool client_openChatWindowAt, which likely has a similar or more specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of related tools, prerequisites, or scenarios where this should be preferred over client_openChatWindowAt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure, but it only says 'Search for messages'. It does not state whether the operation is read-only, whether pagination or limits apply, or how sessionId scopes the search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the core purpose, containing no filler. However, it is more of a fragment than a well-structured description, and the lack of detail is not compensated by any structural elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a nested options object, the one-line description is insufficient for confident invocation. Missing return format, pagination behavior, and usage context force the agent to make significant assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters, so schema coverage is 100%, earning the baseline 3. The description adds no parameter-level meaning, and the 'options' description remains vague, but this is not a gap beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' and resource 'messages', clearly indicating the tool's function. It distinguishes from sibling 'client_searchChannels' by targeting messages, though it lacks detail on scope or filtering behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'client_searchChannels' or 'chat_fetchMessages'. The description does not mention required session context, exclusions, or how this search differs from other message-fetching tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not disclose potential side effects, authentication requirements, whether the message triggers read receipts, or any other behavioral traits. Sending a message is a mutation but no consequences are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It clearly front-loads the primary action and is appropriately sized for its limited scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with complex parameters (content can be an object, contentType has multiple allowed values, options is an object), the description is insufficient. It doesn't explain how to use contentType, what options are for, or the relationship between content and contentType. No output schema is provided, so the description should offer more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters (100% coverage), so the baseline is 3. The description adds no additional semantic meaning beyond what the schema provides, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Send' and the resource 'message to a specific chatId', which is specific. However, it doesn't distinguish from sibling tools like channel_sendMessage, which also sends a message but to a channel. The [Client] prefix gives some context but no explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as message_reply or channel_sendMessage. It simply states the action without mentioning appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 merely states the action without mentioning side effects (e.g., sending a receipt), required session state, or potential consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It front-loads the action clearly, though it is quite minimal even for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, along with the many sibling tools, the description is insufficiently complete. It does not explain when this tool is appropriate, what the response looks like, or any session requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters adequately. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark the chat as seen') with a specific verb and resource. It is unambiguous in its core function, though it does not explicitly distinguish itself from the similar sibling tool 'chat_sendSeen'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative tools like 'chat_sendSeen' or 'client_markChatUnread'. The description gives no context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the basic action and provides no behavioral details such as side effects, persistence, or session-specific impact. With no annotations available, the full burden falls on the description, which does not disclose anything beyond the flag-setting operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
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 concise, though the phrase 'auto load download audio flag' is somewhat awkward and could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with only two parameters and full schema coverage, the description lacks sufficient context for an agent to know when to use it or what implications the setting has. It does not mention session context or the meaning of true/false in practical terms, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 documented. The description adds no additional meaning about the 'flag' or 'sessionId' parameters beyond what the schema states, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Set') and the target resource ('auto load download audio flag'), and 'audio' distinguishes it from sibling tools like client_setAutoDownloadPhotos. However, the phrasing is slightly awkward and could be more explicit about what the flag controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, despite the presence of closely related sibling tools for other media types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states 'block' but does not disclose any behavioral details like reversibility, side effects, permission requirements, or what happens to existing chats/messages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing only the essential action. The '[Contact]' prefix is minor noise but does not detract significantly. It front-loads the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's low complexity, the description is extremely minimal and lacks necessary context such as return values, effects, or related actions. Without annotations or an output schema, more detail is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for contactId and sessionId are complete (100% coverage). The description adds no additional parameter context, but the schema already provides adequate meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Block contact' uses a specific verb and resource, making the core action clear. It differentiates from sibling tools like contact_unblock by the action verb, though it doesn't explicitly distinguish from other blocking-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives such as contact_unblock or client_getBlockedContacts. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It reveals that the tool mutates the group subject, but it doesn't mention permissions, return values, overwrite behavior, or side effects. This is inadequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a category prefix and clear action. It has no fluff. While it is terse, it is not under-specified to the point of being unhelpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema requires only sessionId, but the description implies chatId and subject are both needed to update the subject. This inconsistency isn't addressed, and there is no indication of what happens if they are omitted. The description leaves important gaps for a simple mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for all three parameters (100% coverage), so the description doesn't need to add much. It adds no parameter-specific meaning beyond the word 'subject', which aligns with the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Update the group subject' and the '[Group Chat]' prefix distinguishes it from similar channel tools like channel_setSubject. However, it doesn't elaborate on the tool's scope or differentiate it from other group chat setters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as groupChat_setDescription or channel_setSubject. The intended context is only implied by the tool name and prefix, with no explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does not describe what happens when media is downloaded—whether it saves to disk, returns a buffer, or produces a URL—nor does it mention limitations or required authorization. The description essentially restates the tool name without adding behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately conveys the core action. It is free of unnecessary words and front-loaded with the key verb. However, it is so brief that it misses opportunities to include useful context, but for what it is, it is structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a download tool with three parameters and no output schema or annotations. The description is far too minimal to be complete: it does not explain what the user will receive, whether chatId and messageId are both required for the download, or what media types are supported. Sibling tool message_downloadMediaAsData hints at a possible data-return variant, but no distinction is made.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds no additional semantics beyond stating 'attached message media,' which does not meaningfully clarify how chatId, messageId, or sessionId are used in the download process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Download attached message media' clearly states the tool's action (download) and resource (attached message media). It is specific enough to understand the primary function, though it does not differentiate between this tool and the sibling message_downloadMediaAsData, leaving some ambiguity about the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The existence of message_downloadMediaAsData suggests a potential alternative, but no distinction is made. There is also no mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only says 'get' which implies a read operation, but does not explain what happens when no mentions exist, whether it returns a list, or if it requires both chatId and messageId to be valid. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single short sentence with a [Message] prefix. Every word is necessary, and it is front-loaded with the context tag. This is ideal conciseness with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 params, no output schema), but the description is too sparse to be complete. It does not explain the purpose of chatId and messageId, how to obtain them, what the return value looks like, or how this differs from message_getGroupMentions. Contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (chatId, messageId, sessionId) are already documented with examples and descriptions. The tool description adds no extra semantic meaning about how these parameters relate to the tool's behavior, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the contacts mentioned' clearly states a specific verb (get) and resource (contacts mentioned), with the [Message] prefix indicating it operates on a message context. However, it does not differentiate from the sibling tool message_getGroupMentions, which likely has a similar purpose for group mentions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like message_getGroupMentions, nor any context on prerequisites or typical scenarios. It is a bare statement with no usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only implies a safe read operation via the verb 'Get' but does not state return format, side effects, error cases, or any prerequisites like session requirements. This is inadequate for an operation that likely depends on message/chat context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or repetition. It is front-loaded with the verb 'Get' and the resource. However, it is extremely under-specified, which slightly reduces efficiency because the reader still has to consult the schema for basic understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description fails to explain what 'order details' means, how the parameters interact, or what the return value looks like. Given the sibling tool message_getInfo provides more context, this definition leaves significant gaps 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions fully cover all three parameters (chatId, messageId, sessionId) with examples and semantic explanations, so the baseline is 3. The description itself adds no parameter-specific meaning, but the schema compensates completely, making this score appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and a specific resource ('order details'), and the name message_getOrder reinforces this. It distinguishes from sibling tools like message_getInfo or message_getPayment, as no other sibling targets 'order'. However, 'order details' is somewhat ambiguous without further context about WhatsApp's order feature, so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as message_getInfo or message_getPayment. There is no mention of prerequisites, exclusions, or scenarios where 'order details' would be relevant. This is a clear gap given the large sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only states 'Get the payment details' without explaining side effects, required permissions, return format, or behavior when the message is not a payment. This is a simple read operation but lacks any additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
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 concise and easy to parse. However, it is extremely terse and could benefit from a bit more context, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what 'payment details' means, when they are available, or what the return value looks like. The schema explains the parameters but not the overall behavior or context of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptive text for each (sessionId, chatId, messageId). The description adds no additional parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('payment details'), which distinguishes it from sibling tools like message_getInfo or message_getMentions. The '[Message]' prefix helps contextualize it as a message-related operation. However, it could be more explicit that it retrieves payment details from a message, but overall it is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or mention sibling tools like message_getInfo for general message details. There is no implied usage context beyond the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'Get the quoted message' and does not disclose behavior such as what happens if there is no quoted message, return format, or required permissions. This is minimal and insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with no wasted words. However, it is under-specified, lacking any structured elaboration on behavior or return values, so it doesn't earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a very brief description, the tool is not well contextualized. The description does not explain the expected return value or any preconditions, making it incomplete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are well documented in the schema. The description adds no extra meaning beyond what the schema already provides, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the quoted message' clearly states the action (get) and resource (quoted message), distinguishing it from siblings like message_getInfo or message_getMentions. However, it lacks detail on scope or what 'quoted' means, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. The description simply states what it does without any context, exclusions, or references to sibling tools like message_getInfo.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It only says 'React with an emoji' and does not mention idempotency, that sending an empty string removes the reaction, or potential side effects like replacing an existing reaction. This is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase that is immediately readable and front-loaded. It contains no filler, though its brevity leaves other dimensions under-served.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient: it doesn't explain prerequisites (e.g., active session), behavior when the reaction is removed, or return values. It covers only the core action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage with detailed descriptions for all four parameters. The description adds no semantic value beyond what the schema already states—it merely restates the reaction concept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'React' and identifies the emoji action, clearly differentiating this tool from message_forward, message_star, and message_reply. However, it omits the explicit object ('to a message'), relying on the [Message] prefix and tool name, so it is clear but not fully self-contained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives such as message_getReactions (to view reactions) or message_star (a different message action). The description only states what the tool does, not when to choose it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It only says 'Star the message' and offers no information about return values, side effects, prerequisites, or whether starring is idempotent. This is comparable to mutation tools with no annotation coverage that fail to describe behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, front-loaded with the action. There is zero fluff or redundancy. While it is under-specified, that deficiency is better captured in other dimensions; the brevity itself is appropriate for a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation-like tool with no annotations, no output schema, and only a terse description. The description does not explain what happens after starring, whether identifying the message requires both chatId and messageId, or what the response contains. It falls short of being contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for all three parameters (chatId, messageId, sessionId). The tool description adds no parameter-specific meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Star the message'. The verb 'star' and resource 'message' are specific, and it implicitly distinguishes from sibling tools like message_unstar. However, it lacks any additional scoping or context that would make it fully unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools like message_unstar, message_react, and message_edit exist, but the description gives no hint about selecting this tool. It only restates the action without contextual use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose the return format (e.g., image data, base64), error conditions, or any side effects. It only restates the basic function without adding behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action. The second sentence repeats the first idea, slightly redundant, but overall efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the screenshot returns or any requirements. It does not. Given the lack of annotations and output schema, the description is incomplete for a tool that produces a screenshot.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—the sessionId is clearly described with example and format. The description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a page screenshot for a given session, using a specific verb and resource. It is distinguishable from sibling session tools like session_getSessions which list sessions or session_qr which gets QR codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no mention of prerequisites like an active session, and no mention of where the screenshot comes from or what to do with it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only restates the action of getting a QR code without disclosing return format, side effects, or dependencies, although the operation appears read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the second sentence restates the concept of a QR code and only adds marginal detail about the session ID. It is concise but slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should clarify what the return value looks like (e.g., image, data URI with MIME) and any prerequisites. It only states the input and intention, leaving significant context missing for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description of the required `sessionId` parameter, including an example. The description's mention of 'given session ID' adds no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and names the resource 'session QR code', clearly stating what the tool does. However, it does not differentiate from the sibling tool `session_qr_image`, which may serve a similar purpose, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like `session_qr_image`. The description simply states the function without mentioning any exclusions or contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but only states the intent to request authentication. It doesn't mention side effects like sending a code to the phone, changing session state, or requiring specific permissions, leaving the agent uncertain about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear verb and resource. It avoids redundancy and is easily readable, though it is minimal and could be expanded with useful context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a pairing code), any prerequisites, or behavioral side effects, which is particularly critical for an authentication-related action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the input schema, covering sessionId, phoneNumber, and showNotification. The description adds no additional parameter context, so the baseline of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Request authentication via pairing code') and the resource (Session), distinguishing it from other session tools like session_qr or session_start. However, it doesn't explicitly differentiate it from sibling tools that offer alternative authentication methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus session_qr or other authentication methods. The description lacks context about prerequisites, such as an active session, or when pairing code is preferred over QR-based authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It says only 'stops a session' without disclosing side effects (e.g., whether it closes connections, releases resources, or is reversible). This is insufficient for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the action, using a category prefix for context. The repetition 'Stop session' and 'Stops a session' is slightly redundant, but overall it is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but without annotations or behavioral explanation, the description is too sparse. It fails to clarify what 'stopping' entails or how it differs from similar session-management tools, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes sessionId with an example and format constraint. The description adds nothing beyond 'for the given session ID', which merely restates the schema. Baseline 3 is appropriate because the schema covers all parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop session') and its target ('session for the given session ID'), which distinguishes it from many sibling tools. However, it does not explicitly differentiate from session_terminate, which may have overlapping semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus session_terminate, session_restart, or session_terminateAll. The only implied context is that a session ID is required, but no situational advice or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the action 'Pin the chat' without revealing side effects, permissions, state changes, or return behavior. This is a minimal disclosure 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, containing only the essential action. It has no redundant words, earning its place, though it lacks any additional context or structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers parameters, but without annotations or output schema, the description is somewhat incomplete. It conveys the basic action but lacks usage context and behavioral details, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both chatId and sessionId documented. The description adds no additional parameter meaning beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pin the chat' clearly states the action (pin) and the resource (chat). It distinguishes itself from sibling tools like client_unpinChat, client_archiveChat, and client_muteChat by specifying a unique operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or why pinning would be preferred over archiving or muting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 simply restates the tool name ('Unmute the chat') without mentioning any side effects, permissions, or state changes. This adds no transparency beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no superfluous words. It is appropriately concise for a simple tool, and the information it does convey is clear and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is too sparse. It fails to explain the role of `chatId` (which is not required in the schema) or how this tool relates to `client_muteChat` and other chat actions. More contextual detail would be needed for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both `sessionId` and `chatId` having descriptions in the schema. The tool description adds no parameter information, but the baseline is 3 due to high schema coverage. No additional meaning is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unmute') and the resource ('the chat'), which matches the tool name. It distinguishes from the sibling tool `client_muteChat` by indicating the opposite action. Despite being terse, it leaves no ambiguity about the primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is the inverse of `client_muteChat` or suggest any context such as re-enabling notifications. There are no explicit when/when-not or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it merely restates the action without disclosing idempotency, session requirements, permissions, or side effects beyond unblocking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but redundant, repeating 'Unblock the contact' in both sentences; the second sentence adds no new information, making it less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, and the description does not explain return values, error behavior, or the relationship to contact_block, leaving a mutation tool insufficiently specified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both contactId and sessionId with examples and coverage at 100%, so the description adds no additional parameter meaning, justifying the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Unblock the contact from WhatsApp' with a specific verb and resource, and it is distinct from sibling tools like contact_block, which handles the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as contact_block, and there are no exclusions or contextual triggers mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden of disclosing behavior. It only states the action 'Update the group description' without mentioning side effects, permissions, whether an empty description clears the description, or the return value. This is essentially a restatement of the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: '[Group Chat] Update the group description'. It is concise, contains no unnecessary words, and effectively communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks contextual completeness. It does not explain when this operation is appropriate, what requirements exist (e.g., being a group admin), what happens when the description parameter is empty, or what kind of response is expected. Since there is no output schema, the description should cover these gaps but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a name, example, and description. The description text itself adds no additional parameter information, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb and resource: 'Update the group description'. The '[Group Chat]' prefix helps identify the scope, and it distinguishes from siblings like groupChat_setSubject and groupChat_setPicture by naming 'description'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., admin rights), nor exclusions, nor differentiation from similar sibling tools like channel_setDescription or groupChat_setSubject.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action (get all chats) without mentioning side effects, permissions, rate limits, pagination, or whether the session must be active. This is a significant gap for an unannotated read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) but redundant: 'Get all current chats with optional search parameters' is nearly repeated in the second sentence. It is front-loaded with the core action, but the repetition wastes words without adding significant value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the tool returns (e.g., array of chat objects, count, pagination). It only says 'Get all current chats' without any return details. Given the low complexity and absence of annotations, the description is incomplete for an AI agent to fully anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says 'optional search parameters' but does not name them, leaving ambiguity about what filters exist. The schema already documents sessionId, since, and unread, so the description adds little value beyond the structured data. With only 50% schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all chats for a given session ID, using the verb 'Get' and specifying the resource 'chats'. It distinguishes from siblings like client_getChatById (single chat) and client_getChatsByLabelId (by label) by emphasizing 'all' and 'given session ID', though it does not explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this to list all chats for a session, with optional search parameters. It implies the tool is for broad retrieval rather than specific lookups, but it does not explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states 'Mute the channel' without explaining side effects, duration, reversibility, permission requirements, or return values. The agent cannot infer what 'mute' implies operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that gets straight to the point. It is concise and front-loaded, though it omits behavioral details that would be necessary for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a well-documented schema, the description lacks any explanation of the operation's effect, prerequisites, or return behavior. For a tool with no annotations and no output schema, this level of detail is insufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for both chatId and sessionId. The tool description adds no extra parameter context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Mute') and the resource ('the channel'), clearly distinguishing it from sibling tools like channel_unmute and client_muteChat. The prefix '[Channel Chat]' reinforces the channel context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as channel_unmute or client_muteChat. The description does not mention prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'Sends', which implies a mutation, but it does not disclose side effects, permissions required, whether the invitation needs to be accepted, or any consequences. This is inadequate for a tool that alters channel admin state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the category, and contains no filler. It is appropriately sized for the simple action it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema. The description and schema together fail to explain the invitation workflow, required state, or return behavior. The misleading userId description further undermines completeness for this moderately complex admin action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, so baseline is 3, but the description adds nothing about parameters. More importantly, the schema for userId says 'The ID of the user to demote', which contradicts the tool's purpose of sending an admin invitation. This actively misleads and warrants a lower score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb and resource: 'Sends a channel admin invitation to a user.' It clearly distinguishes from sibling tools like channel_acceptChannelAdminInvite and channel_revokeChannelAdminInvite by focusing on the sending action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or how it differs from accepting, revoking, or transferring admin invitations. The user must 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.
Behavior3/5
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 return behavior for an empty result ('Returns empty array if you don't have any common group') and implies a read-only operation via 'Get'. However, it does not mention any permission requirements, error conditions, or side effects, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is redundant, repeating 'Get the contact's common groups' twice in the first two sentences. This wastes a sentence and could be tightened to a single statement. The useful information about 'with you' and the empty-array return is buried in the repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and no output schema, the description covers the core behavior and the empty-array edge case. It does not elaborate on the content of non-empty arrays or error scenarios, but these are likely inferable from the tool's name and context. Overall, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for both parameters (contactId and sessionId). The description does not add extra 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('contact's common groups') with scope ('with you'), indicating the groups shared between the contact and the current user. While it doesn't explicitly distinguish it from the similar sibling contact_getCommonGroups, the '[Client]' prefix and phrasing provide enough clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparison to similar tools like contact_getCommonGroups. The usage context is only implied by the purpose itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 basic action without mentioning potential null returns, error conditions, network dependencies, or session requirements. For a read operation, this lacks depth and leaves behavioral assumptions unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and easily scannable, though slightly awkward grammatically. This is an exemplary level of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), and the description is mostly adequate. However, the presence of a closely related sibling tool 'contact_getProfilePicUrl' introduces ambiguity. The description does not clarify the distinction or provide enough context to ensure correct tool selection, making it incomplete in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions and examples for both 'contactId' and 'sessionId'. The description adds no additional parameter-related meaning beyond what the schema already documents, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return the contact ID's profile picture URL' clearly states the action (return) and the resource (profile picture URL for a contact ID). It is specific and understandable, but it does not differentiate from the sibling tool 'contact_getProfilePicUrl', which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives. It does not explain the '[Client]' prefix or reference the similar sibling tool 'contact_getProfilePicUrl'. There are no explicit context cues or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description carries full responsibility for disclosing behavior. It only states 'Force reset' but fails to mention side effects such as disconnection, re-authentication needs, irreversibility, or impact on ongoing operations. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It conveys the core action efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is somewhat adequate. However, it lacks behavioral context, usage guidance, and relationship to sibling tools, making it only minimally complete for an AI agent to select and invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage (100%) for the only parameter, sessionId, with a clear description. The tool description adds no extra parameter information, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'force reset' of connection state for the client, using a specific verb and resource. It distinguishes from sibling tools like client_getState (which reads state) and session_restart (which operates at session level). However, it could more explicitly convey the exact scope of 'the client' and what 'reset' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as session_restart, client_getState, or other client/session management tools. The description does not mention use cases, prerequisites, or scenarios where this reset is appropriate, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action without detailing side effects, reversibility, or what 'unavailable' signifies in the system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded and efficient, though slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks context on when to use it, what 'unavailable' implies, and the relationship to the availability counterpart. The agent may need to infer usage from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter sessionId well-documented including an example. The description adds no param information, but the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark the client as unavailable' uses a specific verb and resource, clearly conveying the action. It is distinct from the sibling tool client_sendPresenceAvailable, which sets the opposite state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. The sibling client_sendPresenceAvailable is not referenced, and no conditions or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'set flag' and does not explain whether the setting persists, requires an active session, affects future downloads, or what the response/errors look like. This is a notable gap for a mutating setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant content. It is front-loaded with the action and appropriately sized for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully documents its parameters, but there are no annotations or output schema, and the description omits side effects and usage context. This is a minimum viable description, adequate for understanding the basic purpose but leaving clear gaps about behavior and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions (flag as boolean, sessionId as string), so the baseline is 3. The description adds no additional parameter information, leaving the meaning of 'flag' to be inferred from the tool name rather than explicit explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Set' and names the resource 'auto load download videos flag', clearly indicating the tool controls video auto-download behavior. The mention of 'videos' distinguishes it from sibling tools like client_setAutoDownloadAudio and client_setAutoDownloadPhotos. However, it largely restates the tool name and could be more precise about what 'auto load download' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context such as requiring an active session. It simply states the action with no exclusions or comparisons to related setters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The privacy caveat ('if privacy settings allow it') adds useful behavioral context, hinting that the result may be absent or restricted. However, with no annotations, the description still omits details about return format, failure modes, and whether any permissions are needed, leaving a moderate transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but repetitive: 'Get the profile picture URL' and 'Get the contact's profile picture URL' convey nearly the same information across two sentences. It could be condensed into one sentence without losing meaning, so it is not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with no output schema, and the description covers its basic purpose and a key caveat. However, it does not address the optionality of contactId (only sessionId is required), nor does it hint at the return value structure. A more complete description would mention how the contact is selected when contactId is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional parameter semantics beyond implying that 'the contact' refers to contactId. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('contact's profile picture URL'), making the core purpose clear. It does not explicitly contrast with sibling tools like client_getProfilePicUrl, but the 'contact' prefix in both name and description sufficiently distinguishes it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The phrase 'if privacy settings allow it' describes a conditional outcome, not a usage context. Lacks any mention of when to prefer this over client_getProfilePicUrl or other contact-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it merely restates the schema. It does not mention side effects, permission requirements, whether participants are added silently or trigger invites, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded, but the two sentences are slightly redundant ('Add the participants' and 'Add a list of participants...'). Still, it is concise and wastes no words, though it could consolidate the message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested options object and four parameters, the description is under-specified. It omits return values (no output schema), prerequisite conditions, and the specific behavior when adding participants. The schema covers parameter names but not the tool's overall context, making this insufficient for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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's phrase 'by ID' adds no information beyond the schema's 'participantIds' description. It does not explain the 'options' object structure or that 'chatId' is required conceptually despite not being marked required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('participants' to 'the group'), making it unambiguous. It distinguishes itself from sibling tools like groupChat_removeParticipants and groupChat_promoteParticipants by specifying the add operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any mention of prerequisites (e.g., admin rights, group membership). The description only states the action without contextualizing it among the sibling group management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states the action. It fails to disclose whether deletion is irreversible, requires special permissions, or has any side effects (e.g., does it also clear cached picture).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it omits useful context and adds little beyond the tool name. It is not poorly structured, just minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the core action is clear, but the description lacks usage context and behavioral caveats. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters (chatId, sessionId) at 100%, but the description adds no additional parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Delete') and resource ('group picture'), making it distinct from sibling tools like groupChat_setPicture and client_deleteProfilePicture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. There is no mention of prerequisites (e.g., admin rights) or that groupChat_setPicture is the appropriate tool for changing a picture.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic effect (demote to regular users) but does not disclose permission requirements, side effects, reversibility, or error behavior. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the first sentence is somewhat redundant with the second. It could be condensed to a single sentence without losing meaning. Still, it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple mutation tool with no annotations, no output schema, and no behavioral details. The description only covers the core action, leaving out important context like what happens on failure, whether the action is reversible, and any permission requirements. It is minimally adequate but falls short for an agent to fully understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds 'by ID' which aligns with participantIds, but does not provide additional semantic detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (demote), the target (participants), and the outcome (to regular users). It distinguishes itself from sibling tools like groupChat_promoteParticipants and groupChat_removeParticipants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidelines on when to use this tool vs alternatives. It doesn't mention prerequisites like being a group admin, nor does it reference the promote/remove counterparts. The usage context is only implied by the tool name and '[Group Chat]' prefix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states 'Get the membership requests' without disclosing whether returns pending, approved, or all requests, whether any side effects occur, or if special permissions are required. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase, front-loaded with the group chat context. It avoids unnecessary words, but it is a fragment rather than a full sentence, making it slightly less polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema, the description does not clarify what the return value contains (e.g., list of pending requests). It also lacks context on when to use it relative to the approve/reject siblings, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters, but the input schema has 100% coverage, providing descriptions for both chatId and sessionId. The schema carries the parameter semantics, so the description adds no extra value but is not penalized heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and the resource ('membership requests') with a '[Group Chat]' prefix, making its purpose explicit. It distinguishes itself from sibling tools like approve/reject membership requests by being the read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be called before approving or rejecting requests, nor does it explain the typical workflow. Sibling names imply a relationship, but the description itself offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral consequences. It only says 'Leave the group' without mentioning whether the action is reversible, requires admin rights, or affects the user's membership status. The behavioral impact is unclear, leaving the agent to guess the tool's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, containing no filler words. It quickly communicates the primary action. However, it is so brief that it borders on under-specification, though for this simple operation it still counts as efficient rather than wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks critical context: prerequisites (must be a current group member), whether the action is reversible, and any side effects on chat history or the session. With no output schema and no annotations, the description fails to provide a complete picture for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as both chatId and sessionId have descriptive text in the input schema. The description adds no additional parameter meaning, but per the rubric, a high coverage baseline of 3 is appropriate. The parameters are already well-documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Leave the group' clearly states a specific action (leave) on a specific resource (group). The '[Group Chat]' prefix contextualizes it within the group chat domain. Among the many sibling tools, no other tool explicitly covers leaving a group, so it is well distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives. For example, it does not clarify that this is for the current user leaving a group, as opposed to groupChat_removeParticipants which removes other participants, or chat_delete which removes the chat locally. No exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the tool name ('Set the group picture') and provides no additional behavioral context. With no annotations, the description carries the full burden of disclosure, but it omits any side effects, requirements, or post-conditions (e.g., whether the picture becomes immediately visible, if there are size limits, or whether admin rights are needed).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is clear and free of unnecessary words. It efficiently conveys the core purpose without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully documents parameters, so the description is minimally viable. However, it lacks any usage context or behavioral details (e.g., whether this is a mutating operation with side effects, or how it differs from sibling tools), which limits its completeness for an agent deciding when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already states, such as the format of pictureData or the meaning of chatId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set the group picture' with a resource qualifier '[Group Chat]'. It distinguishes from siblings like groupChat_deletePicture and other setter tools (channel_setProfilePicture, client_setProfilePicture) by specifying the group chat context and the set operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or any prerequisites. The description does not mention when to prefer this over groupChat_deletePicture or other group settings tools, nor any conditions like admin permissions or media requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states that it returns a QR code image, but does not mention any side effects, prerequisites (e.g., session must be active), output format (e.g., PNG, base64), or whether it is a read-only operation. This is sparse behavioral information for 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'Get session QR code as image' is immediately followed by 'QR code as image of the session with the given session ID,' which restates the same idea. It could be condensed to one clear sentence without losing information. This is not an egregious waste, but it is not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description gives a minimal but functional understanding of its purpose. However, it omits details that would help an agent, such as the image format, whether the session must be active, or any error conditions like 'session not found.' Given the lack of annotations and output schema, the description leaves some important gaps for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full documentation for the single parameter 'sessionId' (type, example, format rules, and description), giving 100% coverage. The tool description adds 'with the given session ID' but this is redundant with the schema. Since schema coverage is high, the baseline of 3 is appropriate; the description does not meaningfully enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get session QR code as image.' It uses a specific verb ('get') and resource ('session QR code'), and the phrase 'as image' distinguishes it from siblings like session_qr, which might return the QR code in another format. The parameter 'session ID' is also referenced, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like session_qr or session_requestPairingCode. It does not mention that this is the image-returning variant or when an image is preferred. No exclusions or prerequisites are stated, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing effects, prerequisites, reversibility, or error conditions. For a mutating operation, this lack of context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no unnecessary words. It is concise, but the sparseness means it could be slightly more informative without harm.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with fully documented parameters, but no annotations or output schema. The description provides the action and scope but does not explain return behavior, failure conditions, or prerequisites. It is minimally viable but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (chatId, sessionId) have descriptions in the schema, so schema coverage is 100%. The description adds no additional meaning beyond what the schema already provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Unmute the channel' with the '[Channel Chat]' prefix, identifying the specific action and resource. It distinguishes from related tools like client_unmuteChat by scoping to channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives like channel_mute or client_unmuteChat. The '[Channel Chat]' prefix implies scope but does not state exclusions or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 explaining behavioral traits. It merely states that messages are cleared but does not disclose whether this is irreversible, whether it affects only the local state, or if any permissions are required. This is a critical gap for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It effectively communicates the core action and target without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a well-documented schema, the description lacks essential context such as whether chatId is optional (it is not required), side effects of clearing messages, and what the return value might be. With no output schema or annotations, this leaves significant ambiguities for a destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions and examples, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides, making it neutral in this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Clear' and the target 'all messages from the chat', making the primary purpose evident. However, it does not differentiate from similar sibling tools like chat_delete or chat_clearState, so it falls short of full distinctiveness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this tool when you want to clear all messages in a chat. However, there is no explicit guidance on when not to use it nor any mention of alternatives, such as chat_clearState or chat_delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a state-changing operation (joining a group) but does not disclose potential side effects, required auth state, or success/failure behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant wording. It is front-loaded with the tool's primary operation and is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a mutating operation with no annotations or output schema, the description is insufficient. It does not explain the outcome of accepting an invite, any dependencies (e.g., active session, valid invite code), or distinguish the group context from channel invites. The sparse description leaves critical context unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both sessionId and inviteCode documented. The description adds no extra meaning about how parameters relate to the action, but the schema already provides baseline clarity. No additional value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses a specific verb ('accept') and resource ('invitation to join a group'), conveying the tool's purpose directly. It distinguishes itself from siblings like groupChat_revokeInvite and channel_acceptChannelAdminInvite by specifying 'group' rather than channel or generic invite operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites (e.g., having a valid invite code or active session), or contrast with related invite operations such as groupChat_getInviteCode or channel_acceptChannelAdminInvite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits beyond the obvious 'create' action. It fails to mention that a valid sessionId is required, whether the operation is destructive or reversible, or what the response/return value will be. The agent cannot anticipate side effects, making this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without unnecessary words. It is appropriately concise for a tool with only three parameters, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must supply context about prerequisites, return values, and side effects. It does none of these. The description is too minimal to support correct invocation in edge cases (e.g., invalid session, duplicate channel name, or success/failure indicators).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes title and sessionId, covering 67% of top-level parameters, which mitigates the lack of parameter info in the description. However, the 'options' wrapper is not explained, and the description adds no clarification about how parameters relate to the operation. This is a moderate score: schema covers most, but the description doesn't add meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new channel'), which is specific and unambiguous. It distinguishes from sibling tools like client_createGroup or channel_setSubject by the resource type. The '[Client]' prefix indicates the tool operates at the client level, adding useful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as client_createGroup or channel_setSubject. There is no mention of prerequisites (e.g., an active session), excluded scenarios, or why one would choose this over other channel-related tools. The agent is left without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get', implying read-only, but does not describe return format, session validation, or whether the label list is sorted or includes deleted labels. This is insufficient for 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no redundant words. It is front-loaded with the client scope and action, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what is returned when labels are fetched. It does not describe the return structure or label fields, leaving a significant gap for a one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter sessionId with a description. The tool description adds no parameter-specific detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'all current labels', clearly indicating a global label-fetching operation. It distinguishes from sibling tools like client_getLabelById (single label) and client_getChatLabels (chat-scoped labels).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when to prefer it over client_getLabelById or chat_getLabels, nor any prerequisites such as an active session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to rely on, the description carries the burden of behavioral disclosure. It explicitly states that the tool 'Returns null if you don't have permission to read their status,' which is a meaningful behavioral trait beyond the basic read operation. Additional details like error handling are absent, but this is a valuable addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains a redundant first sentence ('Get the contact's current info') that essentially restates the tool's purpose, followed by a more specific but overlapping second sentence. One of these could be removed without losing information, and the first sentence is vague and unnecessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with no output schema, and the description covers the core action and a key permission-related edge case. However, it does not explicitly state the success return value (the about string), leaving that to inference. For a tool with this simplicity, the description is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage, clearly describing both contactId and sessionId with examples. The description adds no parameter-level meaning, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a contact's 'about' info, which distinguishes it from sibling getters like contact_getProfilePicUrl or contact_getCommonGroups. However, the opening sentence 'Get the contact's current info' is vague and could imply broader data, slightly muddying the focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling contact getters, nor does it mention any alternatives or exclusions. Usage is only implied by the tool name and the mention of 'about' info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It does disclose an important edge case: returns null when querying the chat for the currently logged-in user. However, it does not mention other behavioral details such as error handling for invalid contactIds or the structure of the returned chat object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, but the first two clauses are redundant: 'Get the chat' and 'Get the chat that corresponds to the contact' essentially restate the same idea. The null note is useful, but the redundancy makes the structure less efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two well-described parameters, the description provides the core purpose and a key edge case, but lacks explicit mention of the return type (a chat object) and any failure behaviors. Given the absence of an output schema, this is a moderate gap, but the tool's simplicity mitigates it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both contactId and sessionId have schema descriptions with examples, covering 100% of parameters. The description adds no additional parameter-specific semantics beyond what the schema already provides, so it neither enhances nor detracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a chat associated with a contact, using a specific verb ('Get') and resource ('chat that corresponds to the contact'). It distinguishes itself from sibling tools like chat_getContact by focusing on the chat-side lookup, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's use case is implied: when you have a contactId and need the corresponding chat. However, it does not explicitly mention when to choose this over client_getChatById or other chat retrieval methods, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action without mentioning permissions, reversibility, or side effects. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'Promote the participants.' and 'Promote participants by ID to admins' say essentially the same thing. Could be streamlined to one sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no annotations and no output schema. The description covers the core function, but lacks behavioral context such as when to use, requirements, or potential effects. While parameters are well-documented in the schema, the overall context is incomplete for an agent to fully understand invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions. The description adds minimal value by saying 'by ID' but this is already explicit in the schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (promote participants) and the resource (group chat). It distinguishes from sibling tools like groupChat_demoteParticipants by explicitly mentioning 'promote' to admins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 versus alternatives like demote or add participants. The usage is implied by the description, but there is no mention of prerequisites (e.g., being an admin) or exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It only mentions the operation and output type, omitting details about return format, error conditions, side effects, or read-only nature, which is insufficient for a download operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words, and the '[Message]' prefix adds useful categorization without bloat. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain the return value and any preconditions. It only says 'binary data', leaving ambiguity about how data is returned (e.g., base64, buffer) and what happens if the message has no media. It also fails to clarify how this tool differs from message_downloadMedia.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema with examples and descriptions (100% coverage), so the description does not need to add parameter details. It adds no extra meaning beyond the schema, but the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Download') and resource ('attached message media') plus the output form ('as binary data'), which clearly distinguishes it from siblings like message_downloadMedia by indicating the data format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like message_downloadMedia, nor any prerequisites or context. The description only states the action without explaining selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action without explaining side effects, permissions, reversibility, or what happens if the message is not starred. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and to the point. It earns its place by stating the core action clearly without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description does not mention return values, errors, or the effect of unstaring. While the operation is simple, the description fails to provide essential context about expected outcomes or when to use it. This leaves the agent without enough information for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with all three parameters described thoroughly. The description itself adds no parameter-specific meaning, so the baseline of 3 applies. It does not clarify how the parameters relate to the operation beyond schema comments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Unstar the message' - a specific verb and resource. It distinguishes from sibling 'message_star' by indicating the inverse operation. The [Message] prefix provides context that this tool operates on messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as whether the message must already be starred, nor does it reference sibling tools like message_star. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It only restates the tool's name and provides no additional behavioral context, such as what status values are returned, possible errors, or side effects. The description adds no value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, but the second sentence largely repeats the first: 'Get session status. Status of the session...' This redundancy makes it slightly less concise than necessary, though it remains short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but there is no output schema and no information about what the status looks like or how the response is structured. The description does not cover potential errors or nuances like session not found, making it incomplete for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no extra meaning about the sessionId format or semantics beyond what the schema already provides, but it does confirm the sessionId is used to identify the session.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get session status' for a given session ID. It distinguishes itself from sibling session tools like session_start, session_stop, and session_terminate by focusing on status retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking a single session's status via the sessionId parameter, but it does not explicitly state when to use this over session_getSessions (which likely lists all sessions) or provide exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits like what defines 'inactive,' whether it is destructive, or what side effects occur. It only repeats the action without adding context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but redundant: 'Terminate inactive sessions. Terminates all inactive sessions.' The second sentence repeats the first with only slight variation, so it does not earn its place. It could be condensed to one sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with no annotations and no output schema, the description lacks critical context such as the meaning of 'inactive,' potential data loss, or return value. It is minimally viable but leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage). The baseline for no parameters is 4, and the description adds no unnecessary parameter information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool terminates inactive sessions, with 'all inactive sessions' specifying the scope. This distinguishes it from sibling tools like session_terminate (likely for a specific session) and session_terminateAll (for all sessions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as session_terminate or session_terminateAll. The description simply states what it does without context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 and owner requirement, but does not explain that deletion is permanent, whether it affects subscribers, requires special permissions, or if it can be undone. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. However, it under-specifies essential behavioral details, making it not appropriately sized for a tool with no annotations; the brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 parameters and full schema coverage, so the description is mostly adequate for understanding what the tool does. Yet it omits important context such as the outcome for subscribers, irreversibility, and any ownership/permission requirements beyond the phrase 'you created'. This makes it incomplete for a deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover both parameters (chatId and sessionId) completely with 100% coverage, so the description does not need to repeat them. However, the description adds no additional meaning beyond the schema, such as which parameter identifies the channel to delete, so it meets the baseline but no more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'a channel you created'. It distinguishes itself from sibling tools by adding the ownership constraint 'you created', which clarifies its scope compared to other channel operations and chat_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'you created' implies that this tool should only be used on channels owned by the caller, giving some usage context. However, it does not explicitly mention alternatives (e.g., chat_delete for regular chats) or exclusions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action 'update' without mentioning permissions, side effects, idempotency, or return behavior. This is similar to the update_drive reference example, which also scored 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately conveys the tool's purpose, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation and rich schema, the description is adequate for conveying basic purpose but lacks usage guidance and behavioral context. It does not explain when to use this tool versus similar channel/group tools, nor does it address potential limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions and examples for all three parameters (chatId, sessionId, newDescription), achieving 100% coverage. The description adds no additional parameter-level meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Update a channel description' with a specific verb and resource. The '[Channel Chat]' prefix distinguishes it from sibling tools like groupChat_setDescription, clarifying the target context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as channel_setSubject or groupChat_setDescription. There is no mention of exclusions or conditions under which this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states the action but does not mention that deletion is permanent, whether it requires specific permissions, or any side effects across devices. 'Delete' implies destructiveness but does not add context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and easy to parse. However, it may be too terse for a destructive operation, but that is more a completeness issue than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description tells what it does but lacks essential context about permanence, reversibility, and impact. Given that this is a deletion action, a more complete description would warn about irreversible changes or effects on the user's profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter sessionId completely with type, example, and description. The description adds no additional parameter information. Since schema coverage is 100%, the baseline of 3 is appropriate; the description does not need to elaborate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete the current user's profile picture'. It uses a specific verb ('Delete') and resource ('profile picture') and distinguishes itself from sibling tools like client_setProfilePicture (sets a picture) and groupChat_deletePicture (deletes a group chat picture). The scope 'current 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you want to remove the current user's profile picture. It does not explicitly state when not to use it or mention alternatives, but the purpose is self-evident and no competing tool for deleting a personal profile picture exists. No exclusions or context are provided, so the guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While 'Get' implies a read-only operation, it does not disclose potential pagination, rate limits, response shape, or the meaning of 'current' (e.g., session-bound). This is a minimal disclosure with no extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded with the tool category '[Client]' and immediately states the action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description adequately states the primary function, but it omits return value details, possible response size concerns, or any special behavior. Given the low complexity and no output schema, it is sufficient but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single sessionId parameter fully with a description and example (100% coverage), so the description adds no additional parameter-specific meaning. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('all current contacts'), and the name client_getContacts aligns. It distinguishes itself from client_getContactById by indicating a list operation, so the agent knows what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions. There is no mention of prerequisites or alternative tools for retrieving individual contacts, so the agent receives no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavior such as whether it performs a network call, what happens for unregistered IDs, or any permission requirements. The description carries the full burden but offers minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly to the point, with no wasted words. It is well-structured with a clear prefix and action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple check operation with two parameters and no output schema, the description is minimally adequate. However, it does not explain the return value or the auto-appending behavior of '@c.us' (though that is in the schema), leaving some context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds little beyond what is already in the schema. The term 'given ID' loosely maps to the 'number' parameter, but all parameter details are already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Check if a given ID is registered in WhatsApp'. It clearly distinguishes from sibling tools like client_getNumberId or client_getContactById which retrieve IDs/contacts rather than checking registration status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any prerequisites or scenarios for using this check, nor does it exclude any cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It only states that it 'sets' the status message, implying a mutation, but fails to mention any side effects, permission requirements, or return behavior. This is insufficient for a tool that modifies user state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fully communicates the core function without any wasted words. It is appropriately sized and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter with a well-defined schema, but the description lacks any mention of return values, error conditions, or session requirements beyond the sessionId parameter. It is adequate but leaves gaps that could affect correct invocation in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage for both parameters, with descriptions and examples. The description itself adds no additional parameter semantics, but does not need to since the schema is already detailed. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting the current user's status message. It uses a specific verb ('set') and resource ('current user's status message'), which distinguishes it from sibling tools like client_setDisplayName or client_setProfilePicture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or alternative tools, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'terminates the session' without explaining consequences like irreversibility, side effects, or what happens to associated resources. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it contains redundancy: 'Terminate session' and 'Terminates the session with the given session ID' say essentially the same thing. It could be condensed to one concise sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description lacks detail about the effects of termination and how it differs from sibling tools like session_stop or session_restart. It minimally covers the function but misses important context for a termination action with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of sessionId. The description adds little beyond repeating 'given session ID', which is already documented in the schema. Baseline 3 applies since the schema carries the meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Terminate session' with a specific resource (the session identified by session ID). It distinguishes from sibling tools like session_terminateAll and session_terminateInactive by focusing on a single session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with the given session ID' implies use for terminating a specific session, but it does not explicitly mention alternatives such as session_terminateAll or session_terminateInactive, nor does it state when not to use this tool. Guidance 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure, but it only states the basic retrieval action. It does not explicitly confirm that the operation is read-only, mention potential for large result sets, or describe behavior on invalid session IDs. The word 'get' implies reading, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the first sentence front-loading the core purpose. The second sentence adds the session ID requirement, though it is slightly redundant with the first. Overall, it is appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and no output schema, so the description should explain what the tool returns. It states that it retrieves all chats, but it doesn't describe the return format or potential pagination. While the purpose is clear enough for basic selection and invocation, the lack of return details makes it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for the only parameter, sessionId, including an example. The tool description reiterates the session ID context but adds no meaning beyond what the schema already 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: "Get all current chats" and "Retrieve all chats for the given session ID." It specifies a distinct resource and scope, and the phrase "all current chats" differentiates it from siblings like client_getChatById and client_getChatsByLabelId.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its name and phrase "all current chats," but it does not explicitly provide when-to-use/when-not-to-use guidance or name alternative tools. The mention of "for the given session ID" gives a prerequisite, but no exclusions or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing safety. 'Retrieve' implies a read-only operation, which is useful, but the description does not explain edge cases (e.g., missing contact, invalid session) or what 'lid' means. It is adequate for a simple getter but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the second sentence largely repeats the first ('Get contact lid and phone' vs 'Retrieve the contact lid and phone number'). It is still efficient, with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (2 params, no output schema), the description is incomplete: it does not explain the relationship between 'specific chat' and userIds, lacks any output format detail, and leaves the term 'lid' undefined. These gaps could lead to incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: the userIds property lacks a property-level description and the tool body does not clarify it. The description mentions 'specific chat' but the parameters are sessionId and userIds (user identifiers), not a chatId, creating ambiguity. The tool description adds no meaningful parameter semantics beyond the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get'/'Retrieve') and resource ('contact lid and phone'), and adds scope ('for a specific chat'). This distinguishes it from sibling tools like client_getContactById or client_getContacts, which are broader or return different fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific chat' implies a use case, but there is no explicit guidance on when to choose this tool over alternatives such as client_getContactById or client_getNumberId. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The description only says it opens the chat window to the message position; it does not disclose whether this is a safe read-only operation, what happens if the message is not found, whether the chat window must already be open, or any side effects like scrolling. This is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently conveys the core purpose, though it is almost too terse and could benefit from a bit more context. Still, every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple UI-navigation tool with 2 well-documented parameters and no output schema, the description is minimally adequate. However, given the lack of annotations, more context about prerequisites (e.g., active session) and behavior (e.g., whether the chat window is opened if closed) would improve completeness. It is not severely inadequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with meaningful descriptions for both parameters (e.g., messageId is 'ID of the message to scroll to (serialized)'). The tool description itself adds no additional semantic meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('chat window') with a precise scope ('to the position of the message'), clearly distinguishing it from the sibling tool client_openChatWindow which likely opens without positioning. This is a clear statement of 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to navigate to a specific message by mentioning 'position of the message', but it does not explicitly state when to use this over client_openChatWindow or when not to use it. No alternatives or exclusions are mentioned, 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.
Behavior2/5
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 merely states the action without mentioning read-only nature, return format, error conditions, or any side effects. This is insufficient for an agent to anticipate tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every word contributes to stating the tool's purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite full schema coverage and a simple getter operation, the absence of an output schema and annotations means the description should explain what the tool returns or any important context. It does not, leaving the agent without a complete picture of tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters with types, examples, and descriptions. The tool description adds no additional parameter information, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('groups mentioned in this message'), clearly distinguishing from sibling tool message_getMentions which likely covers all mentions. It directly states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing group mentions in a message, but it provides no explicit guidance on when to use this tool versus alternatives like message_getMentions. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action and actor, but does not mention side effects, permission requirements, or what happens to the invitation or the user. The description adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, no unnecessary words. It is efficient and directly conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 3 parameters and no output schema. The description provides the core purpose, but lacks usage guidance and behavioral transparency (e.g., prerequisites, effects). Given the low complexity, the description is minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description (e.g., chatId as 'Unique WhatsApp id for the given channel group'). The description itself adds no parameter-specific information, so it does not compensate beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'revokes' and identifies the resource 'channel admin invitation', with context 'sent to a user by a channel owner'. This clearly distinguishes it from sibling tools like channel_sendChannelAdminInvite and channel_demoteChannelAdmin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the action but does not explicitly specify when to use this tool versus alternatives, nor mention prerequisites such as owner permission or that the invitation must be pending. Usage is implied by the verb but no exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 25-second duration and that the recording is simulated, but it does not explain side effects, whether the state can be canceled, or what happens after the duration ends.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy, repeating 'Simulate recording audio' in the first and second sentences. It could be condensed to a single sentence without losing meaning, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function and duration, which is adequate for a simple state-simulation tool. However, with no output schema and no annotations, it lacks details on return values, termination behavior, or potential side effects, so completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters (chatId and sessionId) with descriptions and examples. The tool description adds no additional parameter semantics, so it stays at the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Simulate recording audio') and resource ('chat'), with a defined duration of 25 seconds, making it clear what the tool does and distinguishing it from sibling state tools like chat_sendStateTyping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: the tool is used to simulate an audio-recording state in chat. However, it does not explicitly mention alternatives (e.g., chat_sendStateTyping) or provide when-not-to-use guidance, so the agent must infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not add behavioral context beyond the basic operation. It fails to disclose whether the label must exist, what happens when labelId is omitted (schema marks it optional), or whether pagination is involved. The description merely restates the function without deeper insight into side effects or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no wasted words. It is front-loaded with the verb 'Get' and the resource 'chats', making it easy to parse and understand immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (two parameters, no output schema), the description covers the core purpose adequately. However, the optional labelId creates ambiguity, and the lack of any return value or error behavior explanation leaves gaps for an agent. The description is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both labelId and sessionId, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides, such as format details or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all chats for a specific label' with a specific verb and resource, distinguishing it from sibling tools like client_getChats (all chats) and client_getChatById (single chat). The phrase 'specific label' adds scope, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a label ID is available, but it does not explicitly mention alternatives or conditions for when to use this tool versus client_getChats or client_getChatLabels. No exclusions or prerequisites are stated, leaving usage guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 return value, but does not mention whether the operation is read-only, if it requires an active session, or any potential side effects. This is minimal disclosure for a tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the '[Client]' context and clearly communicates the purpose. Every word earns its place, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description adequately explains what the tool does, but it leaves out potential return format details and behavior under invalid sessions. The minimal gap in context is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter (sessionId), so the schema already provides full documentation. The description adds no extra parameter semantics, but the baseline of 3 applies due to complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Return') and target resource ('the version of WhatsApp Web'), making it distinct from all sibling tools that involve other operations. It is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing the WhatsApp Web version, but provides no explicit guidance on when to use it vs alternatives or any exclusions. Since no sibling tool offers a similar function, the lack of alternatives makes this acceptable, but explicit guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action of marking the client online but does not disclose side effects, prerequisites (e.g., active session), reversibility, or whether the operation can fail. This leaves a notable gap in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It immediately communicates the tool's purpose without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description covers the core action. However, it omits any information about return values, side effects, or how it relates to client_sendPresenceUnavailable, leaving some gaps. For such a basic operation, the description is adequate but not thoroughly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single sessionId parameter, including a description and example. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate given that the schema already documents everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Mark' with resource 'client' and state 'online', clearly distinguishing it from the sibling tool client_sendPresenceUnavailable. The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when wanting to set the client's presence to online, but it does not explicitly state when to use it versus client_sendPresenceUnavailable or any other alternative. There is no mention of prerequisites or context, so 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.
Behavior2/5
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 intended action without mentioning side effects, such as overwriting the existing picture, required permissions, asynchronous behavior, or what is returned. The brief description is not misleading but fails to reveal any behavioral characteristics beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and target. There is no redundant jargon, filler, or repetition of schema details, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a straightforward mutation tool with a minimal description and no output schema. The schema fully documents parameters, but the description lacks contextual details about the operation's effects, return value, or prerequisites. While adequate for a simple setter, it does not go beyond the bare minimum to fully inform an agent about the tool's behavior and place among related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides thorough descriptions and examples for all three parameters (sessionId, pictureData, pictureMimetype), achieving 100% schema description coverage. The tool description itself 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('current user's profile picture'). The '[Client]' prefix and 'current user' differentiate it from sibling tools like groupChat_setPicture, channel_setProfilePicture, and client_deleteProfilePicture, making the purpose unambiguous and well-scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for the current user's own profile picture, which provides some usage context. However, it does not explicitly state when to prefer this over alternatives (e.g., group chat or channel picture setters) or mention any exclusions or prerequisites, leaving the when-to-use guidance 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.
Behavior3/5
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 discloses the core behavior (returns the country code) and even gives an example, but does not mention potential errors, whether the operation is read-only, or any edge cases like invalid contact IDs. For a simple getter, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using one sentence and an example to convey the purpose and behavior. It is front-loaded with the verb 'Get' and includes only essential information, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity with a full input schema, but there is no output schema or annotations. The description is complete enough for a trivial getter, yet it omits return type information (string vs. number) and error handling. Given the simplicity, this is acceptable but leaves some gaps for an agent relying solely on this text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for both parameters. The description adds no extra meaning to the parameters beyond what the schema states, but it does reinforce that contactId is tied to the contact's country code. This meets the baseline for schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the country code' for a contact, with a concrete example mapping a phone number to a country code. It distinguishes itself from sibling tools like client_getCountryCode by prefixing '[Contact]' and specifying it operates on a contact, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as client_getCountryCode or other contact-related tools. It implies usage for retrieving a contact's country code but does not state exclusions or prerequisites, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions generating a QR code and writing a log file, which is a behavioral disclosure. Yet it omits details about the log file (e.g., location, content), whether the tool returns a value, or if the 'callback' is a blocking operation. The description is not misleading but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, with the purpose front-loaded and a clear development-only warning in caps. Every word earns its place, and there is no fluff or repetition of structured data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema, so the description should compensate by explaining return values and how the callback is used. It does not mention output at all and leaves the 'callback' mechanism ambiguous. It also fails to clarify how it relates to the numerous session QR tools, making the description incomplete given the surrounding context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is complete (vacuously). Since there are no parameters, the description does not need to explain any. Per the rubric, 0 params yields a baseline of 4, and no additional semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'generate a QR code and writes a log file.' This clearly identifies the tool's main function. However, the term 'Local callback' is vague and does not explicitly distinguish it from sibling tools like session_qr or session_qr_image, though the 'DEVELOPMENT/TEST PURPOSES' caveat helps set it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'ONLY FOR DEVELOPMENT/TEST PURPOSES,' giving a clear use restriction and implying not for production. However, it does not provide alternatives or explain when not to use it versus the many QR-related sibling tools. The guidance is present but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It conveys a read-only operation and array return type, but does not cover edge cases like missing chatId, invalid session, or empty label lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that immediately state the action and scope. There is no filler or redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The absence of output schema and annotations places a heavy burden on the description. It does not clarify the optional chatId behavior or the structure of returned label items, leaving important operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both chatId and sessionId described in the input schema. The description adds no extra parameter detail, but the schema handles the semantics adequately, making a baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and the resource ('all labels assigned to this chat'), which distinguishes it from global label tools like client_getLabels. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for chat-scoped label retrieval but does not explicitly contrast with sibling tools like client_getLabels or provide when-not guidance. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 indicates a read-only action ('Get'), but does not elaborate on return format, potential errors, or whether it only returns contacts blocked by the session's host. While the behavior is straightforward, the description lacks any caveats or details about what the response contains or how it behaves under invalid sessions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. The [Client] prefix and the active verb make it skimmable and well-structured. There is no redundant information, and every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is largely sufficient. It clearly states the operation and the scope. However, since there is no output schema, the description could have mentioned the return value (e.g., a list of blocked contacts), but the phrase 'Get all blocked contacts' implicitly covers this. Given the low complexity, the omission is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, with 'sessionId' described as a unique identifier with examples. The description does not add additional parameter semantics, but since schema coverage is high, a baseline score of 3 is appropriate. There is no extra context about how sessionId might affect the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get all blocked contacts by host account.' This specifies a unique resource (blocked contacts) and differentiates it from sibling tools like client_getContacts or contact_block. The verb 'Get' is direct, and the scope 'by host account' adds context that distinguishes it from other client getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as client_getContacts or contact_block. It simply states what the tool does without mentioning any prerequisites, exclusions, or alternative scenarios. For a simple getter, the purpose implies usage, but explicit guidance is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the empty-array return behavior, which is useful, but it does not mention whether the operation requires any permissions, has side effects, or what happens if contactId is omitted (since schema only lists sessionId as required). For a read operation, this is minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the core action. However, the second sentence ('Get the contact's common groups with you.') is redundant, repeating the first sentence with only a minor clarification. It remains compact but could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary behavior and the empty-array return case, which is good for a simple getter. However, it does not clarify the inconsistent optionality of contactId (the schema only requires sessionId) or describe the response structure beyond 'array'. Given the lack of an output schema and the presence of a similarly named sibling, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (contactId and sessionId) with 100% coverage, including examples and type information. The description adds no additional parameter semantics, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and the resource ('the contact's common groups'), with the [Contact] prefix distinguishing it from the sibling client_getCommonGroups. The phrase 'with you' clarifies the intended scope, and the mention of the empty array return value reinforces the function's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use this tool (when you need a specific contact's common groups), but it provides no explicit guidance on when not to use it or how it differs from similar tools like client_getCommonGroups. There are no exclusions or alternative recommendations, so it stops at implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It provides an example of the transformation, which adds transparency, but doesn't disclose edge cases, error behavior, or side effects. The read-only nature is implied by 'Get' but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and includes a clear example. No unnecessary words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich and the example clarifies the return format. However, the optional nature of contactId (only sessionId is required) is not explained in the description, leaving a small but notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters, so baseline is 3. The description adds no extra meaning beyond what the schema provides; contactId and sessionId are already documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the formatted phone number' with a specific transformation example. It differentiates from siblings like contact_getCountryCode and contact_getProfilePicUrl by focusing on number formatting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Sibling client_getFormattedNumber exists but no distinction is provided. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only states the action ('demotes') without mentioning permissions required, reversibility, side effects on the user's admin status, or what happens if the user is not an admin. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the [Channel Chat] context. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with three well-documented parameters, and the purpose is clear. However, there is no output schema and the description does not specify return values, success/failure behavior, or any prerequisites. For a mutation tool, this leaves some gaps, but the schema coverage keeps it at a minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for chatId, userId, and sessionId. The tool description adds no additional parameter context beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Demotes') and resource ('a channel admin to a regular subscriber'), clearly distinguishing it from sibling tools like channel_revokeChannelAdminInvite (which revokes an invite) and groupChat_demoteParticipants (which operates on group chats). The [Channel Chat] prefix reinforces the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The [Channel Chat] prefix provides clear context that this tool is for channel chats, not group chats or other chat types. While it doesn't explicitly mention alternatives or exclusions, the naming and prefix imply the appropriate use case, which is sufficient for an agent to differentiate from group demotion tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only lists valid values and their meanings, but fails to mention permissions, side effects, reversibility, or what happens to existing reactions. This is a mutation tool, so more transparency is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with all information in a single sentence plus a clear list of valid values. It is slightly awkward in structure but contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple setter tool, providing complete valid value documentation. However, it lacks any mention of return values, errors, or permission requirements, and there is no output schema or annotations to fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the schema descriptions are minimal. The description adds meaningful value by enumerating the exact codes (0, 1, 2) and corresponding reaction sets, going beyond the schema's 'New reaction setting' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates available reactions in a channel, using a specific verb and resource. It distinguishes itself from sibling channel tools like channel_setSubject or channel_setDescription by focusing on reaction settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to change channel reaction settings) but does not explicitly state exclusions or alternatives. No guidance is given on when not to use it or how it compares to other channel configuration tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds a useful behavioral note about the admin requirement, but does not disclose side effects like what happens to the current owner's role, or the meaning/impact of options like shouldDismissSelfAsAdmin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the core purpose upfront. The added note is relevant and necessary. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameters and the description states the core action, the tool is a mutation with no output schema and no annotations. It lacks details about return values, success/failure behavior, or the effect of the shouldDismissSelfAsAdmin option. For a simple transfer tool, this is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so individual parameters like chatId and newOwnerId are already documented. The description's note about the new owner being a channel admin adds context for newOwnerId, but does not explain the nested options object's fields beyond examples. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Transfers'), a clear resource ('channel ownership'), and defines the exact action ('to another user'). This unambiguously distinguishes it from sibling tools like channel_demoteChannelAdmin or channel_sendChannelAdminInvite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a critical precondition (the new owner must be a channel admin), which implies when the tool can be used. However, it does not explicitly state when to use this over alternatives, nor any exclusions or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key behavior of muting forever by default and conditionally until a specified date. It does not disclose reversibility, permission requirements, or effects on notifications, which are relevant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence and front-loads the action. It is slightly redundant ('Mute the chat' then 'Mute this chat') but remains efficient. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter mutation tool with no output schema, the description covers the essential behavior including the default duration. It does not explain prerequisites or side effects, but these are not critical for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description partially reiterates the unmuteDate behavior but adds no new semantics beyond the schema. Since schema coverage is high, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool mutes a chat, with a specific verb and resource. The '[Client]' prefix and explicit 'Mute the chat' differentiate it from sibling tools like client_unmuteChat and channel_mute. The added detail about duration further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to mute chats, with the option to set a temporary mute via unmuteDate. However, it does not explicitly state when to prefer this over alternatives or exclude other contexts like channel muting. The 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.
Behavior3/5
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 a significant limitation: subscribers are limited to those in the agent's contact list. However, it doesn't mention permissions, pagination, return format, or the optional chatId parameter's role, so some behavioral traits remain hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates what the tool does and a key limitation. The '[Channel Chat]' prefix is minimal and adds useful categorization without clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one required parameter and no output schema, the description covers the main purpose and an important constraint. It doesn't explain return format or authentication, but these can be reasonably inferred; overall it is fairly complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter has a description. The tool description adds no extra parameter-level meaning beyond what the schema already 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Gets the subscribers of the channel' – a specific verb and resource. The qualifier 'only those who are in your contact list' adds scope clarity and distinguishes it from other channel-related tools like channel_getClassInfo or channel_fetchMessages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool when you need channel subscribers, but it does not explicitly state when to use it versus alternatives. It provides a constraint (contact list only) but no exclusions or mention of related tools, leaving timing considerations up to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that messages are sorted from earliest to latest, which is a behavioral trait. However, with no annotations, it doesn't explicitly state that this is a read-only operation or mention any side effects, though 'Load' implies read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the scope prefix, and every word earns its place. No unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sparse, with no mention of return format, pagination, or handling of optional chatId. However, the schema covers parameters, and the tool is a simple fetch, so it's minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions and examples for chatId, sessionId, and searchOptions, so the description adds no additional parameter semantics. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Load' with the resource 'channel messages', and the '[Channel Chat]' prefix clearly distinguishes this from sibling tools like chat_fetchMessages. It states exactly what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '[Channel Chat]' prefix provides clear context that this tool is for channel messages, but it doesn't explicitly mention when not to use it or alternatives like chat_fetchMessages. The context is clear enough to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It clearly discloses the core behavior: the current invite code is invalidated and a new one is generated. This goes beyond the name alone and gives the agent a concrete understanding of the operation's effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with a bracket prefix and a clear action. The slight redundancy between 'Invalidate the invite code' and 'Invalidate the current group invite code and generates a new one' is minor, but the second sentence adds the important detail of generating a new code.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description sufficiently explains what the tool does. The chatId and sessionId parameters are well-defined in the schema, and the operation's effect is clearly stated. It could mention the side effect of invalidating existing invite links, but overall it is complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 additional parameter details beyond what is already in the schema. ChatId and sessionId are well described in the schema, but the description does not mention them or clarify their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Invalidate the invite code' and further explains it invalidates the current code and generates a new one. This distinguishes it from sibling tools like groupChat_getInviteCode, which retrieves rather than invalidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('Invalidate the current group invite code') but does not explicitly compare to alternatives or state when not to use it. It is clear from context that this is for revoking invites, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavior: returns null if the message does not exist or is not sent by you. However, it does not mention return structure, permissions, or other operational details. This adds some value but leaves gaps, consistent with a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise two-sentence structure with no filler. It front-loads the primary purpose and then adds a critical conditional behavior. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description provides the essential purpose and a null condition but fails to describe the return structure or any statuses. This is adequate for a simple read tool but leaves the agent guessing about the response shape, so a 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters (100%) with descriptions and examples. The tool description adds no extra meaning about how chatId, messageId, or sessionId relate to the delivery status. Baseline 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('information about message delivery status'). It distinguishes itself from sibling tools like message_getClassInfo and other message getters (e.g., message_getReactions, message_getMentions) by focusing on delivery status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need delivery status information for a message. It also hints at a limitation ('not sent by you') but does not explicitly name alternatives or provide when-not-to-use guidance. This is clear context without exclusions, meriting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It accurately states the core action (stopping typing/recording) and adds 'immediately' to convey urgency. However, it does not explain potential edge cases (e.g., behavior when chatId is omitted, whether both typing and recording are cleared if both are active, or any side effects on the chat state).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundancies. The [Chat] prefix provides quick category recognition, and the wording is clear and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 2 parameters, full schema coverage, and no output schema, the description adequately covers the essential behavior. It could be improved by mentioning when to use it relative to state-sending tools, but for this low complexity, the description is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both chatId and sessionId have clear descriptions in the schema. The tool description does not add extra parameter semantics, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop typing or recording in chat immediately' clearly states the action (stopping an ongoing state) and the resource (a chat). It distinguishes from siblings like chat_sendStateTyping and chat_sendStateRecording by focusing on stopping rather than starting the state, and from chat_clearMessages which covers messages, not state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is used to halt an ongoing typing or recording action. It implies the user would call this after having triggered a send state. While it does not explicitly exclude alternatives or mention sibling tools, the intended usage is unambiguous for a simple action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently explains the counting logic (WaWeb connections plus phone) and provides a concrete example. It doesn't disclose edge cases, errors, or permissions, but for a simple get operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the core purpose, then adds a clarifying example. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with no output schema, the description adequately explains the return value by defining device count and giving an example. It could be more explicit about the return type or error conditions, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (sessionId and userId), so the schema fully handles parameter documentation. The description adds no additional parameter meaning, which is fine but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get user device count'. It specifies the resource (device count) and verb (get), and distinguishes it from sibling tools as the only one for device counting. The example clarifies the exact meaning of the count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through the description and tool name, but there is no explicit guidance on when to use this tool versus alternatives or any exclusions. The description gives insight into the output semantics but not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states a key behavior: returning null if the number is not registered on WhatsApp. It also implies a read-only operation via 'Get'. This goes beyond the schema, which only describes parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with a clear subject and outcome. It is front-loaded with '[Client]' for grouping and quickly conveys the core purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 well-documented parameters, no output schema), the description adequately explains the return behavior (registered ID or null). It is complete enough for an AI agent to invoke the tool correctly, though it doesn't detail the exact format of the returned ID or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'number' and 'sessionId' fully described in the input schema. The description adds no additional parameter information beyond what's already present, so it doesn't compensate further. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting the registered WhatsApp ID for a number. It distinguishes itself from sibling tools like client_getFormattedNumber (formatting only) and client_isRegisteredUser (likely returns a boolean) by specifying the return of the ID and the null condition for unregistered numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need the registered WhatsApp ID for a phone number. However, it does not explicitly mention when to use this versus alternatives, nor any exclusions or prerequisites. Sibling tools like client_getContactById or client_isRegisteredUser are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 a critical behavior: 'This action will take effect after you restart the client.' This is valuable information about the side effect and timing of the change. However, it does not mention permissions, reversibility, or what the flag value means, but for a simple setter, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one action sentence plus a critical note. No filler words. The structure front-loads the purpose immediately, and the note is placed at the end. Every word adds value, making it an exemplar of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 2 parameters, no output schema, and no annotations, the description covers the core purpose and the key side effect (restart required). It is brief but sufficient for an agent to understand what the tool does and what to expect. It lacks a bit of detail about flag semantics, but the schema provides 'flag true/false', so completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'flag' and 'sessionId' have descriptions in the schema. The tool description adds no extra parameter context, but the schema already handles parameter meaning adequately. Baseline 3 is appropriate because the description does not compensate or add beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Change the background synchronization setting.' This uses a specific verb ('Change') and resource ('background synchronization setting'), which distinguishes it from sibling tools like client_setAutoDownloadAudio or client_setDisplayName. The intent is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('Change the background synchronization setting') but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The note about restarting the client gives some context, but does not address when this setting should be toggled or mention related tools. This is basic implied usage, not a clear guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It does disclose a key behavior: returning null if the message does not exist or is not a poll. However, it does not mention any other behavioral details such as whether it requires specific permissions, how it handles expired polls, or the structure of the results. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It front-loads the action and includes the most important edge-case behavior (null return) without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with fully documented parameters and no output schema, the description is largely complete. It explains the purpose and the null return behavior. However, it does not specify the shape of the returned 'poll vote results,' which could be helpful since there is no output schema, but the tool's name and intent make it reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides complete descriptions for all three parameters (coverage 100%), so the description need not add parameter-specific details. The baseline of 3 applies because the schema does the heavy lifting; the description adds no extra parameter semantics beyond what is already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get poll vote results for a message with a poll') with a specific verb and resource. It distinguishes itself from sibling message tools (e.g., message_getReactions) by focusing specifically on poll votes, and even notes the null return condition, which sharpens the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need poll vote results for a message that contains a poll. It does not explicitly name alternatives or exclusions, but the context is clear. Sibling tools cover other aspects (reactions, info), so a user can infer the appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses that the tool responds with a 'pong' message, which is the core behavior. However, it does not elaborate on any side effects, authentication requirements, or error handling, leaving some gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded with the term 'Health check'. The main content is efficient, but the leading '[Various]' prefix is extraneous and detracts from the overall clarity, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is entirely sufficient. It specifies both the input (request) and output ('pong' message), making the tool's behavior fully understood without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description appropriately adds no unnecessary parameter information, as none exist. The schema already confirms no parameters, and the description aligns with that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a health check that responds with 'pong', which is a specific verb and resource. It is unambiguous and distinguishes itself from all sibling tools, as none other serve a health-check purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied rather than explicit. As a health check, it is evident that it is used to verify service availability, but the description does not explicitly state when to use it or mention any alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![wwebjs-mcp MCP server](https://glama.ai/mcp/servers/victor-halla/wwebjs-mcp/badges/card.svg)](https://glama.ai/mcp/servers/victor-halla/wwebjs-mcp)

Score Badge

Copy to your README.md:

[![wwebjs-mcp MCP server](https://glama.ai/mcp/servers/victor-halla/wwebjs-mcp/badges/score.svg)](https://glama.ai/mcp/servers/victor-halla/wwebjs-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/victor-halla/wwebjs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server