Botsify

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

Annotations already indicate this is a mutating, non-idempotent action. The description adds the HTTP POST endpoint and clarifies a parameter detail, but does not describe the behavioral side effects of activation (e.g., switching the active version). This is acceptable but not exceptional.

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

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

Two concise sentences with zero redundancy. The action is fully specified in the first sentence, and the second sentence provides a crucial parameter clarification relevant to correct invocation.

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

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

This is a simple 2-parameter tool with an output schema and annotations. The description effectively covers the tool's purpose and the key parameter gotcha, making it sufficiently complete. A brief mention of the activation effect could make it fully complete.

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

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

Schema descriptions cover both parameters, so the baseline is 3. The description adds extra semantic clarity by warning that bot_id is the API key string, not a numeric id, which goes beyond the schema's description and helps prevent a common mistake.

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

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

The description clearly states the tool's purpose with a specific verb ('Activate') and resource ('a version') and even specifies the REST endpoint. This distinguishes it from sibling tools like list-agent-versions, delete-agent-versions, or deploy-agent-version.

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

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

No explicit guidance on when to use this tool vs alternatives. The description only states what it does ('Activate a version') with no mention of prerequisites, when not to use, or references to sibling tools such as deploy-agent-version or save-agent-version.

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

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

The description explicitly states that status 2 deletes users and status 6 deletes conversations, which is destructive behavior. This directly contradicts the annotation 'destructiveHint: false'. The description is transparent about the side effects, but the annotation says otherwise, creating a serious inconsistency.

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

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

The description is two concise sentences. The first identifies the action and endpoint, the second lists the status meanings. Every sentence earns its place with zero fluff.

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

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

Given that an output schema exists and parameters are fully documented in the schema, the description sufficiently covers the key behavioral context of status codes and their side effects. The only gap is the unresolved contradiction with annotations, but the description itself is complete for the tool's core use.

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

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

The schema covers 100% of parameters, but the description adds critical semantic value by explaining what each numeric status means (e.g., 2 deletes users, 3 marks test users). This goes beyond the schema's generic 'Activation action code such as 2, 3, 6, or 7', enriching parameter understanding.

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

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

The description clearly states the tool's function: changing messenger user status via POST /v1/user/change-status/{status}. It enumerates specific status codes (2, 3, 6, 7) with their effects, which uniquely identifies the tool among siblings like set-user-attribute or list-messenger-users.

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

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

The description provides clear context for when to use this tool and what each status does, enabling the agent to decide between destructive and non-destructive status changes. However, it does not explicitly mention alternatives or conditions when this tool should not be used, which would warrant a 5.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds the endpoint and the scope of clearing 'state' but does not disclose further behavioral details such as irreversibility or what specific data is lost. This is adequate but not enhanced.

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

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

A single, front-loaded sentence that states the action, target, and endpoint with no extraneous words. Every element adds value.

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

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

Given zero parameters, rich annotations (destructive, idempotent, open-world), and the existence of an output schema, the description is nearly complete. It could mention the prerequisite of having a selected bot, but this is a minor omission.

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

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

The tool has zero parameters, so the baseline is 4. The description adds context about the 'selected bot' but no parameter-level detail is needed since the schema is empty.

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

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

The description clearly states the action ('Clear'), the resource ('builder conversation state'), and the specific endpoint ('POST /v1/clear-conversation'). This distinguishes it from sibling tools like stop-builder-stream or start-builder-chat.

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

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

The description does not explain when to use this tool versus alternatives, nor does it mention any prerequisites like selecting a bot first. It only implies use for clearing builder conversation state, which is basic context without explicit guidance.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds the behavioral detail that cloning can take a few minutes, which is useful. However, it does not elaborate on the exact scope of duplication (e.g., what is copied, whether original is affected), so it provides only moderate transparency beyond the annotations.

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

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

The description is one sentence with two concise parts: the core action and a latency warning. It is front-loaded with the verb and resource, contains no filler, and every word contributes to understanding.

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

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

For a simple tool with a single well-documented parameter, an output schema, and annotations, the description is nearly sufficient. It covers the key purpose and the notable latency behavior, but it could mention what the clone operation returns or any post-conditions. Still, given the context signals, it is largely complete.

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

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

The input schema fully documents the single parameter bot_id with a clear description. The HTTP endpoint in the description restates the same parameter, adding no new semantic meaning. Since schema coverage is 100%, the baseline of 3 applies.

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

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

The description clearly states the tool duplicates an existing agent, using the specific verb 'Duplicate' and resource 'agent'. It also provides the HTTP endpoint, which unambiguously identifies the operation and distinguishes it from sibling tools like create-agent or delete-agent.

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

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

The description gives clear context on when to use the tool: to create a duplicate of an existing agent. It does not explicitly mention alternatives or exclusions, but the verb 'duplicate' inherently differentiates from create-agent, and the latency note provides additional usage context (not to be used for instant operations).

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

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

Annotations indicate readOnlyHint=false, so mutation is expected. The description adds valuable context by disclosing the side effect: 'Stores the new bot_api_key for later tools.' This is beyond what annotations provide, though it does not cover additional behavioral aspects like authentication 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.

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

The description is two sentences, front-loaded with the primary action and endpoint. Every clause adds value: creation action, required type, optional template, and side effect. No filler or redundancy.

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

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

Given the simple create operation, the description covers the essential aspects: what it does, required types, optional template, and the important side effect of storing the bot_api_key. The presence of an output schema and comprehensive parameter schema means the description does not need to explain return values or parameter details. It is sufficiently complete for an agent to select and invoke this tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats information already in the schema (agent_type values, template optionality) but does not add new meaning beyond the schema. It does not explain how bot_name is used or any format constraints beyond what's in the schema.

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

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

The description clearly states the action ('Create a Botsify agent'), the resource ('agent'), and the specific API endpoint ('POST /v1/create-bot'). This is more specific than the tool name alone and distinguishes it from sibling tools like clone-agent or rename-agent.

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

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

The description provides clear context for when to use the tool (creating an agent) but does not explicitly mention alternatives or when-not-to-use scenarios. For example, it does not differentiate from clone-agent, which is a related sibling. The statement 'Requires agent_type chatbot, agent, or voice' gives parameter constraints, not when-to-use guidance.

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

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

The description discloses the operation type ('Exchange password grant credentials') which aligns with readOnlyHint=false, but does not add rich behavioral context beyond that, such as token expiration, refresh semantics, or side effects. Annotations already signal non-idempotency and non-destructiveness, so the description adds modest value.

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

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

The description is two concise sentences, front-loaded with the action and endpoint, and the second sentence adds necessary credential-source context. No wasted words.

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

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

Given the tool's moderate complexity (5 params, output schema present), the description is fairly complete: it states the action, endpoint, and where required credentials come from. The output schema covers return values, so lack of description there is fine. Minor gap: it doesn't explicitly frame the overall auth flow or token usage, but that is inferred.

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

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

Schema coverage is 100% with all parameters described. The tool description mostly repeats the source of client_id/client_secret already in the schema, and does not add meaning for scope, username, or password beyond their existing schema descriptions. Baseline 3 is appropriate.

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

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

The description uses the specific verb 'Exchange' and identifies the resource as 'password grant credentials via POST /oauth/token', clearly distinguishing it from login-account and other sibling tools. It also explains the source of client_id/client_secret, which ties it to the login flow.

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

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

The description implies that a prior login must have occurred ('client_id and client_secret come from POST /v1/login') but does not explicitly state when to use this tool vs alternatives or provide any exclusions. It gives context but lacks explicit usage guidance.

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

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

Annotations already convey non-read-only, non-destructive behavior. The description adds endpoint context and the SMS type nuance, but lacks deeper behavioral details like authorization requirements or idempotency implications.

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

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

Two concise sentences, front-loaded with the core action, no redundant wording.

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

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

Given 7 parameters including nested objects and an output schema, the description is adequate but terse. It covers the key type distinction but offers little guidance on optional fields or template creation flow.

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

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

Schema coverage is 100%, so parameters are fully documented. The description reinforces the critical 'type' parameter ('Set type to sms') but does not add meaningful semantics beyond what the schema provides.

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

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

The description uses a specific verb ('Create') and resource ('WhatsApp or SMS media template') with an explicit endpoint, clearly distinguishing it from sibling tools like list-whatsapp-templates or send-whatsapp-broadcast.

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

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

The description clearly implies usage for creating WhatsApp or SMS templates and highlights the SMS type switch, but it does not explicitly contrast with alternative creation or template-related tools.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, which covers the write/safety profile. The description only adds the HTTP method and endpoint, which is mechanical rather than behavioral. It does not disclose auth requirements, what side effects occur, or response behavior. The 'Postman JSON body' reference is vague.

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

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

The description is a single sentence, front-loaded with the action and resource, and contains no filler. It efficiently conveys the endpoint and body type.

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

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

The description is thin for a tool with a flexible object payload. It references a 'Postman JSON body' without explaining what that is or what fields are required, and it lacks any context about prerequisites or what happens after creation. While the output schema exists, the tool description alone would leave an agent needing external Postman documentation.

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

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

Schema description fully covers the single 'extra' parameter with examples (name, email, package). The tool description adds no additional meaning about payload structure or syntax, so the baseline of 3 for high schema coverage is appropriate.

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

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

The description specifies the exact action ('Create a whitelabel client') and the HTTP endpoint (POST /v1/whitelabel/create-client), making the purpose unmistakable. It clearly distinguishes from the sibling 'create-whitelabel-package' tool by explicitly naming 'client'.

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

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

The description clearly implies this tool is for creating a whitelabel client, but provides no explicit when/when-not guidance or alternatives. It does not mention prerequisites (e.g., needing a whitelabel package first) or contrast with list-whitelabel-clients or update-like tools.

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

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

Annotations already indicate write intent (readOnlyHint=false) and non-destructiveness. The description adds the endpoint and that it uses a Postman JSON body, but does not disclose details like required permissions, idempotency, or response behavior. It captures the essential behavior without contradicting annotations.

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

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

The description is a single, focused sentence with no redundant information. It front-loads the action and resource, then provides the method and payload source efficiently.

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

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

Given the tool has an output schema, annotations for safety, and a single parameter, the description provides adequate context: it specifies the endpoint and where to find the payload. It could elaborate on prerequisites or response handling, but for a create operation with an open-world parameter, it is sufficiently complete.

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

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

The schema has 100% coverage for the single 'extra' parameter, with a description referencing Postman documentation. The tool description also mentions 'Postman JSON body', adding slight context. However, the actual contents of the payload are not described beyond 'as documented in Postman', which is minimal but acceptable given the free-form object.

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

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

The description clearly states the action 'Create' and the resource 'whitelabel package', with an explicit endpoint. It distinguishes from sibling tools like 'create-whitelabel-client' and 'list-whitelabel-packages' by including the package-specific endpoint.

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

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

The phrase 'Create a whitelabel package' implies when to use the tool, but it does not explicitly mention when not to use it or provide alternative tools (e.g., 'list-whitelabel-packages' for listing). This is an implied usage rather than explicit guidance.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds the word 'permanently' and the HTTP method, reinforcing the destructive nature. However, it does not provide additional behavioral context such as irreversibility confirmation, authorization requirements, or side effects beyond what the annotations imply.

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

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

The description is a single sentence, front-loaded with the key action 'Permanently delete,' and contains no redundant filler. Every word contributes to clarifying the tool's purpose and method.

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

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

Given the simple interface (one parameter, output schema present, strong annotations), the description is sufficiently complete. It states the action, the target identifier, and the HTTP method. It does not explain return values, but the output schema handles that. The only minor omission is that it doesn't explicitly mention irreversibility beyond 'permanently,' which is largely covered.

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

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

The schema covers the only parameter (bot_id) with 100% coverage, describing it as 'Numeric bot id of the agent to delete.' The description repeats this by saying 'by numeric bot id,' adding no new meaning. Thus, the description relies on the schema, and the baseline of 3 applies.

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

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

The description clearly states the tool's function: 'Permanently delete an agent by numeric bot id via DELETE /v1/delete-agent/{id}.' It specifies the verb (delete), resource (agent), and method (DELETE), and it distinguishes from sibling tools like 'delete-agent-versions' which targets versions, not the whole agent.

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

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

The description implies usage (permanent deletion of an agent) but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. There is no comparison to other agent-management tools like deactivate or clone.

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

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

Annotations already mark the tool as destructive and non-read-only. The description adds meaningful context beyond annotations: the active/inactive version constraint and the HTTP endpoint. It does not elaborate on reversibility, but the destructive hint covers that.

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

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

The description is one concise sentence with no redundancy. It front-loads the action and resource, then immediately states the critical constraint.

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

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

Given the tool's low complexity (one parameter), rich annotations (destructive, idempotent), and the presence of an output schema, the description is sufficient. It covers the core function and the key usage limitation without needing to explain return values.

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

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

The schema description covers the only parameter (version_ids) with 'One or more inactive version ids to delete', achieving 100% coverage. The tool description adds no extra parameter detail beyond restating the inactive version constraint, so the baseline of 3 applies.

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

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

The description clearly states the tool's purpose with a specific verb (delete), resource (agent versions), and scope (inactive only). It also distinguishes from siblings like activate-agent-version by noting active versions cannot be deleted.

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

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

The description provides clear context on when to use the tool: only for inactive agent versions, with the explicit exclusion that active versions cannot be deleted. Though it doesn't name sibling tools like list-agent-versions, the constraint effectively guides usage.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, etc.), the description discloses concrete behavioral effects: making the version active and copying instructions into bot_flow. This adds useful context for the agent. No contradictions with annotations.

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

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

The description is a single sentence that packs essential information: endpoint, action, and side effects. No filler or redundancy; every part earns its place.

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

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

For a tool with two optional parameters, a rich schema, and an output schema, the description is sufficient. It covers the purpose, endpoint, and key side effects. Minor gap: no explicit guidance on when to use this vs. activate-agent-version, but that is partially covered by the side-effect statement.

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

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

The schema provides 100% coverage with descriptions for both parameters. The tool description does not add any further meaning beyond what the schema already documents, so a baseline 3 is appropriate.

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

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

The description clearly states a specific verb ('Deploy'), resource ('a version'), and the endpoint (POST /v1/deploy-ai-agent). It also distinguishes this tool from siblings like 'activate-agent-version' by noting the additional side effect of copying instructions into bot_flow.

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

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

The description provides clear context: deploying makes the version active and copies instructions into bot_flow. It implies when to use this tool (full deployment) versus merely activating, but does not explicitly name alternatives or exclusion conditions. This is clear context without formal alternatives.

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

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

Annotations already disclose readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the endpoint (POST /v1/bot-dashboard-stats) and optional date parameters, but no further behavioral context like authentication or response formatting. With annotations handling the key behavioral traits, this is adequate but not particularly rich.

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

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

The description is a single, efficient sentence that conveys the action, endpoint, and optional parameters. No filler or redundant content, and it is front-loaded with the core purpose ('Fetch bot analytics').

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

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

Given the tool's simplicity (2 optional params, no required fields), the presence of an output schema, and annotations that cover read-only behavior, the description is complete enough for an agent to select and invoke the tool appropriately. It does not need to explain return values since an output schema exists.

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

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

Schema description coverage is 100%, and both parameters already have clear descriptions ('Range start date in YYYY-MM-DD format' and 'Range end date...'). The description merely says 'optional date_from and date_to' without adding any additional semantic value beyond what the schema provides. Baseline 3 applies.

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

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

The description clearly states the tool's purpose: 'Fetch bot analytics' via a specific endpoint, with the scope (analytics/dashboard stats) distinguishing it from sibling tools like get-bot-details or list-owned-bots. It uses a specific verb and resource, leaving no ambiguity about 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.

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

The description implies usage context ('fetch bot analytics') and mentions the optional date range, but does not explicitly state when to use this over sibling tools or provide exclusions. It gives clear context without alternative guidance, which fits a 'clear context, no exclusions' scenario.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is covered. The description adds useful context by specifying the data fields returned (agent_type, versions, LLM config, counts) and the HTTP endpoint, going beyond the generic annotation hints. No contradiction with annotations.

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

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

The description is a single sentence that front-loads the action and object, then compactly lists the key response contents and endpoint. There is no filler or redundancy; every word contributes meaning.

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

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

This is a simple zero-parameter read tool with rich annotations and an output schema present. The description's enumeration of fetched fields and the endpoint, combined with the existing structured metadata, fully equips an agent to select and invoke the tool correctly.

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

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

The tool has zero parameters and an empty schema, so schema coverage is trivially 100%. With no parameters to document, the description does not need to add parameter-level detail; the baseline of 4 for parameterless tools is appropriate.

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

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

The description uses the specific verb 'Fetch', identifies the resource as the 'selected bot record', and enumerates key contents (agent_type, versions, LLM config, related counts). It also includes the exact endpoint GET /v1/bot/get-data, making it clearly distinct from sibling list/update tools.

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

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

The phrase 'selected bot' clearly indicates the tool operates on a currently selected bot, implying use after a selection step. However, it does not explicitly mention when not to use it or name alternatives such as get-bot-dashboard-stats or list-owned-bots, so it stops short of full guidance.

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

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

Annotations already convey read-only, idempotent, and non-destructive behavior, lowering the burden. The description adds the endpoint and a single-fbId scope, which is useful but does not enrich behavioral understanding further (e.g., pagination, limits, or error semantics). No contradiction with annotations.

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

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

The description is a single, well-structured sentence that is front-loaded with the action and resource. It avoids unnecessary words and includes the essential endpoint detail, making it highly concise without losing clarity.

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

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

For a simple one-parameter read tool with rich annotations and an output schema, the description covers the core purpose and scope. It could briefly mention when to use it relative to siblings, but the combination of schema, annotations, and the endpoint makes it sufficiently complete 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.

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

Schema coverage is 100% with fbId described as 'End-user fbId'. The description only repeats 'for one fbId', adding no new semantic depth beyond the schema. The baseline of 3 applies because the schema carries the parameter meaning adequately.

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

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

The description clearly states a specific verb ('Fetch') and resource ('converse conversation history') and includes the HTTP endpoint for precision. It implicitly distinguishes from sibling tools by focusing on 'converse' history for one fbId, which is a unique scope.

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

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

The description gives a usage context: it fetches history for a single fbId via a specific endpoint. However, it does not explicitly mention when to use this tool versus alternatives like list-conversations or get-user-chat, nor does it provide any exclusionary guidance. The context is clear but not fully fleshed out.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering the basic safety profile. The description adds that it uses POST and is 'legacy', offering some context, but does not disclose side effects, rate limits, or operational nuances beyond annotations.

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

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

A single sentence that front-loads the action and resource, with no filler or redundancy. Every word contributes to the clarity of the tool's purpose.

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

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

Given the low complexity (2 simple params) and presence of an output schema, the description is largely adequate. The 'legacy' hint could have been expanded to contrast with a modern alternative, but it does not leave critical gaps.

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

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

Schema description coverage is 100%, and both parameters (query, fbId) are thoroughly documented in the schema. The description merely restates 'query text and fbId' without adding any new meaning or constraints.

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

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

The description uses a specific verb 'Run' and identifies the resource as the 'legacy story matcher' with an explicit endpoint. It partially distinguishes from siblings by labeling it 'legacy', though it does not name a specific alternative.

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

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

No guidance is provided on when to use this tool versus alternatives. The word 'legacy' implies an older version but does not specify use cases 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.

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the singular scope ('one user transcript') and the HTTP method (POST), but does not disclose return format, error behavior, authentication needs, or rate limits. It aligns with annotations and adds minimal context beyond them.

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

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

The description is a single concise sentence that directly states the action, resource, endpoint, and parameter. It is front-loaded with the verb 'Fetch', contains no unnecessary words, and every element is relevant.

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

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

For a simple read-only tool with one parameter and an output schema present, the description provides sufficient context: it specifies what is fetched (one user transcript), how (POST /v1/get-chat), and using which parameter (end-user fbId). Return values are covered by the output schema, so no further explanation is needed.

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

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

The input schema already describes the only parameter fbId with a clear description ('End-user fbId whose transcript you want'), achieving 100% schema coverage. The description repeats 'using the end-user fbId' without adding format, constraints, or additional 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.

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

The description uses the specific verb 'fetch' and identifies the resource as 'one user transcript', clearly distinguishing it from sibling tools like list-conversations or get-converse-history by emphasizing the singular nature and the fbId-based retrieval. The mention of the POST endpoint adds further specificity.

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

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

Usage context is implied by the phrase 'one user transcript' and the fbId parameter, suggesting it is for retrieving a single user's chat transcript. However, there is no explicit guidance on when to use this tool instead of alternatives like list-conversations or get-converse-history, nor any exclusions or prerequisites.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds the HTTP method POST, which is useful context for a read operation and does not contradict annotation hints. No additional behavioral details (e.g., date handling) are provided, but the annotations carry the safety profile.

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

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

The description is a single, compact sentence that immediately states the tool's core action and endpoint. No filler or redundancy; it is front-loaded and efficient.

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

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

Given the tool's simplicity, the annotations, and the presence of an output schema, the description sufficiently covers the essential behavior. Minor gaps exist (e.g., date format expectations) but these are not critical for an agent to select and invoke the tool correctly.

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

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

The input schema provides 100% coverage with descriptions for all three parameters (start_date, end_date, and status with enum values). The description itself adds no parameter-specific meaning, so baseline 3 is appropriate when the schema already documents parameters.

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

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

The description clearly states the action (Fetch), the resource (WhatsApp broadcast delivery stats), and the specific endpoint (POST /v1/whatsapp-broadcast-report). This distinguishes it from sibling tools like send-whatsapp-broadcast and get-bot-dashboard-stats.

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

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

The description clearly conveys the tool's purpose as a retrieval/report tool for WhatsApp broadcast delivery stats, which implies usage when delivery information is needed. It does not explicitly name alternative tools or exclusion scenarios, but the context is unambiguous given the sibling set.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the behavior that when bot_id is omitted, the selected bot API key is used, and specifies the HTTP GET method, providing useful context beyond the annotations.

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

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

Two sentences with no redundancy. The first sentence gives the action and endpoint; the second explains the parameter option. Perfectly front-loaded and concise.

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

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

For a simple read-only list operation with one optional parameter, the description covers the endpoint, parameter behavior, and defaults. An output schema exists, so return values need not be described. This is complete for the tool's complexity.

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

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

Schema description coverage is 100% and already explains bot_id as 'Numeric bot id. When omitted, the selected bot API key is used.' The description repeats this information without adding new meaning, so baseline 3 is appropriate.

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

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

The description clearly states 'List instruction versions for an agent' with a specific verb and resource, and includes the HTTP endpoint 'GET /v1/bot/agent-versions'. This distinguishes it from sibling tools like activate-agent-version or delete-agent-versions that perform other actions.

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

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

The description gives clear usage context: 'Pass numeric bot_id or use the selected bot API key.' This explains two invocation modes but does not explicitly contrast with alternatives or state when not to use it. The context is sufficient given the straightforward listing purpose.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds the POST endpoint and pagination details, but does not disclose behavioral nuances like the requirement for a prior bot selection or any rate limits. It does not contradict annotations.

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

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

The description is a single concise sentence that front-loads the main purpose and includes the endpoint and key parameters. Every word earns its place with no fluff or redundancy.

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

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

Given the annotations, output schema, and simple parameter list, the description is fairly complete. It could be improved by explicitly noting the prerequisite of selecting a bot and differentiating from the similar 'list-messenger-users' tool, but it is adequate for the tool's complexity.

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

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

The schema description coverage is 100%, so the baseline is 3. The description only mentions 'limit and skip' without adding extra meaning beyond the schema, which already describes both parameters with defaults.

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

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

The description clearly states a specific verb ('List') and resource ('messenger users for the selected bot'). It also distinguishes from the sibling 'list-messenger-users' by scoping to a selected bot, and mentions the HTTP endpoint and pagination parameters.

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

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

The description implies usage for a selected bot and includes the endpoint, but it does not explicitly state when to use this tool over the similar sibling 'list-messenger-users'. There is no exclusion or alternative guidance, though the context is reasonably clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds the 'recent' qualifier and the POST endpoint, providing some behavioral context, but does not go into depth about pagination limits or filtering nuances. This warrants 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.

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

The description is a single sentence that front-loads the primary action and includes the endpoint and optional parameters, with no redundant information. It is concise and well-structured.

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

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

For a read-only list tool with two optional parameters, a detailed output schema, and comprehensive annotations, the description adequately covers the core functionality. The mention of 'recent' and the endpoint, combined with the schema and annotations, makes it sufficiently complete 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.

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

The input schema provides full descriptions for both parameters (page and source), achieving 100% schema description coverage. The description merely restates that they are optional and the channel, adding no new semantics beyond the schema, so a baseline 3 is applied.

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

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

The description clearly states the tool lists recent messenger conversations via a specific endpoint, with a clear verb and resource. It differentiates from siblings by specifying messenger conversations and the endpoint.

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

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

The description provides clear context that this tool lists recent conversations with optional page and channel parameters, but it does not explicitly mention alternatives or when not to use it. Since the name and description suffice for basic usage, it earns a 4 rather than 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is well-covered. The description adds the 'selected bot' scope and HTTP method, but does not discuss pagination behavior, authentication, or rate limits. Minimal extra context beyond annotations.

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

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

The description is one concise sentence that directly states the action, resource, and endpoint without any unnecessary words. It is immediately comprehensible.

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

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

For a simple list tool with one documented parameter, an output schema, and rich annotations, the description is adequate. It could mention pagination details or the meaning of 'selected bot' but the schema and annotations compensate.

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

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

The input schema has 100% coverage for the single 'page' parameter with a clear description ('Page number starting at 1'). The tool description adds no additional parameter semantics, so the baseline 3 is appropriate.

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

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

The description clearly states the tool lists messenger users for the selected bot and identifies the endpoint. It is specific with verb and resource, but it does not distinguish itself from the sibling tool 'list-bot-messenger-users', which has a nearly identical name and could be confusing.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'list-bot-messenger-users'. There is no mention of prerequisites, selection context, or exclusions, leaving 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.

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

Annotations already convey readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat that. It adds value by clarifying that the result includes both owned and shared bots, which is a subtle but important behavioral detail, and by exposing the underlying POST endpoint.

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

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

The description is a single, front-loaded sentence that efficiently packs the action, resource, scope, and endpoint without unnecessary words. It is a model of conciseness.

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

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

Given the simplicity of the tool (no parameters, an output schema exists, and annotations cover safety), the description is fully sufficient. It names the endpoint and scope, making it complete 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.

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

The tool has zero parameters, so the baseline for parameterless tools is 4. The description correctly adds no parameter information, and the empty schema confirms there is nothing to explain.

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

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

The description clearly states the action (List), the resource (bots), and the scope (owned and shared for the logged-in user), and even specifies the HTTP endpoint (POST /v1/get-bots). This distinguishes it from sibling tools like list-workspace-agents by focusing on user-level bots.

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

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

It provides clear context by specifying 'for the logged-in user', which helps an agent decide when to use it. However, it does not explicitly compare against alternatives like list-workspace-agents or get-bot-details, nor does it mention exclusions or when-not-to-use conditions.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the GET endpoint and the dual-type listing behavior, but does not describe pagination or return handling. Given the existing annotations and output schema, this is acceptable but not exceptionally rich.

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

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

One sentence that front-loads the action and resource, includes the endpoint, and contains no redundant text. It earns its place efficiently.

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

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

For a simple list tool with an output schema, annotations, and optional parameters, the description is sufficient. It covers the core purpose and the SMS option; pagination behavior is implied by the per_page parameter in the schema.

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

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

The schema covers all three parameters with clear descriptions (type, query, per_page), so the description adds no parameter-level meaning. Baseline 3 applies because schema_description_coverage is 100%.

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

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

The description clearly states the action 'List' and the resource 'WhatsApp or SMS templates', plus the specific endpoint. It distinguishes from sibling create-whatsapp-template and other list tools by naming the exact scope.

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

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

Provides clear context for when to use the tool (listing templates) and indicates the SMS vs. WhatsApp distinction via the type parameter. However, it does not explicitly mention alternatives or exclusions, though the sibling naming makes them obvious.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the specific GET endpoint and the 'logged-in partner' scope, providing useful behavioral context beyond the annotations. It does not mention pagination or rate limits, but the annotations and output schema cover the safety profile.

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

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

The description is a single, front-loaded sentence that directly states the action, resource, scope, and HTTP method. 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.

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

For a simple list operation with no parameters, the description is complete: it names the endpoint, the actor (logged-in partner), and the resource. The output schema exists to define the response structure, and annotations cover safety and idempotency. No further details are necessary.

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

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

The input schema has zero parameters, and schema coverage is 100%. The description adds no parameter details because none exist. With no parameters, the baseline is 4, and the description sufficiently explains the simple invocation.

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

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

The description states a specific verb ('List'), a clear resource ('whitelabel clients'), and scope ('for the logged-in partner'), along with the HTTP endpoint. This distinguishes it from sibling tools like create-whitelabel-client (creation) and list-whitelabel-packages (packages vs clients).

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

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

The description provides clear context: this is for listing clients belonging to the logged-in partner, via GET. While it does not explicitly mention alternatives or when not to use it, the action is unambiguous enough for an agent to select it when needing to list whitelabel clients, and the sibling tool names further disambiguate.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the HTTP GET method, which reinforces read-only behavior, but provides no additional context like pagination or permission requirements. With annotations present, this is adequate but not exceptional.

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

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

A single, front-loaded sentence that directly conveys purpose and method. No filler or redundancy.

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

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

For a zero-parameter list operation with strong annotations and an output schema, the description is fully sufficient. The endpoint is specified, and no additional requirements (e.g., permissions, filters) are needed.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty schema). The description does not need to explain parameters, and the baseline of 4 applies since there are no parameter semantics to clarify.

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

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

The description clearly states the action 'List' and the resource 'whitelabel packages', with the HTTP endpoint providing additional specificity. It distinguishes itself from sibling tools like 'create-whitelabel-package' and 'list-whitelabel-clients'.

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

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

The tool's purpose is self-evident as a read-only listing operation, and the context makes it clear when to use it. However, it does not explicitly mention alternatives or conditions when not to use it, so it stops short of a 5.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds the endpoint and parameter names but does not disclose additional behavior such as pagination defaults, sorting, or error handling. It adds some value beyond annotations but is not rich in behavioral context.

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

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

The description is a single, focused sentence that front-loads the primary purpose and includes the endpoint and optional parameters. There is no irrelevant information or redundancy.

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

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

With a rich annotations set and an output schema, the description need not explain return values. It adequately conveys the operation and optional parameters. However, it could be slightly more complete by mentioning pagination behavior or filtering nuances, though these are mostly covered by the schema.

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

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

Schema description coverage is 100%, so the schema already describes all four parameters (tab, page, query, per_page). The description only paraphrases parameter names (page, search query, tab, page size) without adding semantic meaning beyond what the schema provides.

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

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

The description clearly states the tool lists agents in the authenticated workspace via a specific endpoint, distinguishing it from siblings like list-owned-bots or list-agent-versions. The verb 'List' and resource 'workspace agents' are 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.

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

The description provides clear context for what the tool does but does not explicitly state when to use it over alternatives. It mentions the endpoint and optional parameters but lacks exclusion or alternative recommendations, which would be helpful given similar sibling tools.

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

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

Annotations already indicate a non-read-only, non-idempotent operation. The description adds context by naming the exact API endpoint and revealing the side effect of storing the Bearer token in the session, which is valuable beyond the annotations. It does not contradict any annotation.

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

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

A single concise sentence that front-loads the action and includes the endpoint and purpose. No filler or redundancy, every word contributes.

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

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

With only two well-documented parameters and an output schema available, the description sufficiently covers the tool's operation. It could be improved by explicitly stating that this is a prerequisite for authenticated endpoints, but 'for later tools' already conveys that. Overall it is complete for a simple login tool.

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

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

Schema coverage is 100% and each parameter already has a clear description (email with format and fallback, password as account password). The description merely repeats 'using email and password' without adding new semantics, so baseline 3 is appropriate.

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

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

The description states a specific action (log in) with a specific resource (Botsify Authorization API POST /v1/login) and explains the outcome (store Bearer token for later tools). It clearly distinguishes this tool from siblings like create-oauth-token or select-bot by focusing on email/password session login.

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

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

The phrase 'store the Bearer token for later tools in this session' implies this should be invoked before other authenticated tools. However, it does not explicitly mention when not to use it or compare with alternatives such as create-oauth-token, so it lacks explicit exclusions.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds the HTTP endpoint, which is useful, but it does not disclose behavioral traits like whether the update overwrites the entire section or how empty content is handled (though the schema covers this). No contradiction with annotations.

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

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

The description is two concise sentences, front-loaded with the action and resource, followed by a necessary constraint. No fluff or redundancy, making it highly efficient.

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

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

Given the rich schema (100% coverage) and existing annotations, the description sufficiently explains the core purpose and allowed field values. It does not need to repeat parameter details or return values, though it could clarify the update semantics (overwrite vs merge), which prevents a higher score.

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

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

Schema description coverage is 100%, so all parameters are already documented. The description only repeats the enum values for 'field' already present in the schema, adding no new meaning to the parameters.

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

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

The description clearly states a specific action: 'Update one instruction column on a version via POST /v1/update-instruction.' It identifies the resource (instruction column on a version) and differentiates from siblings like save-agent-version by specifying it updates only one column, not the entire version.

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

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

The description gives context (updates a single instruction column) and lists allowed field values, but it does not explicitly state when to use this tool versus alternatives like save-agent-version or activate-agent-version. No when-not-to-use guidance is provided, so usage is implied rather than explicit.

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

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

Annotations already convey that the tool is non-idempotent, open-world, and non-destructive. The description adds the POST endpoint, X-Api-Key header, and fbId requirement, which is useful context beyond annotations, but it does not elaborate on side effects, rate limits, or other behavioral nuances.

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

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

The description is a single concise sentence, front-loaded with the action and resource, and includes only essential information. There is no unnecessary wording or repetition.

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

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

With 2 well-documented parameters and an output schema present, the description plus annotations cover the essential invocation details (endpoint, authentication). It lacks usage scenario guidance, but for a simple query tool, this is sufficiently complete.

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

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

The input schema fully documents both parameters with clear descriptions. The description itself only mentions fbId and 'agentic query' without adding any new semantic detail beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Send') and resource ('agentic query') and includes the exact endpoint and authentication method, clearly distinguishing it from sibling CRUD operations. This makes the tool's purpose unambiguous.

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

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

The description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. It implies usage by describing the operation itself, but lacks direct guidance on scenario selection.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, which communicates the write nature and safety. The description adds that the operation uses POST, but it does not disclose additional behavioral details such as permissions required, side effects, or reversibility. With annotations covering the core safety profile, this is acceptable but not enriched.

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

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

The description is a single sentence that front-loads the action and mentions the endpoint and required parameters. There is no wasted wording, and it is appropriately sized for the tool's simplicity.

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

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

This is a simple rename operation with only two well-documented parameters and an output schema. The description provides the endpoint and parameter roles, which is sufficient for typical usage. It does not mention error cases or prerequisites, but these are not critical given the simplicity and available structured data.

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

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

The input schema fully documents both parameters with clear descriptions: bot_id is the numeric id, bot_name is the new display name. The description simply restates this ('using the numeric bot id and the new display name'), adding no new meaning beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the action: 'Rename an agent via POST /v1/update-bot-name'. It identifies the resource (agent), the specific verb (rename), and even the endpoint. This distinctly separates it from sibling tools like create-agent or delete-agent, which perform different operations on agents.

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

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

The description explains what the tool does but does not explicitly state when to use it versus alternatives. The action of renaming is self-evident, and the sibling list suggests other agent operations, but no direct comparison or exclusion is provided. This makes the usage context implied rather than explicit.

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

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

The annotations already indicate this is a write operation (readOnlyHint=false), and the description adds the useful constraint of requiring full agent text and chat_flow JSON. However, it does not disclose that the tool can also update existing versions (via the 'edit' and 'version_id' parameters), which is a behavioral nuance not covered by annotations.

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

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

The description consists of two concise sentences that front-load the action and then provide a critical usage constraint. 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.

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

The tool has 10 parameters and an output schema, so the schema covers return values and parameter details. The description captures the core purpose and key constraint (full payload), but does not explicitly clarify the dual create/edit behavior. This is a minor gap given the schema already documents the 'edit' and 'version_id' fields, making it sufficiently complete for most use cases.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explicitly stating that 'agent' and 'chat_flow' must be sent in full, not as partial chunks, which clarifies the most important parameter relationship beyond the schema's individual descriptions.

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

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

The description clearly states the tool's purpose: 'Create an instruction version via POST /v1/update-agent.' It uses a specific verb (Create) and resource (instruction version), and the added 'Send the full agent text plus chat_flow JSON, not a partial chunk' distinguishes it from sibling tools like patch-instruction-section, which likely handles partial updates.

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

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

The description provides clear context that this tool is for creating instruction versions and emphasizes sending the full payload rather than partial chunks. However, it does not explicitly name alternatives or state when not to use this tool, making the usage 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.

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

The description adds behavioral context beyond the annotations: the key is applied to later calls, and the selection persists as 'last_selected_bot' until switched. This explains the side effects of the mutating operation, going beyond the idempotent and readOnly hints.

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

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

The description is two sentences, front-loaded with the main action, and contains no redundant phrasing. Every sentence earns its place.

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

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

For a one-parameter tool with an output schema, the description is complete: it explains the effect on later calls, the persistence of the selection, and the default behavior after login. No further context is needed.

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

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

The schema description covers the single parameter (apikey) fully, including where to get it. The tool description adds no additional parameter detail, which is acceptable given 100% schema coverage, so the baseline of 3 applies.

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

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

The description clearly states the tool's function: 'Set the bot API key used as apikey and bot_key on later calls.' It uses a specific verb ('Set') and resource ('bot API key'), and the note about 'last_selected_bot' being the default distinguishes it from other bot-related tools.

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

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

The description gives clear context: after login, the last selected bot is the default until you switch, implying this tool is used to change that selection. It doesn't explicitly mention alternatives, but the intended use is evident.

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

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

Annotations already indicate non-read-only, non-idempotent behavior, so the description carries a lighter burden. It adds that the request is non-streaming and uses POST, but doesn't elaborate on side effects, authentication, or rate limits. No contradiction.

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

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

Single concise sentence with no redundant words, front-loads the verb and endpoint, and is easy to parse.

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

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

Given the simple schema and output schema present, the description covers the core action but omits context about bot_key sourcing, error handling, and selection among sibling tools. Adequate for straightforward use.

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

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

Schema description coverage is 100%, so parameters are well-documented. The description adds mention of bot_key, but bot_key is not in the schema, creating slight ambiguity. It does not add further parameter details.

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

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

The description clearly states the tool sends a non-streaming converse request via POST /v1/converse, identifying the specific endpoint and key fields. This distinguishes it from streaming siblings like stream-user-message and other send tools.

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

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

The description implies usage for non-streaming converse requests but does not explicitly state when to prefer this over alternatives like send-user-message or stream-user-message. No exclusions or alternative tools are mentioned.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description is consistent with a write operation. It adds the HTTP method and endpoint, which gives a bit more context, but does not disclose any side effects, permission requirements, or error behavior beyond that.

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

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

The description is a single concise sentence that front-loads the action, resource, and endpoint, then lists the required parameters. There is no filler or redundant information.

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

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

Given the small parameter set, full schema coverage, and presence of an output schema (not shown), the description is adequately informative for a message-sending tool. It doesn't explain return values, but the output schema presumably covers that, and annotations handle the write nature.

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

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

All three parameters have descriptions in the input schema (100% coverage), and the description repeats their names but adds no additional semantic detail. The schema already explains bot_id, fbId, and message, so the description provides minimal extra value.

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

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

The description clearly states the verb 'Send' and the resource 'live-chat inbox message', along with the HTTP endpoint POST /v1/send-message. It mentions the key parameters, making the tool's function obvious. However, it does not explicitly differentiate from sibling tools like send-user-message or send-converse-message.

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

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

No guidance is provided on when to use this tool versus alternatives. The description simply states what the tool does without mentioning alternatives or exclusion criteria. There is no 'use this for' or 'instead of' language.

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

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

Annotations already indicate readOnlyHint=false, and the description's mention of 'POST' reinforces the write nature without adding much new context. It references 'converse JSON format' without explanation, and does not disclose authentication requirements, rate limits, or failure behavior. The description adds minimal value beyond the annotations.

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

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

The description is a single, efficient sentence that front-loads the core action and endpoint. However, its brevity leads to missing essential details, so it is concise but not optimally structured for completeness.

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

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

With 6 parameters and sibling tools that overlap in functionality, this description is too minimal. It does not explain when to choose this tool, what default channels are used, or how the 'converse JSON format' differs from alternatives. Although an output schema exists to cover return values, the lack of selection and operational context makes the description incomplete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's only parameter information ('Use to as fbId or phone') is redundant with the schema's existing property description for 'to'. No additional meaning is provided for other parameters like 'message', 'type', 'format', 'tag', or 'user_id'.

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

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

The description clearly states the tool's function: 'Send an outbound message to an end user' with a specific action verb and resource. It also mentions the endpoint and a key parameter nuance ('Use to as fbId or phone'). However, it does not distinguish this tool from sibling tools like send-converse-message or send-inbox-message, so it misses the highest score.

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

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

There is no guidance on when to use this tool versus alternatives. The only usage hint ('Use to as fbId or phone') is a parameter detail, not a tool-selection guideline. No exclusions or alternative tools are mentioned, leaving the agent without contextual decision support.

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

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

Annotations already indicate a non-read-only, non-destructive operation. The description adds the endpoint and 'static or dynamic template' detail but does not disclose side effects like async behavior, rate limits, or report generation. With annotations covering the safety profile, a moderate score is appropriate.

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

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

The description is a single concise sentence, front-loaded with the key action and resource, and includes the endpoint. No unnecessary words or repetition of schema details.

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

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

Given the moderate complexity, presence of an output schema, and robust annotations, the description is largely complete. It covers the core purpose and differentiates through the endpoint, though it could explicitly state that this is for bulk broadcasts versus one-on-one messaging. Overall sufficient enough for an agent to select correctly.

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

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

Schema description coverage is 100%, so the schema already fully documents all parameters. The description adds minimal semantic value beyond the schema, mentioning static/dynamic templates but not directly explaining how parameters map to that behavior. Baseline 3 is warranted.

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

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

The description clearly states that the tool sends a WhatsApp template broadcast via a specific endpoint. It uses a specific verb ('Send') and resource ('WhatsApp template broadcast'), and it distinguishes from sibling tools like create-whatsapp-template or get-whatsapp-broadcast-report by focusing on the send action.

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

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

The description implies usage for sending broadcasts but provides no explicit guidance on when to use this tool versus alternatives like send-user-message or send-inbox-message. It does not mention exclusions or alternatives, leaving the decision to the agent's inference.

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

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

The description adds the HTTP method and endpoint, providing context beyond the annotations. However, it does not disclose whether setting an existing key overwrites the value or any validation behavior. Annotations already indicate idempotent and non-destructive, so this is acceptable 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.

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

The description is a single, well-structured sentence that front-loads the action and target, with no unnecessary words or repetition.

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

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

For a simple attribute-setting operation with full parameter documentation, a clear purpose, and annotations indicating idempotency and non-destructive behavior, the description is complete. An output schema exists, so return values need not be described. A minor omission is lack of details on overwrite behavior, but this is not critical.

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

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

The input schema covers all three parameters with descriptions, achieving 100% coverage. The description does not add additional parameter-level context, but the schema already provides sufficient meaning.

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

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

The description clearly states the action ('Set') and the target resource ('custom attribute on a messenger user'), and also provides the exact API endpoint. This is specific and distinguishes it from sibling tools like send-user-message or get-user-chat.

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

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

No explicit guidance is given on when to use this tool versus alternatives. The description does not mention prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage solely from the action.

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

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

The description adds behavioral detail beyond the annotations by mentioning the POST endpoint and the syncing of bot_flow with the active agent version. The annotations already indicate non-read-only (readOnlyHint=false) and non-idempotent (idempotentHint=false), which aligns with the described mutation. No contradictions.

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

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

The description is a single, focused sentence that front-loads the primary action and includes the essential behavioral detail. There is no unnecessary information or repetition.

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

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

For a simple tool with no parameters and an existing output schema, the description is complete. It explains what the tool does and key side effects (syncing bot_flow). The presence of sibling tools and annotations provides additional context without requiring more from the description.

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

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

The tool has zero parameters, so the schema coverage is trivially 100% and there is no parameter info to add. The description does not need to explain any inputs, and the baseline for 0-parameter tools is 4.

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

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

The description clearly states the action ('Start a new builder chat'), the resource (builder chat), and includes the specific endpoint (POST /v1/new-chat) plus the syncing behavior. This distinguishes it from other builder-related tools like stream-builder or store-builder-response.

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

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

The context of when to use the tool is clear: to start a new builder chat. It does not explicitly mention alternatives or when not to use it, but the description's clarity provides sufficient usage context for a tool with no parameters.

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

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

Annotations already declare idempotent (true), non-destructive (true), and not read-only (false). The description adds the specific REST endpoint and the 'in-progress' condition, which provides useful context beyond the annotations. It does not contradict annotations; 'cancel' aligns with readOnlyHint=false. No mention of error behavior, but idempotency covers redundant calls.

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

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

A single sentence that is front-loaded with the action ('Cancel') and efficiently conveys the endpoint and key requirement. No redundant words or filler. Perfectly concise and well-structured.

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

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

For a simple one-parameter cancellation tool, the description covers the core behavior, the target stream type, and the required stream id. With an output schema present, return values need not be described. It doesn't expand on what constitutes a 'builder stream' or error cases, but the idempotent annotation and low complexity make this adequate.

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

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

The schema already documents stream_id with 100% coverage, including its origin ('Stream id passed when stream-builder was started'). The description's phrase 'using the stream id' merely restates the schema and adds no new meaning. Baseline 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.

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

The description clearly states the tool cancels an in-progress builder stream and specifies the exact HTTP endpoint (POST /v1/stop-agentic-stream) and required identifier. It distinguishes from sibling tools like stream-builder (which starts a stream) and stop-user-message-stream (which stops a user message stream) by explicitly naming 'builder stream'.

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

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

The description clearly sets the context for use: canceling a builder stream that is currently in progress. It does not explicitly mention alternatives or exclusions (e.g., not for user message streams), but the action and target are unambiguous. The sibling stop-user-message-stream provides implicit differentiation, but explicit guidance would earn a 5.

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

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

Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the HTTP endpoint and mentions the need for a 'selected bot_key', but it does not describe side effects (e.g., whether the stream can be resumed) or any other behavioral details. No contradiction with annotations.

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

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

The description is a single sentence that leads with the primary action ('Stop a converse stream') and then provides the endpoint and required inputs. It is concise, front-loaded, and contains no extraneous information.

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

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

Given the low complexity (one parameter, output schema present) and rich annotations, the description is largely sufficient. It captures the tool's purpose and key inputs. The only minor gap is the under-specified 'selected bot_key' reference, which could be clearer, but overall the description is complete enough for a stop-stream operation.

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

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

The schema already has 100% coverage for the single parameter stream_id, including its origin from stream-user-message. The description adds meaningful context by mentioning that a bot_key is also used (even though not a schema parameter), clarifying the execution context beyond the schema.

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

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

The description clearly states the action ('Stop a converse stream') and the specific endpoint (POST /v1/converse/stop-stream). It distinguishes this from sibling tools like stop-builder-stream by referencing the user-message stream context and the stream_id parameter from stream-user-message.

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

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

The description implies usage by linking the stream_id parameter to 'stream-user-message', suggesting this tool is the complementary stop action. However, it does not explicitly state when to use this tool over stop-builder-stream or any other alternative, and it lacks clear exclusions.

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

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

The description states the tool performs a POST to store a response ID and explains the purpose, but it does not add much beyond the annotations. Annotations already indicate the operation is non-read-only, idempotent, and non-destructive. No additional behavioral details (e.g., overwriting behavior, error handling) are provided, so the description adds only moderate context.

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

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

The description is a single, concise sentence that packs action, endpoint, and rationale without redundancy. It is front-loaded with the key verb and object, and every word contributes to understanding the tool's function.

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

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

For a simple one-parameter store operation, the description conveys the essential workflow: persist the last builder response ID to continue the thread. It could be more explicit about the dependency on a prior builder streaming call, but the purpose implies it. Given the existing annotations and output schema, the description is sufficiently complete.

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

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

The schema fully documents the only parameter (response_id) with a description ('Builder response id returned by the model stream'). The tool description essentially repeats this concept ('last builder response id') without adding extra format constraints or additional meaning, so it does not exceed the baseline expected given 100% schema coverage.

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

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

The description clearly identifies the action ('Save'), the object ('the last builder response id'), and the purpose ('so the next builder turn can continue the thread'). It even includes the specific endpoint, making the tool's function unambiguous and distinguishing it from sibling tools like stream-builder or start-builder-chat.

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

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

The description implies when to use the tool: after receiving a builder response from the model stream, to persist the response ID for continuity. It does not explicitly mention alternatives or when not to use it, but the context is clear enough for an agent to infer the correct usage scenario.

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

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

Annotations already declare this is not read-only and not idempotent. The description adds the fact it uses POST and is streaming, yielding instruction output. However, it does not explain behavior around cancellation, state persistence, or open-world effects beyond the annotation hints.

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

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

The description is a single, information-dense sentence, front-loaded with the action. No redundant content or filler.

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

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

The tool is moderately complex with nested objects and streaming behavior. The description covers the core purpose but omits relationship to sibling streaming tools, how to consume the stream, and implications of openWorldHint. The output schema exists, so return value explanation is not required, but overall context feels incomplete.

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

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

The input schema already describes all three parameters thoroughly (messages array, extra object, stream_id string), achieving 100% coverage. The description does not add any additional parameter-level meaning beyond confirming chat messages are sent.

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

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

The description clearly states the tool runs the streaming agent builder via a specific POST endpoint, with action verbs 'Run' and 'Send', and specifies the resource ('agent builder', 'builder chat messages'). It distinguishes from sibling tools like stream-user-message by focusing on builder context and instruction output.

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

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

The description provides no guidance on when to use this tool versus alternatives such as start-builder-chat or stop-builder-stream. It does not mention exclusions, prerequisites, or scenarios for which the streaming builder is appropriate.

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

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

Annotations already indicate the tool is non-read-only, non-idempotent, and non-destructive. The description adds the endpoint and chat_complete behavior, but does not disclose additional side-effect risks, rate limits, or stream consumption details. No contradiction with annotations.

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

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

Two sentences convey the core purpose and a key variant, with no filler. Information is front-loaded and scannable.

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

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

Given the presence of an output schema and full parameter documentation, the description is adequate for basic invocation. However, it lacks context on streaming behavior (e.g., how to consume the stream) and does not differentiate from closely related sibling tools, leaving some ambiguity for the agent.

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

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

Schema description coverage is 100%, with all five parameters documented. The description's mention of chat_complete only repeats the schema's existing documentation, so it adds little beyond the schema.

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

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

The description states a specific verb ('Stream') and resource ('an agent reply') with an explicit endpoint, and scopes the target as 'website or API user', which differentiates it from builder-related tools and send-message tools.

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

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

It provides context that this tool streams messages and mentions the chat_complete toggle for a different endpoint, but does not explicitly state when to use this tool over siblings like send-user-message or stream-builder. The audience scoping ('website or API user') gives some guidance, but exclusions are absent.

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