Asyntai

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

Discloses only that it adds an image; no mention of persistence, overwrite behavior, URL validation, or side effects. Annotations only provide false hints, so the description carries the burden and doesn't meet it.

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, but the second sentence is meta-commentary about the description parameter and overlaps with the schema; it could be tightened without losing core 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?

For a simple create-like operation with no output schema, it states the basic action and key parameter nuance, but omits return behavior, errors, and usage context.

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

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

Schema covers all three parameters with descriptions; the tool description adds extra semantic context for the description parameter ('what the AI reads to decide when the image answers the question'), going beyond the schema's basic text.

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

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

States 'Add an image the chatbot may show' with a clear verb and resource, distinguishing it from list_images/delete_image. The second sentence is meta-instruction about the description parameter and slightly muddies the tool-level purpose.

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

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

No guidance on when to use this tool versus add_knowledge_text/add_product/add_webhook, no prerequisites, and no mention of how to decide among image-related 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?

Beyond the annotations, the description discloses that the entry is immediately usable by the chatbot and that it never replaces existing entries—useful behavioral details that help the agent predict side effects.

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

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

Two concise, focused sentences. No redundant information, and the key points are front-loaded.

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

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

For a simple create operation without an output schema, the description covers the essential context: what is added, to where, and the side effect of immediate availability plus non-replacement. It is sufficient for an agent to decide and invoke.

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 descriptions already fully cover the meaning of title, content, and website_id. The tool description adds no extra parameter-specific context beyond what is 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 (add), the object (a titled block of text), and the scope (to one website's knowledge base), distinguishing it from sibling tools that add URLs, set tags, or crawl.

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 versus alternatives like add_knowledge_url or set_knowledge_tags. The description implies it is for adding text content but does not state conditions or mention any comparable 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?

The description discloses the core mutating behavior (fetching and adding text) beyond what annotations indicate. It does not mention potential side effects like duplicate entries, fetch failures, or processing delays, but with annotations already covering non-readonly/non-idempotent traits, this is adequate.

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

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

The description is two concise sentences with the action stated first and usage guidance second. Every sentence adds value, and it is appropriately front-loaded for quick comprehension.

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 provides enough context for correct invocation: what the tool does, when to use it, and when to prefer an alternative. It does not detail failure modes or content-extraction nuances, but the schema and annotations cover the essential invocation details.

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?

Both parameters are fully described in the schema with 100% coverage, so the description adds little beyond what the schema already provides. The baseline of 3 applies because the schema carries the full parameter 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 tool fetches one web page and adds its text to the knowledge base, using specific verbs and a clear resource. It is explicitly distinguished from the related start_crawl tool by single-page versus whole-site 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 explicit usage guidance: 'Use this for a single page' and directly names the alternative for whole-site ingestion: 'To take in a whole site, use start_crawl instead.' This makes the selection criteria 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?

Consistent with readOnlyHint=false (it's a write operation). Adds the plan requirement as a constraint, but does not disclose other potential side effects (e.g., whether adding an existing product overwrites or errors). The description goes slightly beyond annotations by noting the plan prerequisite, but not significantly.

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

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

Extremely concise and to the point. One sentence conveys the action, purpose, and a key prerequisite 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?

Sufficient for a simple add operation. It explains the outcome (product card for chatbot) and the plan requirement, though it omits details about return values or error handling. Given no output schema and simple nature, it is adequately 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 covers 100% of parameters with individual descriptions, so the baseline is 3. The description does not add any extra meaning beyond what the schema already provides for parameters like name, price, image_url, etc.

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?

Clearly states the action ('Add a product') and the purpose ('the chatbot can show as a card'), distinguishing it from sibling tools like list_products or delete_product. The one-sentence description is specific and unambiguous.

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

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

Provides a prerequisite ('Needs the Standard plan or higher') but does not explicitly mention when to use this tool over alternatives (e.g., no reference to update_product or import tools). The plan requirement is useful context, but the description lacks guidance on when not to use it.

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 the tool is not read-only and not destructive. The description adds valuable behavioral details: the signing secret is shown only once, and a paid plan is required. 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 extremely concise, using three short sentences. It leads with the core purpose, then adds the key caveat about the signing secret, and finally the plan requirement. Every sentence earns its place.

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

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

The description covers the essential aspects: what the tool does, the one-time secret, and the paid-plan restriction. Since there is no output schema, it does not need to describe return values. It is sufficiently complete for a simple creation tool.

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

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

The schema already provides descriptions for all three parameters (100% coverage). The description does not add extra meaning beyond the schema, so it stays at the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Register a URL to receive events') and provides an example. It is easily distinguished from sibling tools like delete_webhook and list_webhooks.

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

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

The purpose is so clear that when to use it is implied, but the description does not explicitly state when not to use alternatives like list_webhooks or delete_webhook. It does mention the paid plan requirement, which is useful context.

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

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

Beyond annotations (readOnlyHint false, openWorldHint true), the description discloses two critical side effects: it spends one message from the monthly allowance and calls an external model provider. This informs the agent of cost and external dependencies, which is valuable behavioral context. 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 with no filler. The primary action and purpose are front-loaded, and the cost/external-call disclosure is placed as a natural follow-up. Every word earns its place.

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

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

Given the tool's simplicity, the schema covers parameters, annotations cover safety, and the description covers side effects and intent. It does not detail the return format or error handling, but for a simple ask-and-answer tool with no output schema, the provided information is sufficient for correct invocation.

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

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

Schema description coverage is 100%, with each parameter already well-documented (e.g., session_id for continuing conversations, website_id defaults to primary). The description adds no additional parameter-level insight, so it stays at the baseline of 3, relying on the schema to carry the semantic load.

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

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

The description states a clear verb+resource: 'Ask one website's chatbot a question and get the answer a real visitor would receive.' It adds a specific purpose ('test the bot') that differentiates it from conversation-management tools like send_agent_reply or list_conversations, making its role unambiguous.

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

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

It explicitly says 'Use this to test the bot', giving a clear when-to-use context. It does not mention when not to use it or name alternative tools, but the test-oriented purpose is distinct enough to guide an agent without further 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?

Beyond the annotations (which only indicate non-read-only and non-destructive), the description discloses that the operation adds a resource, returns an embed code, enforces plan limits by refusing, and triggers a crawl by default. This gives a clear picture of the side effects and failure conditions, exceeding what annotations alone provide.

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

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

The description is compact (two sentences) and front-loaded with the primary purpose, followed by constraints and side effects. Every sentence adds meaningful information without 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 create operation, the description covers the main result (embed code), the limit-based failure mode, and the default crawl behavior. It does not mention potential validation errors (e.g., invalid domain) or success response details, but given the absence of an output schema and the relative simplicity of the tool, this is reasonably complete. A minor gap prevents a 5.

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

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

The schema already provides descriptions for all three parameters (name, crawl, domain), achieving 100% coverage. The description adds only marginal context—such as the 'by default' behavior for crawl—but does not materially enhance per-parameter understanding beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Add a new website'), the resource ('website (a new AI agent)'), and the key return value ('embed code'). It is easily distinguished from sibling tools like get_website or list_websites, and the parenthetical clarifies the domain-specific meaning of 'website'.

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 useful constraints (plan limits and refusal behavior) and notes the default crawl side effect. It does not explicitly name alternative tools, but the action is unambiguous enough that an agent can infer when to use this tool versus get/list/update variants. Lacks a direct 'use this instead of X' hint, hence not 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?

The description clearly indicates the destructive effect of removing an image, which aligns with the destructiveHint and readOnlyHint annotations. It does not mention idempotency or output, but the annotations already cover those aspects and the description adds the user-visible effect.

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, short sentence that states the action, target, and effect without any redundant words or unnecessary detail.

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

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

For a simple single-parameter destructive operation with no output schema, the description combined with annotations and parameter schema provides all the context needed to invoke the tool correctly.

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

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

The input schema fully describes the only parameter, image_id, and its source ('Image id from list_images'). With 100% schema coverage, the description adds no additional parameter detail, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Remove') and names the resource ('one image') and the intended effect ('so the chatbot stops showing it'), which makes the tool's purpose unambiguous and distinct from sibling tools like add_image.

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: when an image should no longer be shown by the chatbot. It does not explicitly contrast with alternatives, but the purpose is clear enough for an agent to select it appropriately.

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?

Description explicitly states permanence ('cannot be undone') and cascading deletion ('every passage built from it'), which aligns with and enriches the destructiveHint and idempotentHint annotations without 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?

The description is two concise sentences covering all essential information without redundancy or irrelevant 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?

Fully covers the scope of deletion, permanence, effect on the chatbot, and source of the id, making the operation complete and unambiguous 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?

The single parameter entry_id is clearly described as coming from list_knowledge, providing sufficient context for the expected value even beyond the schema's own description.

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?

Clearly states the action (permanently delete), the resource (knowledge base entry and its passages), and distinguishes from sibling tools that add or list knowledge.

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 explicit guidance that the chatbot stops using the content immediately and indicates the entry id comes from list_knowledge, which gives the user a clear path to invoke correctly.

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

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

The annotations already indicate destructive and idempotent behavior, so the description does not need to restate those. It adds the behavioral outcome that after deletion the chatbot stops offering the product. It does not mention irreversibility, but destructiveHint covers that concern.

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

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

The description is a single clear sentence with no filler or redundant information. It efficiently states the action, the object, and the 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?

For a simple single-parameter destructive operation, the description combined with the schema and annotations is sufficient. It explains the effect on the chatbot's offerings, and no output schema exists, so return-value details are not needed. Additional error-case behavior would be nice but is not essential.

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

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

The schema fully documents the only parameter, product_id, including its source from list_products. The description adds no additional parameter-level details, which is acceptable because schema 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 states a specific action ('Remove one product') and the intended effect ('so the chatbot stops offering it'). It clearly identifies the resource type and contrasts with sibling tools like delete_image or delete_webhook by being product-specific.

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

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

The purpose clause implies when to use the tool: when a product should no longer be offered. It does not explicitly name alternative tools such as add_product or list_products, but the product_id parameter description references list_products, giving practical guidance for obtaining the required ID.

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 goes beyond the destructiveHint annotation by stating that webhook events stop immediately. It does not describe error behavior, but for a simple delete that is not required.

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

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

Two short sentences with no filler; the action is stated first and the consequence second, making the description easy to scan.

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

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

For a single-parameter delete operation, the description and schema provide enough context: what is deleted and what happens as a result. No output schema exists, but a delete confirmation is not essential to know before calling.

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 description itself adds no parameter detail, but the schema fully documents webhook_id as coming from list_webhooks, so parameter meaning is already covered.

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

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

The description begins with the specific verb 'Delete' and the resource 'one webhook', making the action unambiguous. It is clearly distinct from the sibling tools add_webhook and list_webhooks.

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?

'Events stop reaching that address at once' explains the practical effect and therefore when this tool is appropriate. It does not explicitly contrast with alternatives, but the action is straightforward enough that no alternative guidance is needed.

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 readOnly, idempotent, and non-destructive behavior, so the description does not need to restate these. The description adds detail about the returned data but does not go beyond the annotations in describing side effects.

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

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

The description is a single, focused sentence with no redundant wording. It front-loads the action and immediately lists the key data points returned.

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

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

Given the absence of an output schema, the description sufficiently enumerates what the caller can expect: email, plan, and chat message usage against the monthly allowance. This is complete for the tool's low 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 input schema has no parameters, so there is nothing for the description to explain. The tool takes no arguments, and the description appropriately focuses on the output rather than 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 tool returns the signed-in account's email, plan, and chat message usage against its monthly allowance. This is a specific and unambiguous verb-resource pairing that distinguishes it from the many list- and search-oriented sibling 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 makes the tool's purpose obvious but does not explicitly state when to prefer it over alternatives. Since no other sibling tool targets account details, the context is sufficient, but explicit guidance is absent.

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

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

The annotations already provide readOnlyHint, idempotentHint, and non-destructiveHint, so the safety profile is covered. The description adds useful context by specifying that this retrieves the chatbot's role, tone, and rules, while making no contradictory claims about side effects.

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

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

The description is a single, focused sentence with no filler or redundant details. It front-loads the action and resource, and the clarifier about role, tone, and rules is concise and useful.

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 retrieval tool with one optional parameter and no output schema, the description provides enough context for correct use. The scope and content of the returned instructions are sufficiently indicated, and the schema fills in the parameter behavior.

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

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

The single optional parameter website_id is fully explained in the schema, including its source and default behavior when omitted. Since schema coverage is 100% and the tool description adds no additional parameter context, the baseline score of 3 is appropriate.

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

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

The description clearly identifies the action ('Get'), the resource ('AI instructions'), and the scope ('one website's chatbot'). It also names the content dimensions ('role, tone and rules'), which distinguishes it from sibling tools like get_website or get_widget_settings.

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 intended use is implied by the description and parameter semantics, but there is no explicit guidance about when to choose this tool over alternatives such as update_ai_instructions or get_widget_settings. It does not state when to use it versus related read tools, though the purpose 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?

The readOnly and idempotent annotations already cover the non-destructive nature, and the description reinforces a pure summarization behavior. It additionally clarifies the scope ('one website') and the kind of data included, which goes slightly 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, compact sentence with no redundant phrases. It front-loads the core purpose and then efficiently lists the included metrics, making it easy to scan.

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

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

With no output schema, the description compensates by naming the principal metrics returned. It does not specify grouping, timezone handling, or exact formatting, but for a summary analytics tool the enumerated metrics provide adequate context for most agents.

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

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

The input schema already provides full descriptions for both parameters, including defaults and source for website_id. The description adds contextual alignment by mentioning 'over a period' and 'one website', but it does not need to repeat parameter details since schema coverage is complete.

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

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

The description clearly states a specific action ('Summarise') and resource ('one website's chat activity over a period'), and enumerates the concrete metrics returned: conversations, messages, leads, escalations, and visitor countries. This distinguishes it from sibling tools that operate on raw conversations, leads, or daily reports.

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 when an aggregate summary of chat activity is needed, and the period parameter is referenced. However, it does not explicitly contrast with alternatives like get_daily_report or list_conversations, leaving some ambiguity about when to prefer this tool.

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 false, covering the safety profile. The description adds only the phrase 'in full', which hints at the completeness of the returned content. It does not disclose any other behavioral details such as error handling, pagination, or response format. Given the annotations cover the main safety aspects, a score of 3 is appropriate as the description adds minimal extra 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 sentence that packs all essential information: what it does, how to supply the input, and an example. It is front-loaded with the primary action and resource, with no fluff or redundancy. Every clause contributes to usability.

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 no output schema, the description is complete. It explains the purpose, the source of the slug, and provides examples. The safety profile is fully covered by annotations. There is no missing information an agent would need to invoke the tool correctly. The return value is implied by 'read in full' and does not require explicit specification given the absence of an output 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 already provides a description for the 'page' parameter, and the schema description coverage is 100%. The tool description goes beyond by giving concrete examples ('/documentation/mcp/' or 'mcp') and specifying the source of the slug (from search_asyntai_docs), which adds useful context and disambiguates the expected format. This is valuable beyond the schema alone.

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

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

The description clearly states the verb 'Read' and the resource 'one page of Asyntai's documentation in full'. It is specific about what is read and references the sibling tool search_asyntai_docs as the source of slugs, effectively distinguishing it from other get_* tools. The example further clarifies the expected input format.

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 usage context by specifying that the page is identified via a url or slug from search_asyntai_docs, implying a typical workflow of search-then-read. It does not explicitly exclude other usage or mention alternatives, but the reference to the search tool gives a strong hint of when this tool is appropriate. It lacks an explicit 'when not to use' statement, but the purpose is unambiguous.

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 the description's job is lighter. It adds value by specifying the result is the full message history in order, which is behavioral context not covered by annotations. 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?

A single, front-loaded sentence with zero filler. The main action is stated first and the key input (session id) is mentioned, making it efficient 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?

For a simple read-only tool with comprehensive annotations and a well-documented schema, the description covers the essential behavior: what it reads, from where, and the ordering. It does not explicitly describe the output structure, but no output schema exists and the meaning is implied. Slightly less complete than the ideal because it doesn't mention pagination or limit behavior, but limit is 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?

Schema coverage is 100% and both parameters have descriptive text. The description adds minimal extra meaning beyond the schema—it reinforces that session_id identifies the conversation but the schema already says 'Session id from list_conversations.' The limit parameter is fully described in the schema, so the description contributes little.

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 (read), resource (one conversation), and scope (full message history, in order). It distinguishes from siblings like list_conversations (which lists conversations) and send_agent_reply (which writes), making 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 implies usage: to read a conversation's full history given its session id. It hints that session_id comes from elsewhere (likely list_conversations) but does not explicitly name alternatives or state when not to use this tool. The context is present but exclusions are not stated.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds valuable detail about the output (status and last-sent time) and confirms the scope (one website), going beyond the annotation-provided safety traits. It does not cover error conditions, but that is not critical for a simple getter.

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 directly conveys the core functionality. It avoids redundancy and uses plain language, making it easy to parse and act upon.

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

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

Despite having no output schema, the description sufficiently communicates the return value (enabled status and last-send timestamp). It also clarifies the scope (one website) and the optional parameter behavior, making the tool complete for its intended purpose.

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 fully describes the only parameter (website_id) with a clear description and optionality. The description adds no further parameter semantics beyond restating the website scope, which is already in the schema. Since schema coverage is 100%, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: to report whether the daily email summary is enabled and the timestamp of the last send, scoped to a specific website. This distinguishes it from sibling tools like set_daily_report.

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 reading the daily report setting, but it does not explicitly mention alternatives like set_daily_report or when to prefer this tool over get_analytics. The phrasing is clear enough for an agent to infer the correct use case, but explicit guidance is absent.

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

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

The annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds a potentially confusing note about website crawls being 'listed but not exported,' which may relate to behavior but is not clear. 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 first sentence is concise and front-loaded, but the following two sentences are confusing and not well-structured. The phrase 'A website crawl is listed but not exported' is ambiguous and could be omitted or clarified, detracting from the overall 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 read operation with one parameter, the description adequately covers the purpose and mentions supported content types. However, the unclear statement about website crawls leaves some ambiguity about what is retrievable, making it less complete than it could be.

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

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

The schema already provides a meaningful description for the single parameter, entry_id, referencing list_knowledge. The tool description does not add further detail about the parameter, so with high schema coverage the baseline 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 reads the stored text of one knowledge base entry. This distinguishes it from listing or searching the knowledge base, and the verb 'read' is specific.

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 use when retrieving a single entry, and the parameter description says the entry_id comes from list_knowledge, providing some guidance. However, it does not explicitly name alternative tools or say when not to use it, though the context is fairly 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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns the embed code and field list, which is useful but not rich behavioral context (e.g., no mention of defaults, pagination, or response shape). With the safety profile fully covered by annotations, a 3 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?

One concise sentence front-loads the verb and resource, then lists the returned fields in a compact enumeration. No filler words, and the list adds substantive detail without bloating the description. Every token earns its place.

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

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

With no output schema, the description carries the burden of documenting the return shape; it does so by enumerating key fields (name, domain, platform, widget id, embed code). For a simple get-by-id tool with a single optional parameter and annotations covering safety, this is sufficient. Minor gap: it assumes the agent knows what the 'embed code' is and doesn't hint at other possible fields, but the main expected values are 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 input schema has 100% coverage: the single parameter `website_id` already describes its source ('from list_websites') and default behavior ('Omit to use the account's primary website'). The tool description adds no extra parameter semantics beyond the schema, so the baseline of 3 holds.

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 ('Get') with a resource ('the full record for one website') and enumerates the returned fields (name, domain, platform, widget id, embed code), which clearly distinguishes it from sibling tools like list_websites (list) and get_website_features (subset of features). An agent can confidently select this tool for fetching a complete single-website record.

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: 'Get the full record for one website' contextualizes when to use it (need full website details). However, it does not explicitly state when not to use it or point to alternatives like list_websites for summaries or get_website_features for feature-specific data, leaving the agent to infer the differentiation.

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 safety profile is covered. The description adds value beyond that by specifying the exact output shape — 'Shows current values, which features the plan allows, and the plan each locked feature needs' — and by noting the optional parameter behavior ('Omit to use the account's primary website'), which is a useful behavioral nuance not present in 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 front-loaded with the core purpose in the first clause, and the subsequent feature enumeration is information-dense with no filler or redundancy. The list of twelve features is long, but each item is meaningful for disambiguating scope from sibling tools. The closing sentence about output contents is compact and adds necessary detail without padding.

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?

There is no output schema, so the description correctly assumes the burden of explaining what the read returns — current values, plan allowances, and the plan required for each locked feature, which is sufficient for a read-only tool. The single optional parameter is fully documented in the schema, and the tool's simplicity (one optional param, no side effects) means nothing critical is missing. A small gap is the absence of an explicit note about error behavior when given an invalid website_id, but this is minor for a read-only lookup.

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 sole parameter website_id has a thorough schema description — numeric type, provenance ('from list_websites'), and default behavior ('Omit to use the account's primary website') — giving 100% schema coverage. The tool description itself adds nothing beyond the schema, but the schema is already self-sufficient, so the baseline for a fully covered parameter is met.

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

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

The description opens with a precise verb-resource pair — 'Read the plan-gated features for one website' — and then enumerates the full feature set (Real-Time Data Feed, Product Cards, etc.), which leaves no ambiguity about what this tool retrieves. The contrast with siblings like get_website, get_widget_settings, and update_website_features is implicit but clear, since the feature list uniquely scopes this tool to plan-gated feature readout.

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 choose this tool over alternatives such as get_website or get_widget_settings. The feature enumeration implies a distinct scope, and the parameter hint 'from list_websites' points to a workflow step, but there is no explicit guidance like 'use this to inspect plan-gated entitlements; use get_website for general site info.' The guidance is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. Description aligns with that but adds no extra behavioral context (e.g., no mention of caching or side effects). Baseline score because annotations cover this.

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 concise sentence, no fluff, effectively communicates the full scope of the tool and its limitations (plan-related restrictions).

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

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

No output schema exists, but the description provides enough context about what is returned (settings plus plan restrictions). It is complete for a read-only operation with one optional parameter.

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% for the single parameter (website_id). The description adds no additional meaning beyond the schema's existing explanation, so baseline 3 applies.

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

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

Clearly states it reads widget settings for a website, listing specific categories (colours, greeting, position, etc.) and the additional plan/restriction info. Distinguishes from sibling 'update_widget_settings' by using 'Read'.

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?

Describes exactly what the tool does (read all settings) and implicitly contrasts with the update sibling. Does not explicitly state 'use this when you need to fetch settings' but it is obvious from the verb and scope.

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 a read-only, idempotent, non-destructive operation. The description adds the plan requirement and clarifies the data scope, with no contradictory behavior. It does not mention pagination or rate limits, but the annotation coverage lowers the burden.

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 lists what is returned, followed by the plan requirement. Every part is useful and there is no redundant or ambiguous 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?

The description names the key return fields and the plan constraint, which is sufficient for a simple listing tool without an output schema. It does not specify ordering or response shape, but those are not essential for core usage.

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 descriptions already cover 100% of parameters, including limit bounds and website_id semantics. The description does not add further parameter-level detail beyond the schema, so the baseline score 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 verb 'List' and the resource 'visitors currently in a chat', with specific fields returned (page, country, duration, human takeover). This distinguishes it from sibling tools like list_conversations by focusing on live visitor sessions rather than conversation records.

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 'currently in a chat' implies real-time monitoring use, and 'Needs the Standard plan or higher' gives a prerequisite. However, it does not explicitly compare with alternatives such as list_conversations or say when not to use this tool, so guidance is largely implied.

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

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

The description reinforces the read-only nature with the verb 'Read' and does not contradict the readOnlyHint annotation. However, it adds no additional behavioral context beyond what annotations already provide, such as side effects, rate limits, or authentication details. The mention of the plan is more of a licensing condition than behavior.

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

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

The description is a single, focused sentence with no superfluous words. It is well-structured, immediately conveys the core function, and includes the key detail about the data recorded (who, when, where) in a compact manner.

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 explains what the audit log contains but does not mention the format of the returned data (e.g., an array of entries, fields returned). While the lack of an output schema reduces the expectation, the description would be more complete if it indicated that the tool returns a list of log entries. Given the simple parameters, this is a minor gap.

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

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

The schema provides complete descriptions for all three parameters (days, limit, category), covering 100% of parameter semantics. The description text itself adds nothing beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool reads the audit log, specifying the content (who, when, from where) and the plan requirement. It is unambiguous and distinguishes this tool from others like list_webhooks or list_conversations.

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 explicit guidance on when to use this tool versus alternatives. It only notes the Enterprise plan restriction, which is a prerequisite, not a usage scenario. No mention of typical use cases or comparison to other read-only 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 read-only and non-destructive behavior. The description adds the plan requirement but does not elaborate on side effects or response behavior, so it provides moderate additional 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?

The description is two short sentences, efficient and directly to the point. No redundant information or unnecessary phrasing.

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

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

The description covers what the tool returns (length, price, spots) and a key prerequisite (plan). It lacks information about pagination or filtering, but this is not critical for an MVP listing tool, making it adequately 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 single parameter website_id is fully documented in the schema with clear semantics (numeric id, optional, defaults to primary). The tool description does not add extra parameter detail, so the score matches the baseline for complete 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 lists appointment types with length, price, and spot counts. It is distinct from sibling tools like list_products or list_images, making its 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?

It mentions the prerequisite that bookings require the Standard plan or higher, providing useful context. However, it does not explicitly state when to use this tool over alternatives, though no direct alternative exists among siblings.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior, so the description does not need to restate safety. It adds the 'newest first' ordering as behavioral detail, but does not discuss side effects (which is appropriate given annotations). Overall, it provides marginal added 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 focused sentence with no redundant words. It efficiently conveys the action, scope, ordering, and key output fields, making every word necessary.

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 includes the essential output fields and ordering, and the schema covers parameter defaults. It lacks explicit mention of edge cases or error behavior, but for a straightforward read-only list operation, it is sufficient. Minor gaps like pagination or response format are not critical given no output schema is defined.

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 descriptions for parameters are already comprehensive (100% coverage), so the description need not explain them. It only loosely ties 'for one website' to website_id and does not add new semantics to days, limit, or with_leads_only. This meets the baseline for high schema coverage.

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

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

The description clearly states the action ('List recent visitor conversations'), the scope ('for one website'), ordering ('newest first'), and expected output fields. It is specific and unambiguous, leaving no doubt about the tool's purpose.

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 mention when to use this tool versus alternatives such as get_conversation or list_leads. While the scope and ordering are implied, there is no explicit guidance on selection criteria or comparisons with 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 read-only and idempotent behavior. The description adds value by specifying the returned fields (status, page count, stop reason) without contradicting the annotations. No side effects are implied.

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 conveys the essential information without any unnecessary words.

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

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

The description provides enough context for a list operation, indicating what will be returned (status, page count, stop reason). While no output schema exists, the description covers the key aspects an agent needs to understand the tool's behavior.

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

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

Schema coverage is 100% with descriptive parameter explanations for limit and website_id. The tool description itself does not add extra meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states that the tool lists recent crawl jobs for a website, including status, page count, and stop reason. This is specific and distinct from sibling tools like start_crawl or get_website.

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 is for retrieving crawl job history, but does not explicitly mention alternatives or when not to use it. However, the purpose is evident enough for an agent to select it appropriately among siblings.

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

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

The annotations already indicate readOnly, idempotent, and non-destructive. The description adds the plan requirement but no further behavioral details, which is acceptable given the strong annotation coverage.

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

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

The description is two sentences, direct, and free of fluff. It front-loads the core purpose and includes only essential additional context (plan requirement).

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 tool with one optional parameter and no output schema, the description covers the purpose, scope, examples, and a key prerequisite. No critical information is missing.

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

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

There is only one parameter (website_id) and its schema description fully explains its meaning and default behavior. The description adds no extra parameter context, but the schema already provides sufficient 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 lists third-party tools embedded in the chat, with concrete examples (booking calendar, form). This distinguishes it from other list tools like list_images or list_webhooks.

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

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

It provides a clear prerequisite (Standard plan or higher) and references the website_id source from list_websites. However, it does not explicitly contrast with alternative list tools, though the name and scope make the intended use 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=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by stating the output includes descriptions for relevance, which is useful context. However, it doesn't mention pagination, ordering, or response structure. The added context is modest.

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 action and resource, then adds the key qualifier about relevance descriptions. There is zero waste; every word contributes.

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

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

For a simple read-only list with one optional parameter and no output schema, the description conveys the core purpose and what is returned (images with relevance descriptions). It doesn't specify pagination or limits, but that is not critical for a basic list operation. The tool is simple enough that this 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?

Schema description coverage is 100% – the only parameter (website_id) is fully described in the schema, including its source and default behavior. The tool description adds nothing about parameters, so the baseline of 3 applies since the schema does the heavy lifting.

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

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

The description clearly states the action (list) and resource (images) with a specific scope ('the chatbot may show a visitor'). It also mentions the output includes relevance descriptions. It distinguishes from siblings like add_image/delete_image by the verb, though it doesn't explicitly name them. The purpose is 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 gives clear context for when to use the tool: to retrieve images the chatbot can show. It implies usage for reviewing available images but does not explicitly state when not to use it or mention alternatives. This is adequate for a simple read-only list.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the main safety profile. The description adds useful context about what kinds of sources are included, but it does not mention pagination, ordering, filtering, or potential errors. Given the annotations, this is adequate without being highly detailed.

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 communicates the core purpose and the four source categories without any redundant words or tangential details. It is easy to read and appropriately front-loaded.

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

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

The tool is simple and the description is enough to understand the basic action, but with no output schema present the description does not clarify the response shape, field names, or whether sorting/filtering is supported. It also does not mention the optional nature of website_id beyond what the schema already says, leaving some operational context implicit.

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

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

The schema already provides clear descriptions for both parameters: 'limit' states the range and default, and 'website_id' explains its origin and fallback. The description itself adds little beyond reinforcing that sources belong to 'one website', so it stays at the baseline for already well-documented parameters.

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

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

The description uses a specific verb ('List'), identifies the resource ('sources in one website's knowledge base'), and enumerates the source types ('uploaded text, documents, added pages and crawls'). This clearly distinguishes it from related tools like get_knowledge_entry or search_knowledge_base.

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

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

The description conveys the general use case—listing all knowledge-base sources for a website—but it does not explicitly explain when to prefer this tool over sibling tools such as get_knowledge_entry, search_knowledge_base, or add_knowledge_text. The guidance is acceptable but could be more 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 appropriately indicates a read-only listing operation via 'List' and 'recorded', consistent with the readOnlyHint, idempotentHint, and destructiveHint annotations. It also adds the plan requirement, which is 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?

The description is compact, using two sentences to convey purpose, relation to another tool, and plan constraints. No unnecessary words or redundant schema restatement.

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 complete for the tool's primary purpose and integrates well with sibling tools, though it does not describe the output shape. Since no output schema is provided, a brief note on returned fields could enhance completeness, but it is not strictly 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 schema covers all parameters with descriptions, and the prose adds meaningful defaults for days and limit, clarifies include_resolved is off by default, and points users to list_websites for website_id. This exceeds mere schema repetition.

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 knowledge gaps recorded by Asyntai, defined as real visitor questions the chatbot could not answer. This distinguishes it from related tools like list_knowledge and search_knowledge_base, and explicitly connects it to add_knowledge_text for follow-up.

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 practical guidance by identifying that the tool is for finding gaps to fill with add_knowledge_text and notes the Standard plan requirement. It does not explicitly enumerate when not to use it, but the purpose is clear enough for an agent to select appropriately.

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 read-only, idempotent, and non-destructive behavior, which the description aligns with. The additional mention of 'newest first' provides ordering context beyond the annotations, though it does not describe pagination or error handling.

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

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

The description is a single, concise sentence with no redundant words. It efficiently conveys the action, resource, and output expectations.

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 lack of an output schema, the description adequately specifies what is returned (email addresses, phone numbers, and page context) and ordering. It omits details like pagination or total count, but the core functionality is sufficiently 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?

Both limit and website_id are fully described in the schema, including defaults and source. The tool description adds no extra parameter information, so with 100% schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'List' and the resource 'leads' (email addresses and phone numbers left in chat), including specific details about ordering and content. It is unambiguous and easily distinguishes this tool as a read-only listing operation.

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

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

The description implies use for retrieving captured leads without any explicit alternative or condition. While it doesn't state when not to use it, the context is clear and no sibling tool overlaps directly with this functionality.

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 read-only, idempotent, and non-destructive behavior. The description adds context about including the current plan but does not contradict annotations. No additional side effects are mentioned, which is acceptable given 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 two sentences that are concise and direct, with no fluff or redundant information. It is well-structured and front-loaded with the primary action.

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

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

Despite lacking an output schema, the description explains what the return includes (plans, pricing, allowance, features, current plan) and the reason to use it. This is sufficient for an agent to know what to expect and when to use it.

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

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

There are no parameters defined, so schema coverage is 100%. The description doesn't need to explain parameters, but it does mention what the output contains, which meets the baseline for parameter semantics.

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

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

The description clearly states it lists all plans with specific attributes (price, monthly allowance, features) and includes the current account's plan. The verb 'List' and resource 'plans' are specific, and it distinguishes itself from other tools by focusing on plan comparison.

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

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

It explicitly states the use case: answering which plan to move to and why. This provides clear guidance on when to invoke this tool, making it obvious for an agent to select it.

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 readOnly/idempotent/non-destructive; description adds relevant plan prerequisite and output contents. 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?

Two focused sentences with no redundancy; essential purpose and prerequisite are front-loaded.

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

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

Covers purpose, plan requirement, and output contents (price/links) for a simple list; no output schema, but sufficient for basic invocation.

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

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

Single website_id parameter is fully described in the schema with source and default behavior; description adds no extra parameter detail.

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

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

States specific verb 'List' and resource 'products the chatbot can show as cards', with price and links. Clearly distinguishes from add/delete product siblings.

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

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

Gives clear retrieval purpose and plan requirement, but does not explicitly contrast with alternative product operations or state when to select this over siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by specifying the output content: members, their reach, and seat counts. It does not repeat the annotations and adds value 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, compact sentence that front-loads the main verb and resource, then adds the key details. There is zero waste; every element contributes to understanding what the tool does.

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

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

With no output schema, the description is the sole source of return-value information. It adequately conveys that the result includes members, their access scope, and seat limits. It does not mention pagination or ordering, but for a simple listing tool with no parameters, this is sufficient.

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

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

There are zero parameters, and the schema is an empty object with 100% coverage. The baseline for 0 params is 4, and the description does not need to explain parameters. It correctly does not attempt to describe nonexistent inputs.

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

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

The description states a clear verb ('List') and a specific resource ('the people who share this account'), and adds distinguishing details: what each member may reach and the seat allowance. This makes it clearly distinct from siblings like get_account or list_plans, even without naming them explicitly.

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

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

No explicit guidance is given about when to use this tool versus alternatives like get_account or list_plans. However, the description's content makes the intended use case obvious (reviewing team members and access), so the context is clear but not explicitly stated.

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

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

The description adds the plan requirement (Standard or higher), which is extra transparency beyond the annotations that already mark it as read-only, idempotent, and non-destructive. No side effects are mentioned, but no negative side effects are expected for a read-only list.

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 conveys the core functionality and a key constraint without any fluff or unnecessary 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?

The description mentions the return fields (status, priority, visitor details) and the plan requirement, which is sufficient for a simple list tool. It does not specify pagination behavior beyond the limit parameter, but the schema covers that, so the description is reasonably 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 descriptions cover all parameters (limit, status, website_id) thoroughly, and the tool description adds no additional meaning to the parameters. Since schema coverage is high, 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 lists support tickets raised from chat, including status, priority, and visitor details, which distinguishes it from other sibling tools like list_conversations. It also specifies the plan requirement, making the purpose unambiguous.

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

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

The description implies usage when support tickets are needed (e.g., 'raised from chat') and mentions the plan requirement, but it does not explicitly contrast with alternatives like list_conversations or get_conversation. Usage guidance is implied rather than explicit.

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

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

Explicitly discloses that the signing secret is never returned and is only shown at creation, which is important security behavior not captured in 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 concise sentences, each carrying essential information without redundancy or unnecessary words.

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

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

Complete for a parameterless tool with no output schema; the caveat about the signing secret is the only relevant contextual detail an agent needs.

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?

No parameters exist, so the description adds no parameter-specific info; schema coverage is trivially 100%, making this a neutral baseline.

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

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

States a specific verb ('List') and resource ('webhooks') with scope ('on this account'), clearly distinguishing it from sibling webhook tools like 'add_webhook' and 'delete_webhook'.

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 listing webhooks, and the sibling names make the distinction obvious, though it doesn't explicitly say 'use this when you need to see existing webhooks'.

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, covering the safety profile. The description adds the useful behavioral note that this tool provides the id used by other tools, which is beyond the annotations. It does not mention pagination or return format, but given the annotations cover the safety aspects, the description adds some value, so a 3 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 two concise sentences with no wasted words. The primary action ('List the websites') is front-loaded, and the key usage advice ('Start here...') is included without clutter. Every word earns its place.

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

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

For a simple list tool with no parameters, annotations covering safety, and no output schema, the description is complete enough for an agent to call it correctly. It explains what the tool does, what it returns (the id), and when to use it. The only missing detail might be pagination or response structure, but since there is no output schema to rely on, the description provides adequate context for this low-complexity 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?

The tool has zero parameters and schema description coverage is 100% (trivially). The description does not need to explain parameter semantics since there are none. According to the rubric, a baseline of 4 is given for 0-parameter tools, and the description adds no unnecessary parameter info, so this score fits.

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 'list' and the resource 'websites (AI agents)' on the Asyntai account. It also adds the distinguishing detail that this tool returns the 'id every other tool takes', which separates it from siblings like get_website or create_website, making its 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 provides explicit guidance on when to start here: 'Start here when the account may have more than one.' This clearly indicates the condition for using this tool. However, it does not explicitly mention when not to use it or name an alternative, though the context implies that if you already know the id you might go directly to get_website. This is a clear usage context without full exclusion logic.

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 and idempotent behavior. The description adds context about what the output contains (languages, greeting, agent name), going beyond the basic 'list' verb without contradicting 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, well-structured sentence that front-loads the action ('List') and provides necessary details about the output without extraneous 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?

The operation is simple, with read-only annotations covering safety. The description sufficiently communicates the purpose and expected content, making it complete enough for an agent to call correctly despite the lack of an output 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 single parameter website_id is fully described in the schema with clear instructions on its source and optionality. The tool description does not add further parameter-related 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 the tool lists the languages for which the chat widget has translations, including the greeting and agent name. This distinguishes it from sibling tools like set_widget_translation (which modifies) and other list 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 a read-only retrieval operation but does not explicitly state when to use this versus alternatives (e.g., before setting a translation with set_widget_translation). The guidance is implicit 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 declare destructiveHint=true and readOnlyHint=false, so the description doesn't need to re-state that. It adds context about the timing (AI answers from the next message) which is useful. However, it doesn't elaborate on what happens to the takeover state or any potential side effects 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?

A single sentence that is front-loaded with the core action and effect, with no redundant words. Perfectly 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 tool with one param and no output schema, the description covers the purpose and effect adequately. It implies the prerequisite of a taken-over conversation but doesn't state it explicitly, nor does it mention error cases. Overall, it's nearly 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 describes the single parameter session_id with 'Session id of the conversation.' Since schema coverage is 100%, the description doesn't need to add more. It doesn't, so a baseline of 3 is appropriate.

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

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

The description clearly states the action (release/hand back) and the resource (conversation), and explains the effect: the AI resumes answering from the next message. It differentiates from the sibling take_over_conversation by describing the inverse 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 the tool is used when a conversation has been taken over, which is clear from the wording 'taken-over conversation'. It doesn't explicitly mention alternatives or when not to use it, but the context of siblings and the phrase 'hand back' make the usage scenario obvious. It could be more explicit about prerequisites (e.g., only for taken-over conversations).

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. The description adds context that results include excerpts and that matching is by keyword, plus a note about re-searching with feature names. This goes beyond the annotations, though it doesn't describe any side effects (none expected).

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 paragraph with five sentences, each serving a purpose: purpose, usage context, differentiation from sibling tool, and a behavioral tip. It's slightly longer than minimal but well-structured and free of 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 there is no output schema, the description adequately explains the return format (pages with excerpts). It provides examples of feature names to use as keywords and clarifies the scope (Asyntai's own docs vs customer content). Missing details like error behavior are not critical for this simple search 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% for both parameters (query and limit), each with clear descriptions. The description doesn't add parameter-specific details beyond the schema, but it does mention keyword matching which relates to the query parameter. Baseline of 3 is appropriate given full schema coverage.

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

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

The description explicitly states the tool searches Asyntai's own product documentation and returns matching pages with excerpts. It clearly distinguishes from customer content, and the verb 'search' plus resource 'Asyntai documentation' is specific. It also differentiates from sibling search_knowledge_base, so no ambiguity.

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

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

Provides direct guidance on when to use ('to find out how a feature works before changing anything, rather than guessing'), when not to use (customer content, pointing to search_knowledge_base), and a tip on keyword matching with examples of feature names. This is explicit and actionable.

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, covering the safety profile. The description adds valuable context beyond these: it returns passages with relevance scores, and notably does not consume the message allowance—a behavioral trait not captured by annotations. This additional context helps the agent understand side effects and costs. It could mention pagination or error behavior, but the annotations lower the bar, so a 4 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 two sentences with zero filler. It leads with the core action and output, then states the use case and key exclusions. Every sentence earns its place, and the most decision-relevant information (what it returns and what it doesn't do) is front-loaded.

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

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

For a read-only search tool with no output schema, the description sufficiently explains the return value (passages with relevance scores) and explicitly notes that it does not use the message allowance—a cost-related detail agents need. The safety profile is already covered by annotations, and parameter details are fully in the schema. Nothing essential for invoking the tool correctly is missing.

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

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

The input schema provides 100% description coverage for all three parameters (query, limit, website_id), including defaults and semantics. The description adds no parameter-specific information beyond what the schema already provides, so the baseline of 3 applies. The description's mention of 'for this question' loosely aligns with the query parameter but adds no new syntax or format 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 action: 'Search one website's knowledge base' and specifies the output: 'return the passages the chatbot would retrieve for this question, with a relevance score.' It also differentiates from siblings like ask_ai by noting it does not generate an answer, and from search_asyntai_docs by targeting the knowledge base specifically. The verb-resource pair is distinct 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 a clear intended use case: 'Use this to check what the chatbot knows about a topic.' It also explicitly states what it does not do ('does not generate an answer'), which guides the agent away from using it for answer generation. However, it does not name alternative tools (e.g., search_asyntai_docs) or specify when to prefer them, leaving some inference to the agent.

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 goes beyond the annotations by warning that the visitor sees the message immediately and that user confirmation is required. This is crucial behavioral information not captured in the readOnlyHint/destructiveHint flags.

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

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

The description is concise, consisting of two sentences that front-load the core action and then provide essential precautionary context. No unnecessary words or redundancy.

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

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

The description covers the essential context: the action, the prerequisite, and the importance of user confirmation. Since there is no output schema, no return value explanation is needed, and the description is fully complete for an agent to use 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 schema already provides complete descriptions for all three parameters (message, agent_name, session_id). The tool description adds no further parameter-specific detail, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: sending a message as a human agent to a live visitor. It also distinguishes itself from related actions by specifying the prerequisite of taking over the conversation first.

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 explicit sequencing guidance ('Take the conversation over first') and a critical caution ('show the user the exact wording and get their agreement'). It does not explicitly contrast with alternative tools but gives sufficient context for when to use this tool.

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 idempotent and destructive behavior. The description adds a meaningful side effect: 'creates the signing secret your server needs to sign visitor entitlements.' This goes beyond the annotations and clarifies why turning it on matters. 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?

The description is two compact sentences: first states the action, second explains the side effect and requirement. No redundant words, well-structured, and front-loaded with the primary 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?

With no output schema, there is no need to describe return values. The description covers the action, the side effect, and the plan requirement. It could mention what happens if the plan is insufficient, but that is not essential for the agent to decide to invoke it.

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 clearly ('True to switch it on' and 'Numeric id of the website...'). Since coverage is 100%, the baseline is 3. The description does not add extra meaning beyond the schema, so it stays at baseline.

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

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

The description begins with a clear verb ('Switch'), names the resource ('Access Tags'), and scopes it to one website. This distinguishes it from sibling tools like set_knowledge_tags or set_data_feed without needing to inspect schemas.

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

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

It states a key prerequisite ('Needs the Enterprise plan'), which helps the agent decide if the tool is available. It does not explicitly compare to alternatives, but the purpose is self-evident. Could be more explicit about when not to use it, but adequate.

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 useful behavioral context beyond the annotations by indicating the plan requirement and that the operation is scoped to a single website. It does not contradict the destructiveHint or idempotentHint 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 with no fluff or repetition. It front-loads the core action and follows with the prerequisite.

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 setter with two well-described parameters and no output schema, the description is sufficient. It covers the action, scope, and a key prerequisite. Minor details like return behavior are not necessary here.

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 has a clear description. The tool description does not add extra meaning beyond the schema, so the baseline score 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 action ('Turn ... on or off'), the target resource ('daily email summary of chats'), and the scope ('for one website'). It is immediately distinguishable from sibling tools like get_daily_report.

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 (to enable or disable the daily report) and gives a prerequisite ('Needs the Standard plan or higher'), but it does not explicitly contrast with alternatives such as get_daily_report or explain when not to use it.

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 transparently states side effects: it fetches the feed, validates it, clears previous index, and rebuilds in the background. This aligns with the destructiveHint annotation and adds detail about the background operation, exceeding what annotations alone provide.

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 few concise sentences with no filler, front-loading the primary action and then covering the removal case and prerequisite. It is easy to read and directly informative.

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 and absence of an output schema, the description covers the process, side effects, special case, and prerequisite effectively. It provides sufficient context for an agent to decide when and how to call it.

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 full descriptions for all three parameters (url, enabled, website_id), achieving 100% coverage. The description adds only slight emphasis on the URL behavior (empty removes), but it does not meaningfully enhance understanding beyond the schema, so baseline 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 action: pointing the chatbot at a product feed and indexing it, plus the special case of removing the feed with an empty URL. This distinguishes it from related tools like set_data_feed_max and is specific enough to understand the core function.

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 explains when to use the tool (to set or remove a product feed) and includes a conditional (empty URL for removal). However, it does not explicitly compare against alternatives like other feed-related tools, though the purpose is clear enough to avoid confusion.

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 destructive behavior ('clears the old index') and asynchronous execution ('rebuilds it in the background'), aligning with the destructiveHint annotation. It also mentions the Pro plan requirement. It does not explicitly mention idempotency, but that is 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 is concise, with two sentences that cover the action, differences from set_data_feed, and prerequisites. It is well-structured and front-loaded with the main purpose. Slight dependency on knowing set_data_feed, but not overly verbose.

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

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

Given the tool's complexity (3 parameters, no output schema), the description adequately covers the operational context: what it does, when to use it, and prerequisites. It does not mention error handling or return values, but those are not necessary given the context. The description is complete enough for an agent to decide and 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 schema provides descriptions for all three parameters, so baseline is 3. The tool description does not add extra meaning to the parameters; it references set_data_feed but does not elaborate on how url, enabled, or website_id affect the operation. Thus, no additional value 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 tool's function: it is like set_data_feed but for the Max tier, and it explicitly describes the actions (fetch, validate, clear old index, rebuild). This distinguishes it from sibling tools and provides a concrete purpose.

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 indicates when to use this tool (for the Max tier / larger catalogue) and mentions the prerequisite 'Needs the Pro plan or higher.' It does not explicitly contrast with all alternatives, but it does differentiate from set_data_feed, which is sufficient for typical 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?

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds valuable behavioral context: visitors must present a matching tag signed by your server, and the Enterprise plan requirement. It also implies that setting tags overwrites existing ones (since an empty list makes it public). This goes beyond annotations without contradicting them, so a 4 is warranted.

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

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

The description is three concise sentences with the purpose front-loaded. There is no fluff or redundancy. It loses a point because it could mention that it overwrites existing tags explicitly, but overall it is efficient 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 set operation with two well-documented parameters, the description is fairly complete. It covers the plan requirement, the public-reset behavior, and the signed-tag mechanism. However, it does not differentiate from the closely named sibling 'set_access_tags' and does not mention what happens if the entry does not exist. These are minor gaps given the tool's simplicity.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description reinforces that an empty list makes the entry public, but this is already in the schema. It adds the concept of signed tags, which is behavioral rather than parameter-specific. Given high schema coverage, the baseline of 3 applies; the description adds minimal extra parameter 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 verb 'Restrict' and the resource 'one knowledge base entry', making the primary purpose unambiguous. It also explains the mechanism of signed tags, adding specificity. However, it does not explicitly differentiate from the sibling tool 'set_access_tags', which may be similar in nature, so it loses a point for lack of sibling distinction.

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

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

The description provides usage context by explaining how to restrict access and how to make an entry public again (empty list). It also mentions the Enterprise plan requirement, which is a prerequisite. However, it does not state when to use this tool versus alternatives like 'set_access_tags' or when not to use it, so guidance is incomplete.

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 meaningful behavioral context beyond the annotations, notably that enabling pinning changes the embed code and creates a snapshot. It also implies the effect of the enabled parameter, though it does not explicitly describe the behavior of disabling pinning. The destructiveHint and idempotentHint annotations are consistent with the description.

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

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

The description is concise, consisting of two sentences with no unnecessary fluff. It front-loads the core action (freezing the widget) and provides relevant details (snapshot, embed code change, plan requirement) 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 tool with two parameters and no output schema, the description covers the essential context: the action, the side effect on embed code, and the Enterprise plan requirement. It does not explicitly address the behavior of disabling pinning, but it is reasonably inferable from the title and the enabled parameter 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?

Schema description coverage is 100% for both parameters, so the baseline is 3. The description enhances understanding of the enabled parameter by explaining that turning it on builds a snapshot and changes the embed code, adding value beyond the schema's simple 'True to pin the widget.'

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: freezing the chat widget at its current version and building a snapshot, which is equivalent to enabling or disabling pinning. It distinguishes this from general widget settings updates by focusing on the pinning behavior.

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 mentions the Enterprise plan requirement, which is a precondition, but it does not explicitly state when to use this tool versus alternatives like update_widget_settings. No guidance on comparison with sibling tools is provided.

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 annotation already provides readOnlyHint=false, idempotentHint=true, and destructiveHint=true. The description adds a useful user-facing effect, but it does not clarify what happens when optional fields are omitted, whether this overwrites an existing translation, or whether the change can be reverted. This is acceptable but not rich behavioral disclosure 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 two purposeful sentences: the first states the operation and the fields affected, the second clarifies the user-facing consequence. 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?

For a simple five-parameter mutation with full schema coverage and annotations, the description supplies enough context about where the wording appears and how language selection behaves. A note about omitted-field behavior would improve completeness, but the description is arguably 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 input schema already covers all five parameters with clear descriptions, and the description mostly rephrases the same concepts ("greeting, agent name, bubble text"). There is no additional parameter-level guidance beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states the verb and resource clearly: "set the chat widget's greeting, agent name and bubble text for one language." It distinguishes itself by language scoping and mentions the default-fallback behavior, though it does not explicitly differentiate from close siblings like update_widget_settings.

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?

"A visitor in that language sees this wording instead of the default" implies a localized-use case, but the description does not give explicit when-to-use/when-not-to-use guidance or name an alternative sibling. The context is clear but the routing to alternatives is left to inference.

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

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

Beyond the annotations (non-read-only, non-idempotent), it discloses background execution and the refusal behavior when the page cap is exceeded. This adds useful operational context without overpromising.

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

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

Three concise sentences, no redundancy or filler. All information is directly relevant to using the tool correctly.

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 three optional parameters and no output schema, the description covers the essential behavior, monitoring approach, and constraint (cap). It does not mention return values, but that is acceptable given no 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 descriptions already cover each parameter (max_pages, start_url, website_id). The tool description reinforces the cap behavior but does not add substantially new 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?

Clear verb ('Crawl') and resource ('a website'), explicitly states it adds pages to the knowledge base. This distinguishes it from sibling tools like add_knowledge_url or list_crawls.

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 practical guidance: runs in the background and should be monitored via list_crawls, and mentions the plan cap on pages. Could be more explicit about when to prefer this over other knowledge-adding methods, but the context is adequate.

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 (mutating, idempotent, destructive), the description discloses concrete effects: stops the AI, notifies the visitor, and implies a workflow. It also mentions a prerequisite (Standard plan). This adds meaningful behavioral context not encoded in 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?

Three concise sentences that cover purpose, side effect, workflow, and requirement. No unnecessary words or repetitions. Well-structured and 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?

For a simple tool with one parameter, the description covers the key aspects: what it does, the side effect, the follow-up actions, and the plan requirement. It doesn't elaborate on error cases or return values (no output schema), but that's acceptable given the simplicity.

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

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

The single parameter session_id is already described in the schema as 'Session id from list_active_sessions.' The description does not add further parameter details, but the schema coverage is complete, 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?

Clearly states the action: 'Stop the AI answering one conversation so a human can reply instead.' It also mentions the side effect of notifying the visitor, making the purpose unambiguous and distinct from siblings like send_agent_reply or release_conversation.

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 usage context by indicating when to use it (when a human needs to take over) and gives subsequent steps: 'Use send_agent_reply afterwards, and release_conversation when done.' It also notes the plan requirement. However, it doesn't explicitly contrast with alternatives like 'use send_agent_reply without taking over.'

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 warns that the operation overwrites current instructions and affects every visitor's chatbot experience. This goes beyond the destructiveHint annotation by explaining the real-world impact and the need for user confirmation.

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

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

The description is three concise sentences, front-loaded with the action and key warning. It contains no fluff or redundant phrasing, making it easy for an agent to parse and act on.

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 complete enough for a simple two-parameter update tool: it states the action, the side effect, the prerequisite read, and the required user confirmation. No output schema exists, and the description does not need to elaborate further.

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

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

The schema already provides full descriptions for both parameters, including the optional website_id behavior. The description adds no additional parameter-level detail beyond what the schema covers, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Replace'), the resource ('one website's AI instructions'), and the effect ('changes how the live chatbot answers every visitor'). It is unambiguous and distinct from the related get_ai_instructions tool.

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 explicitly instructs to read the current instructions with get_ai_instructions first and to show the user what will change before calling. This provides clear prerequisite and safe-usage guidance, leaving no ambiguity about the intended workflow.

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 that changes affect the live chatbot behavior for every visitor, which is a significant side effect. It also reveals validation behavior ('A feature the plan does not include is refused') beyond what the annotations indicate, and does not contradict the destructiveHint or idempotentHint 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 compact at four sentences and front-loads the core purpose. The sentence 'A feature the plan does not include is refused with the plan it needs' is somewhat cryptic, but overall the structure is efficient 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 simple two-parameter schema and absence of an output schema, the description covers the essential context: what to update, how to pass values, the prerequisite read call, validation behavior, and the live impact. It stops short of enumerating all possible feature fields, but that is not necessary given the schema coverage.

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 both fields and website_id already described. The description adds the 'read them with get_website_features first' cue and examples, but does not materially expand beyond the schema's parameter explanations, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Turn website features on or off and set their values') and identifies the resource ('website features'), with concrete examples like Real-Time Data Feed URL and PII Redaction rules. This distinguishes it from sibling tools such as get_website_features and update_widget_settings.

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

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

It explicitly instructs the agent to call get_website_features first and to pass an object of field name to value, giving practical usage guidance. It does not explicitly compare with all alternative update tools, but the prerequisite and intended use are clear enough.

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

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

Beyond the annotations (idempotent, destructive), the description discloses important behavioral traits: changes are live for every visitor at once, settings not included in the plan are refused with the required plan, and nothing is written unless every value is valid. These are significant side-effect and failure-mode details.

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

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

The description is concise, consisting of three sentences that each add distinct information: the action, the read-before pattern, and the transactional/plan behavior. No fluff or 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?

The description covers the core action, preconditions, plan limitations, atomicity, and live propagation. It does not mention output or return values, but no output schema exists, and the description does not need to explain that. Given the tool's moderate complexity (nested object, plan checks), this is nearly 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 already covers both parameters with 100% description coverage (settings object with example, website_id with example). The description adds minimal extra value beyond the schema, such as 'object of setting name to new value' which is redundant with the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool changes one or more chat widget settings, using the specific verb 'Change' and resource 'chat widget settings'. It distinguishes itself from sibling tools like get_widget_settings (read) and set_widget_pinning (specific setting) by focusing on general 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 advises to 'read them with get_widget_settings first', providing a clear precondition. It also explains plan restrictions and atomic validation, which helps the agent decide when to use this tool. However, it does not explicitly contrast with alternatives beyond the read hint, so a small gap remains.

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