Asyntai

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the mutation profile is covered. The description adds one genuinely useful behavioral insight — that the description text is what the AI uses at runtime to decide whether to send the image — but says nothing about duplicate handling, permissions, or side effects it does not mention.

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

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

Two sentences, front-loaded with the purpose and followed by the key guidance for the critical parameter. Nothing is wasted, though the second sentence is a slightly dense run-on rather than crisply 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?

No output schema is needed here, the schema fully covers parameters, and annotations carry the safety/mutation profile, so the description only needs to convey purpose and the semantics of the key field — which it does. Minor gaps remain around idempotency and website targeting 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 description coverage is 100%, so the schema already documents all three parameters, giving a baseline of 3. The description reinforces the meaning of the required "description" field ("describe what it shows and when it helps"), but adds only marginal detail beyond the schema's own wording.

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

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

The description states a specific verb and resource ("Add an image the chatbot may show"), making it clear this registers an image asset for the chatbot to surface. It does not differentiate itself from close siblings like add_knowledge_text or add_knowledge_url, so it stops short of a 5.

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

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

Usage context is only implied: the second sentence explains that the AI reads the description to decide when the image answers a question, which hints at the image-serving use case. There is no explicit when-to-use-this-vs-alternatives guidance or routing to add_knowledge_text/add_knowledge_url.

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 cover readOnly=false, destructive=false, idempotent=false, and openWorld=true. The description adds value beyond them by clarifying that insertion is additive ('never replaces an existing one') and that the entry is immediately live for the chatbot, i.e. no indexing lag. It does not mention auth requirements or limits, but for this simple mutation the addition is meaningful.

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

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

Three short sentences, zero filler, with the core action front-loaded and the behavioral caveat immediately after. Nothing repeats the title or the schema.

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

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

There is no output schema, and the description covers the essential return-relevant behavior (usable immediately). With fully documented parameters and rich annotations, the definition is nearly complete; only the sibling routing for URL/image sources is left 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?

Schema description coverage is 100%, so title, content, and website_id are already documented including the default-primary-website behavior. The description adds nothing about parameters, which is the expected baseline when the schema carries the full 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?

States a specific verb and resource with scope ('a titled block of text to one website's knowledge base'), which cleanly separates it from add_knowledge_url and add_image among the add_* siblings. An agent can identify the right tool without opening the schema.

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

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

Explains the effect that determines when this is appropriate ('the chatbot can use it in answers as soon as this returns') and that it is purely additive. It does not name add_knowledge_url as the alternative for URL sources, so the when-not guidance is implied rather than explicit.

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

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

The description discloses the 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true and idempotentHint=false, covering the safety profile. The description adds the plan-tier prerequisite, which is genuine context beyond annotations. It still omits duplicate/error handling and what happens if the plan requirement is unmet.

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 the purpose front-loaded and the prerequisite second. Zero wasted words; everything is load-bearing.

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 6-param create tool with 100% schema coverage, complete annotations, and no output schema, the description covers purpose and the key plan prerequisite. Remaining gaps (duplicate handling, error behavior) are minor given the structured fields carry the rest.

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

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

Schema description coverage is 100%, so the schema fully documents all 6 parameters (including required 'name' and the website_id fallback to primary). The description adds no parameter detail beyond the schema, so the 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?

States a specific verb+resource ('Add a product') and adds scope by clarifying its effect ('chatbot can show as a card'). Clear enough to separate from add_image/add_knowledge_text siblings, though it doesn't explicitly name an alternative. Strong, specific purpose statement.

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?

'Needs the Standard plan or higher' provides a real prerequisite/eligibility condition, which is useful gating information. However there is no when-to-use vs alternatives guidance and no exclusions (e.g., how it differs from a general knowledge add). Implied usage only.

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?

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description contributes the user-visible effect (image disappears from the chatbot), but says nothing about permanence, whether the delete is reversible, or what happens if the image is referenced elsewhere.

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 short sentence, front-loaded with the action and its consequence, with no filler or redundancy.

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

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

For a single-parameter destructive tool whose annotations cover the safety profile and which has no output schema, the description is minimally sufficient to select and invoke it. It is thin on the consequences of an irreversible delete (referencing pages, caches, or audit implications), which would matter to an agent deciding whether 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?

With one parameter and 100% schema description coverage, the schema already documents image_id and points to list_images as its source. The description adds no format, range, or sourcing detail beyond that, so the baseline 3 applies.

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

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

The description gives a specific verb ('Remove') and resource ('one image'), and adds the observable consequence that the chatbot stops showing it. It is unambiguous against siblings like list_images or delete_product, though it does not explicitly name an alternative operation to contrast with.

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

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

There is no when-to-use or when-not-to-use guidance, no stated prerequisites or permission requirements, and no named alternative (e.g., reuse list_images to find the id, or a hypothetical hide/deactivate option). The only usage hint is indirect, via the schema's note that the id comes from list_images.

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, so the safety profile is known; the description still adds genuinely new behavior: the delete is permanent, irreversible, cascades to 'every passage built from it', and takes effect on the chatbot immediately. Only the cascade semantics and no-undo are supplied; nothing about auth or error behavior, but that is a reasonable gap.

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

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

Three short sentences, zero padding, with the destructive/permanent framing front-loaded ahead of the effect statement. Every sentence carries 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 single-parameter destructive tool with no output schema and full annotation coverage, the description supplies the two things an agent most needs: permanence and the cascade to derived passages, plus the immediate chatbot effect. Missing only explicit routing to list_knowledge for obtaining the id, which is covered by the schema.

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

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

Schema coverage is 100% and the single parameter is documented as 'The entry id from list_knowledge', which already explains both format and provenance. The description adds no parameter-level detail, 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?

A specific verb+resource ('Permanently delete one knowledge base entry') that clearly distinguishes it from its delete_* siblings such as delete_image, delete_product and delete_webhook. The scope ('one ... entry') is explicit.

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

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

The description conveys the consequence of using it ('chatbot stops using that content immediately') but never states when to prefer it, what prerequisites exist, or that list_knowledge should be consulted first – only the schema param hints at that. Usage is implied rather than guided.

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

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

Beyond the destructiveHint annotation, the description discloses the concrete effect: the chatbot stops sending on the next page open, and past message-log entries are retained. That tells the agent what is actually lost vs preserved, which annotations cannot express.

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

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

Three short sentences, each carrying distinct information: the operation, the runtime effect plus retention behavior, and the non-destructive alternative. Front-loaded and free of 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?

For a two-parameter destructive delete with full schema coverage and no output schema, the description covers effect, data retention, and alternatives. It stops short of stating failure behavior (e.g., nonexistent rule_id) or whether the deletion is reversible, which would make it fully complete.

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

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

Schema description coverage is 100%, and the schema already explains rule_id sourcing from list_proactive_messages and website_id fallback behavior. The description adds no syntax or format detail beyond that, so the 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?

States a specific verb and resource ("Delete one Proactive Messages rule") and immediately follows with the observable consequence, so the agent knows exactly what changes. It is clearly distinguishable from siblings like list_proactive_messages and save_proactive_message.

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

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

Names the alternative explicitly ("To pause a rule instead, use save_proactive_message with enabled false") and gives the condition that selects it, which is the most common confusion point for a delete tool. Nothing 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds the effect on the chatbot but says nothing about permanence, cascade effects on related data (e.g., images), or not-found behavior, so it adds only modest 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?

A single front-loaded sentence with the action first and the reason second; every word earns its place with no filler.

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

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

For a one-parameter delete tool with no output schema and annotations that carry the destructive/idempotent profile, the definition is nearly sufficient. The remaining gap is the absence of any note on irreversibility or what happens to a product's associated assets.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema ('Product id from list_products'). The description only implies singularity ('one product') and adds no syntax or format detail, 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?

States a specific verb and resource ('Remove one product') and adds the downstream consequence ('so the chatbot stops offering it'), which makes the intent unambiguous. It doesn't name the sibling it differs from (add_product or the other delete_* tools), so it falls short of 5.

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

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

The consequence clause hints at one scenario, but there is no explicit when-to-use, when-not-to-use, or prerequisite guidance. It doesn't clarify whether this differs from simply updating/deactivating a product.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond that: the effect is immediate ('Events stop reaching that address at once'), telling the agent this is not a soft/queued delete. It stops short of saying whether the deletion is reversible.

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, zero filler, and the actionable effect is front-loaded right after the operation statement.

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, non-output-schema tool with rich annotations, the description plus schema cover everything needed to invoke it correctly. The only minor gap is absence of when-to-use or undo guidance.

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 a single documented webhook_id that even points at list_webhooks as the source. The description adds no parameter meaning beyond the schema, so the 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?

States a specific verb and resource with scope ('Delete one webhook'), so it is immediately distinguishable from sibling delete_image/delete_product/delete_knowledge_entry. It is clear but does not explicitly name or contrast with any sibling, which keeps it below a 5.

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

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

The description gives no guidance on when to use this versus alternatives, nor any prerequisite such as confirming the webhook id from list_webhooks. Its only usage-relevant content is the implied single-target 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?

Annotations only say readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the description must explain the actual side effects — and it does: no email is sent, a plan credit is consumed, and Pro tier is required. Where it falls short is persistence: it never says whether the generated draft is stored server-side, which matters given readOnlyHint=false and is a plausible point of confusion with 'nothing is sent'.

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

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

Three short sentences, each earning its place: what it does and in what language, what happens next, and what it costs. The alternative tool and the safety fact ('nothing is sent') appear before the billing details, so the agent sees the critical routing information first.

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

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

For a 2-parameter generation tool with no output schema, the description covers input shape, language behavior, follow-up action, and quota requirements. The only gap is the shape of the returned draft (raw text vs. persisted object with an id usable by reply_to_email), which an agent would need when chaining.

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

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

Schema coverage is 100%, so baseline is 3; the description earns above baseline by illustrating the 'note' parameter with a realistic example ('refund approved, 20 EUR, in 5 days') and by stating that output language follows the customer rather than the note. thread_id semantics are fully covered by its schema description pointing to list_emails.

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?

Names a specific verb+resource ('Turn a short note ... into a full reply to an email conversation') and adds two distinguishing constraints: it works from an email thread and writes in the customer's language. This clearly separates it from reply_to_email (which sends) and reply_to_ticket (which targets tickets), so an agent can pick correctly without opening 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?

Explicitly states the two-step workflow — 'Nothing is sent: show the draft, then send it with reply_to_email' — naming the follow-up sibling. It also gives a concrete note example and states the prerequisites ('Spends one AI reply of the plan. Needs Pro or higher'), removing ambiguity about cost and eligibility before calling.

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 only declare it is not read-only and not destructive; the description adds three behavioral facts annotations cannot express: no side effect occurs on the customer side, one plan AI reply is consumed per call, and a Pro+ subscription is required. Those are exactly the traits an agent needs before invoking a metered AI tool.

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

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

Three short sentences, no waste, and the most decision-relevant fact (nothing is sent, use reply_to_ticket) is front-loaded before the cost and plan-tier notes.

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

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

For a two-parameter tool with a small schema and no output schema, the description covers purpose, side effects, follow-up, cost and access tier. It stops short of saying whether the draft text is returned inline in the response, which is the one thing an agent reviewing the result would want confirmed.

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

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

Schema coverage is 100%, so both parameters are already documented with examples. The description adds only the implicit idea that the note is a short input expanded by the AI, which is marginal beyond the schema's 'What the reply must say, in a few words.' 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?

States a specific transformation ('turn a short note into a full reply to a ticket's customer') on a specific resource. The mention of 'ticket' implicitly separates it from the sibling draft_email_reply, and the language-adaptation detail adds scope the name does not convey.

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?

Explicitly states when this is only a draft ('Nothing is sent: show the draft') and names the follow-up tool and condition ('then send it with reply_to_ticket'). It also gives prerequisites ('Needs Pro or higher'), so the agent knows whether it may call it at all.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds a genuinely new behavioral fact not in any structured field: the Pro plan requirement, which can cause the call to fail or return nothing.

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

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

Two sentences, front-loaded with the verb and resource, then the field list, then the plan constraint. The field enumeration is dense but every item earns its place by substituting for the missing output schema.

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

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

With no output schema, the description carries the burden of describing return content and does so field by field, and it also discloses the plan prerequisite. Nothing an agent needs to select and invoke this correctly is missing.

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

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

Schema coverage is 100% and the single website_id parameter already documents its source (list_websites) and the omit-for-primary-website default. The description only reinforces that one site's settings are returned, which is marginal added meaning over 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?

"Show one website's AI email reply settings" gives a specific read verb plus a precisely scoped resource, and the enumeration (on/off, drafts vs automatic, delay, rules, alert and forwarding addresses) tells the agent exactly what data comes back. The read verb contrasts implicitly and cleanly with the sibling update_email_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 description supplies real usage context: it applies to a single website and requires the Pro plan or higher, which lets an agent rule it out for free-tier accounts. It does not explicitly route to update_email_settings for changes, so a small inference is left 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond that: the plan-gated access requirement and the ordering/contents of the returned thread, which the agent cannot infer from 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 short sentences with no waste. The core action and result shape are front-loaded, and the plan constraint is packed into a single trailing clause.

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 usefully compensates by describing return contents and ordering. For a single-parameter read tool the coverage is nearly complete, with only explicit sibling routing left out.

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 thread_id's provenance ('from list_emails') is documented in the schema itself. The description adds no further parameter meaning, so the 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?

States a specific verb and resource ('Read one email conversation') and enumerates exactly what the result contains: customer emails, AI replies/drafts, and team replies. The singular 'one conversation' plus the ordering note cleanly separates it from the list_emails sibling.

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

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

Gives a concrete prerequisite ('Needs the Pro plan or higher') and implies use after list_emails via the schema's thread_id source. It does not explicitly state when to prefer this over list_emails or get_conversation, so it stops short of full alternative routing.

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

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

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 declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the oldest-first ordering of the embedded chat and emails, the plan tier required, and the conditional rule that email replies need Pro while chat replies only work for widget-originated tickets.

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?

Front-loaded with the core verb+resource, then a compact enumeration of returned content, then a one-line gating note. Slightly dense in the middle clause but no sentence is wasted.

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 correctly takes on the job of describing return contents and ordering, plus plan and channel constraints. Minor gaps remain: behavior when the ticket number doesn't exist, and whether long chats/email threads are truncated or paginated.

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

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

Only one parameter and the schema covers it at 100%, including a format example (TKT-00042) and a pointer to list_tickets. The description adds nothing about the parameter, so the 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?

States a specific verb and resource ("Read one support ticket") and then enumerates exactly what the read returns: details, the originating chat, and emails sent from it, ordered oldest first. The singular "one" cleanly separates it from the sibling list_tickets without needing to name it.

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 prerequisites (Standard plan or higher, email answering needs Pro, chat answering only for website-widget tickets) but never says when to reach for this tool versus alternatives such as list_tickets or get_conversation, nor how to obtain a ticket_number beyond the schema hint. Usage is implied rather than directed.

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 establish read-only, idempotent, non-destructive, closed-world behavior, so the description adds useful context rather than carrying the full burden. It adds that the tool returns plan-gated settings and the required plan for each, and clarifies the boundary between general greeting/auto-trigger bubbles and Proactive Messages. It does not add auth, rate-limit, or detailed response-shape information, but those are less critical given the rich 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 tight sentences, front-loaded with what the tool returns and what categories of settings are included. The third sentence earns its place by preventing confusion between general widget settings and Proactive Messages.

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 one optional parameter, rich safety annotations, and no output schema, the description provides enough return-value context: all appearance and behaviour settings plus plan-restricted settings and required plans. An agent can call it correctly and understand the main content of the response without further output documentation.

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

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

Schema description coverage is 100%: website_id is documented as coming from list_websites and omittable to use the primary website. The description only refers to 'one website's chat widget' and does not add syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description uses a specific verb and resource: 'Read all appearance and behaviour settings for one website's chat widget'. It also distinguishes the scope from Proactive Messages by naming list_proactive_messages, and the read-only framing contrasts with 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 gives clear context for when to use the tool: reading all widget appearance and behaviour settings for a website. It explicitly routes click/page/time/event messages to list_proactive_messages, but does not explicitly say when to use update_widget_settings instead for mutations or list_widget_translations for translations.

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?

Annotations already cover read-only/idempotent safety, so the description adds real context beyond them: default ordering (newest first), the plan gate, and returned fields. Missing pagination/empty-state behavior keeps it short of 5.

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

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

Three compact clauses: what it lists and ordering, the returned fields, then the plan gate and the sibling redirect. Front-loaded and waste-free.

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?

A simple zero-required-param read list with a fully documented schema and annotations; the description covers purpose, scope, ordering, plan gate and next step. Pagination behavior is the only notable omission, minor given the limit 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 coverage is 100% with rich enum and limit descriptions, so the schema carries parameter meaning. The description adds only the implicit default sort order and the 'one website' scoping already implied by website_id's 'Omit to use primary'.

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?

Specific verb+resource ('List the email conversations') scoped to one website's Email inbox, and it names the returned fields (subject, sender, snippet, needs-answer flag). It is clearly distinguished from siblings like list_conversations, list_tickets and get_email_thread.

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?

Explicitly routes single-thread reads to get_email_thread, and the plan requirement ('Pro plan or higher') plus 'one website' scoping tells the agent prerequisites. No explicit when-not-to-use for e.g. list_conversations vs email, so 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 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 declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the payload shape (price, allowance, features, current plan) and the fact it spans both all plans and the account's own — context a no-param list tool otherwise wouldn't convey.

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, zero padding. The contents come first and the usage cue second, which is the right front-loading for a listing tool.

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

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

With no output schema, the description carries the burden of saying what comes back, and it does list the key fields plus the current-plan comparison. It does not describe ordering, pagination or whether historical/legacy plans are included, minor gaps for a no-arg static listing.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; the baseline for a no-param tool is 4. Nothing in the description is needed to explain inputs, and it doesn't waste words pretending otherwise.

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 (Asyntai plans) and enumerates the returned content — price, monthly message allowance, included features — plus the account's current plan. No sibling tool lists plans, so it is trivially distinguishable from the surrounding add_/get_/list_ family.

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 a concrete trigger: 'Use it to explain which plan includes a feature the account asks about.' This tells the agent when to reach for it during plan/feature questions. It stops short of naming an alternative or an exclusion condition, but no competing sibling exists for this data, so the guidance is effectively complete.

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 safety is covered; the description adds genuinely new behavioral context: newest-first ordering, the per-entry fields, that name/email only appears when the site sends User Context, and that replied entries carry a conversation link.

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

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

The resource and ordering constraint are front-loaded, and the long enumeration of returned fields is dense but informative. The closing sentence earns its place by stating purpose; no filler sentences.

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 describing return values, and it does so thoroughly: fields, ordering, conditional visitor identity, and linked conversations. Pagination and limits are left entirely to the schema, which is a minor gap for a log-listing tool.

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

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

Schema coverage is 100%, with limit bounds, rule_id filtering, before_id cursor semantics and website_id defaulting all documented in the schema. The description adds no additional parameter meaning beyond mentioning 'the rule' as a returned field, 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?

The description states a specific resource and what each record represents: 'each proactive message a visitor saw', framed as an exposure log rather than a rule configuration. This implicitly separates it from list_proactive_messages (the rules), but it never names that sibling, so an agent must infer the 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?

'Use it to see who saw a message and whether a rule works' gives a concrete use case that fits the tool well. It does not state when-not to use it or point to list_proactive_messages for editing/reading the rules themselves, leaving that routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered; the description adds useful output detail that no output schema provides: 'every rule with its id and its counts for the last 30 days (shown, opened, replied).' It does not mention pagination or ordering, which limits it to a 4.

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 text is front-loaded with the core definition and builds to usage triggers and then the return shape. The WHEN/WHAT/HOW exposition is informative but slightly verbose for a single read-only list tool; a tighter version would drop some of the phrasing without losing 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 single-optional-parameter read-only listing tool with no output schema, the description covers concept, use cases, and returned fields plus a time window. Nothing an agent needs to invoke it correctly appears to be missing.

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

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

Schema coverage is 100% and website_id is fully documented in the schema, including the default behavior when omitted. The description adds no parameter-level guidance, so the baseline of 3 applies.

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

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

The description defines a specific resource (Proactive Messages rules) with a clear verb (list/returns every rule) and explains the domain concept so an agent understands what a 'rule' is even without prior knowledge. It distinguishes this tool from siblings such as list_proactive_message_log (per-event log) by stating it returns rules with aggregate counts.

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

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

It gives explicit trigger examples: 'anything like a triggered message, an automatic message, a message on click, on a page or after some seconds,' which map user intents to this tool. It does not explicitly name when NOT to use it or contrast with list_proactive_message_log, which likely returns individual fired messages, so it falls short of the top score.

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

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

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes beyond by disclosing the result shape (first questions only, no answers) and two non-obvious behaviors: grouped counts are estimates, and exact per-category counts appear only when Chat Categories is on. It doesn't mention pagination/truncation beyond the limit param, keeping it short of a 5.

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

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

Four tight sentences, front-loaded with the core behavior and then usage, caveat, and the pointer to the alternative. No filler; every clause earns its place.

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

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

With no output schema, the description carries the return-shape burden and does so reasonably: first questions only, no answers, plus category counts when enabled. Ordering/pagination of the returned list is the only notable omission for a list tool.

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

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

Schema description coverage is 100%, so days, limit, per_chat and website_id are already documented in the schema with ranges and defaults. The description adds no format or syntax detail beyond that, so the 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?

States a specific verb and resource (list visitor questions) plus the exact scope: the first questions of each conversation, without the chatbot's answers. This distinguishes it cleanly from list_conversations and get_conversation, which the agent can tell apart without opening 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?

Gives an explicit use case (find what customers ask about most by grouping by meaning) and names the alternative for a different need: 'To read one conversation in full, use get_conversation.' When-to-use and when-to-use-something-else are both present.

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 non-read-only, non-destructive, idempotent behavior, yet the description adds real value: no message is sent, the thread leaves the 'Needs a person' list, and a Pro plan is required. It does not say whether the action can be undone.

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

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

Three short sentences, front-loaded with the action and immediately followed by the critical 'nothing is sent' clarification. No wasted text.

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

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

For a one-parameter mutation with no output schema, the description covers the state change, the absence of an outbound message, and the plan gate. Only reversibility/undo 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?

Single parameter with 100% schema description coverage; the schema already explains that thread_id comes from list_emails. The description adds no additional syntax or format detail, 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?

States a specific verb and resource: marking an email conversation as answered, with the clarifying 'Nothing is sent.' That implicitly separates it from reply_to_email and draft_email_reply, though those siblings are never named outright.

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 a concrete usage context ('for example in its own mail program') and states the effect on the 'Needs a person' list, which tells the agent when this applies. It stops short of explicit when-not conditions or naming the reply/draft alternatives it replaces.

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

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

Annotations already declare the write/idempotent/open-world profile, and the description usefully adds that the AI resumes 'from the next message' rather than retroactively. But it does not explain what 'destructive' entails here, whether in-flight handoff state is lost, or any permission requirements, leaving meaningful behavioral gaps for a destructive-marked mutation.

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 action and the resulting behavior are packed into one clause each, with no redundancy against the title.

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 one required param, full schema coverage, no output schema, and annotations covering the safety profile, the description is nearly complete for invoking the tool correctly. Only the semantics of the destructive flag and any handoff side effects remain unexplained.

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 a single parameter with 100% schema description coverage, so the schema already documents session_id. The description adds no syntax or format guidance beyond what the schema supplies, making the baseline 3 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?

States a specific verb+resource: handing a taken-over conversation back to the AI. It is clearly the inverse of the sibling take_over_conversation, but the description never names that sibling, so the differentiation is implied rather than explicit.

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

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

The phrase 'a taken-over conversation' implies this is used after take_over_conversation, giving implied usage context. However, no explicit when-to-use, prerequisites, or named alternatives (e.g., send_agent_reply vs release) are 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?

Annotations already flag this as a non-readonly, non-idempotent, open-world write, and the description adds real context beyond them: delivery is immediate and irreversible ('the customer receives it at once'), a human confirmation step is required, and the action is plan-gated. Those are exactly the facts an agent needs before committing an external side 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?

Three sentences, front-loaded with what the tool does, then the safety gate, then the plan requirement. Nothing is repeated and no sentence could be dropped without losing a decision-relevant fact.

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 the risk profile, prerequisites, and delivery semantics well for a two-parameter mutation tool. The only gap is the response: with no output schema, the description doesn't say whether it returns a message id or updated thread state, which matters slightly for follow-up calls like mark_email_answered.

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

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

Schema description coverage is 100%, and both parameter descriptions already say what message and thread_id are, including the 'from list_emails' provenance. The description adds no formatting, length, or content constraints, so the 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?

States a specific verb and resource (send an email reply) plus scope: the customer of one email conversation, in the same thread, from the support address. That cleanly separates it from draft_email_reply and reply_to_ticket, which an agent can rule out without opening their schemas.

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

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

Gives a clear precondition (show the user the exact wording and get agreement first) and an eligibility constraint (Pro plan or higher). It never explicitly names draft_email_reply as the alternative for the pre-approval step, so the routing is implied by 'Send' versus 'draft' rather than spelled out.

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

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

Annotations already declare this is not read-only, not idempotent, and open-world, so the safety profile is known. The description adds real value beyond that: the effect is externally visible to the customer, it is plan-gated (Pro or higher), channel chat is restricted to widget tickets, and the reply may be surfaced in two places (email plus website chat). It does not spell out what happens on a closed or already-resolved ticket, or that retrying will duplicate the send despite idempotentHint=false.

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

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

Three sentences, front-loaded with the core action and followed by the per-channel conditions and the confirmation caveat; nothing is padding. The channel discussion is telegraphic ("channel email (Pro or higher) sends an email"), which reads awkwardly but keeps it short. No restructuring needed.

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

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

This is a two-required-parameter mutation with no output schema, and the description covers the external side effect, plan gating, channel eligibility, and the need for user consent — the things an agent must know before calling. Remaining details (return payload, ticket-state behavior) are either absent by design or carried by the schema's resolve/also_chat descriptions.

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

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

Schema coverage is 100%, so the enum, defaults and formats are already documented and the baseline is 3. The description earns the extra point by explaining the real-world semantics behind the channel enum (plan requirement, widget-only constraint) rather than restating the enum values. The resolve and also_chat booleans are left entirely to the schema.

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

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

The description states a specific verb and resource ("Answer a ticket's customer") and immediately distinguishes the two modes of the action: channel email sends an email, channel chat posts to the website chat. An agent knows exactly what the tool does and that it is a real send rather than a draft ("The customer gets it"). It does not name the sibling draft_ticket_reply that performs the near-identical but non-sending action, which is the one differentiation that would push this to a 5.

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

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

It supplies the conditions that govern channel choice — email requires Pro or higher, chat only works for widget-originated tickets — plus a clear precondition ("get the user's agreement first") before sending. That is actionable when-to-use context. It stops short of explicitly routing the agent between this tool and draft_ticket_reply or send_agent_reply, so a reader must infer the send-vs-draft split.

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?

Goes well beyond the annotations by disclosing partial-update semantics ('fields you leave out keep their value'), the AI-credit cost of ai mode, mobile forced-bubble behavior, and the client-side code the site must ship for event triggers. It does not state reversibility or whether an omitted display/enabled resets anything on update, so not quite a 5.

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

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

Front-loaded with purpose and the add-vs-update rule, then cost/plan facts, then the code sample. The JavaScript snippet is long but is the only way to convey the event contract; a few clauses (mobile bubble, fixed-vs-AI cost) sit slightly awkwardly mid-paragraph.

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 an 11-parameter mutation with no output schema, the description covers plan gating, partial-update behavior, cost model, platform rendering differences, and the event-trigger integration requirement. Everything an agent needs before calling is present, with the field-level detail delegated to a fully documented 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%, so baseline is 3; the description earns extra by explaining the rule_id/omission convention and by giving a concrete event-trigger code sample that defines what trigger_value must contain for trigger_type=event. Other parameter meanings (frequency, display) are left to the schema's own enum docs.

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 opening sentence names a specific verb pair (add/change) and the resource (Proactive Messages rule), and immediately differentiates from update_widget_settings for the general-greeting case. An agent can distinguish it from list_proactive_messages and delete_proactive_message without opening any schema.

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

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

Explicit routing rules: pass rule_id to change an existing rule, omit it to add a new one (both sourced from list_proactive_messages), and use update_widget_settings instead for a general greeting bubble. It also states the Pro/Enterprise plan prerequisite, which is a hard gate an agent must check.

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 declare the write/destructive/idempotent profile, so the bar is lower; the description usefully adds that enabling creates a signing secret on the server and that the plan gates the operation. It does not explain what disabling does to already-issued entitlements, which is the main destructive behavior left unexplained.

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

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

Three short sentences with zero filler, front-loading the action before the side effect and the plan requirement. Every sentence carries distinct information.

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

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

For a two-parameter boolean toggle with no output schema, the description covers purpose, side effect, and prerequisite. The one gap is that destructiveHint=true is never elaborated (what turning off destroys/revokes), which matters for a destructive operation.

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

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

Schema description coverage is 100% and both parameters are already documented inline (including 'Omit to use the account's primary website'). The description only restates the single-website scope, adding no syntax or defaulting detail beyond the schema, 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?

States a specific verb ('switch on or off') and resource ('Access Tags') scoped to 'one website', plus the concrete consequence of enabling. No sibling tool overlaps this function, so an agent can select it unambiguously.

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 a real prerequisite ('Needs the Enterprise plan') and implies the single-website scope, which is genuine when-to-use context. It does not name an alternative or an explicit when-not-to-use case, so it falls short of a 5.

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

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

Annotations already declare readOnly=false, idempotent=true, openWorld=true and destructiveHint=true, so the safety profile is largely covered. The description adds the plan-gating requirement, which is valuable, but says nothing about the effect of turning it off (e.g. stopping delivery) that would justify the destructive hint.

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, action first and constraint second, with zero filler. Everything is front-loaded and every clause carries information.

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

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

For a two-parameter toggle with no output schema and annotations that already convey idempotency and destructiveness, the description covers purpose, scope, and plan eligibility. Nothing essential to calling it correctly is missing.

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

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

Schema coverage is 100%, and the schema fully documents 'enabled' and 'website_id', including the 'omit to use primary website' fallback. The description's 'for one website' adds only a slight scoping hint, 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?

Specific verb (turn on/off) plus resource (daily email summary of chats) and scope (one website). The read/write distinction from the sibling get_daily_report is inferable, but the description never explicitly contrasts them, so it stops short of full sibling differentiation.

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

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

It supplies a useful prerequisite ('Needs the Standard plan or higher'), which is genuine when-to-use context. However, it gives no guidance on when to use set_daily_report versus get_daily_report, nor any exclusions or side-effect warnings that would steer selection.

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

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

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 readOnlyHint=false, destructiveHint=true, idempotentHint=true. The description adds substantial context beyond them: the visitor must present a tag signed by your own server, an empty list reverts the entry to public, and the feature requires the Enterprise plan. This meaningfully informs behavior and prerequisites.

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