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?

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?

The annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to restate these. The description adds detail about the returned data but does not go beyond the annotations in describing side effects.

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

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

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

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

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

Given the absence of an output schema, the description sufficiently enumerates what the caller can expect: email, plan, and chat message usage against the monthly allowance. This is complete for the tool's low complexity.

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

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

The input schema has no parameters, so there is nothing for the description to explain. The tool takes no arguments, and the description appropriately focuses on the output rather than parameters.

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

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

The description clearly states the tool returns the signed-in account's email, plan, and chat message usage against its monthly allowance. This is a specific and unambiguous verb-resource pairing that distinguishes it from the many list- and search-oriented sibling tools.

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

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

The description makes the tool's purpose obvious but does not explicitly state when to prefer it over alternatives. Since no other sibling tool targets account details, the context is sufficient, but explicit guidance is absent.

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

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

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

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

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

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

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

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

For a simple read-only retrieval tool with one optional parameter and no output schema, the description provides enough context for correct use. The scope and content of the returned instructions are sufficiently indicated, and the schema fills in the parameter behavior.

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

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

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

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

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

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

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

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

The intended use is implied by the description and parameter semantics, but there is no explicit guidance about when to choose this tool over alternatives such as update_ai_instructions or get_widget_settings. It does not state when to use it versus related read tools, though the purpose is reasonably clear.

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

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

The readOnly and idempotent annotations already cover the non-destructive nature, and the description reinforces a pure summarization behavior. It additionally clarifies the scope ('one website') and the kind of data included, which goes slightly beyond the annotations.

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

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

The description is a single, compact sentence with no redundant phrases. It front-loads the core purpose and then efficiently lists the included metrics, making it easy to scan.

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

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

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

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

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

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

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

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

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

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

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

The description implies usage when an aggregate summary of chat activity is needed, and the period parameter is referenced. However, it does not explicitly contrast with alternatives like get_daily_report or list_conversations, leaving some ambiguity about when to prefer this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds only the phrase 'in full', which hints at the completeness of the returned content. It does not disclose any other behavioral details such as error handling, pagination, or response format. Given the annotations cover the main safety aspects, a score of 3 is appropriate as the description adds minimal extra behavioral context.

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

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

The description is a single sentence that packs all essential information: what it does, how to supply the input, and an example. It is front-loaded with the primary action and resource, with no fluff or redundancy. Every clause contributes to usability.

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

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

For a simple read-only tool with one parameter and no output schema, the description is complete. It explains the purpose, the source of the slug, and provides examples. The safety profile is fully covered by annotations. There is no missing information an agent would need to invoke the tool correctly. The return value is implied by 'read in full' and does not require explicit specification given the absence of an output schema.

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

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

The schema already provides a description for the 'page' parameter, and the schema description coverage is 100%. The tool description goes beyond by giving concrete examples ('/documentation/mcp/' or 'mcp') and specifying the source of the slug (from search_asyntai_docs), which adds useful context and disambiguates the expected format. This is valuable beyond the schema alone.

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's job is lighter. It adds value by specifying the result is the full message history in order, which is behavioral context not covered by annotations. No contradictions with annotations.

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

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

A single, front-loaded sentence with zero filler. The main action is stated first and the key input (session id) is mentioned, making it efficient and scannable.

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

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

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

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

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

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

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

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

The description clearly states the verb (read), resource (one conversation), and scope (full message history, in order). It distinguishes from siblings like list_conversations (which lists conversations) and send_agent_reply (which writes), making the tool's purpose unambiguous.

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

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

The description implies usage: to read a conversation's full history given its session id. It hints that session_id comes from elsewhere (likely list_conversations) but does not explicitly name alternatives or state when not to use this tool. The context is present but exclusions are not stated.

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

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

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

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

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

The description is a single, well-structured sentence that directly conveys the core functionality. It avoids redundancy and uses plain language, making it easy to parse and act upon.

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

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

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

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

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

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

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

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

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

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

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

The description implies usage for reading the daily report setting, but it does not explicitly mention alternatives like set_daily_report or when to prefer this tool over get_analytics. The phrasing is clear enough for an agent to infer the correct use case, but explicit guidance is absent.

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

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

The annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds a potentially confusing note about website crawls being 'listed but not exported,' which may relate to behavior but is not clear. No contradictions with annotations.

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

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

The first sentence is concise and front-loaded, but the following two sentences are confusing and not well-structured. The phrase 'A website crawl is listed but not exported' is ambiguous and could be omitted or clarified, detracting from the overall clarity.

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

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

For a simple read operation with one parameter, the description adequately covers the purpose and mentions supported content types. However, the unclear statement about website crawls leaves some ambiguity about what is retrievable, making it less complete than it could be.

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

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

The schema already provides a meaningful description for the single parameter, entry_id, referencing list_knowledge. The tool description does not add further detail about the parameter, so with high schema coverage the baseline is appropriate.

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

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

The description clearly states the tool reads the stored text of one knowledge base entry. This distinguishes it from listing or searching the knowledge base, and the verb 'read' is specific.

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

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

The description implies use when retrieving a single entry, and the parameter description says the entry_id comes from list_knowledge, providing some guidance. However, it does not explicitly name alternative tools or say when not to use it, though the context is fairly clear.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns the embed code and field list, which is useful but not rich behavioral context (e.g., no mention of defaults, pagination, or response shape). With the safety profile fully covered by annotations, a 3 is appropriate.

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

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

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

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

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

With no output schema, the description carries the burden of documenting the return shape; it does so by enumerating key fields (name, domain, platform, widget id, embed code). For a simple get-by-id tool with a single optional parameter and annotations covering safety, this is sufficient. Minor gap: it assumes the agent knows what the 'embed code' is and doesn't hint at other possible fields, but the main expected values are covered.

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

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

The input schema has 100% coverage: the single parameter `website_id` already describes its source ('from list_websites') and default behavior ('Omit to use the account's primary website'). The tool description adds no extra parameter semantics beyond the schema, so the baseline of 3 holds.

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

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

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

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

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

The description implies usage: 'Get the full record for one website' contextualizes when to use it (need full website details). However, it does not explicitly state when not to use it or point to alternatives like list_websites for summaries or get_website_features for feature-specific data, leaving the agent to infer the differentiation.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by specifying the exact output shape — 'Shows current values, which features the plan allows, and the plan each locked feature needs' — and by noting the optional parameter behavior ('Omit to use the account's primary website'), which is a useful behavioral nuance not present in the annotations.

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

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

The description is front-loaded with the core purpose in the first clause, and the subsequent feature enumeration is information-dense with no filler or redundancy. The list of twelve features is long, but each item is meaningful for disambiguating scope from sibling tools. The closing sentence about output contents is compact and adds necessary detail without padding.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

One concise sentence, no fluff, effectively communicates the full scope of the tool and its limitations (plan-related restrictions).

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

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

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

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

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

Schema description coverage is 100% for the single parameter (website_id). The description adds no additional meaning beyond the schema's existing explanation, so baseline 3 applies.

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

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

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

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

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

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

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

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

The annotations already indicate a read-only, idempotent, non-destructive operation. The description adds the plan requirement and clarifies the data scope, with no contradictory behavior. It does not mention pagination or rate limits, but the annotation coverage lowers the burden.

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

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

The description is a single, focused sentence that lists what is returned, followed by the plan requirement. Every part is useful and there is no redundant or ambiguous wording.

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

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

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

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

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

The schema descriptions already cover 100% of parameters, including limit bounds and website_id semantics. The description does not add further parameter-level detail beyond the schema, so the baseline score applies.

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

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

The description clearly states the verb 'List' and the resource 'visitors currently in a chat', with specific fields returned (page, country, duration, human takeover). This distinguishes it from sibling tools like list_conversations by focusing on live visitor sessions rather than conversation records.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It only notes the Enterprise plan restriction, which is a prerequisite, not a usage scenario. No mention of typical use cases or comparison to other read-only tools.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds the plan requirement but does not elaborate on side effects or response behavior, so it provides moderate additional context beyond the annotations.

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

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

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

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

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

The description covers what the tool returns (length, price, spots) and a key prerequisite (plan). It lacks information about pagination or filtering, but this is not critical for an MVP listing tool, making it adequately complete.

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

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

The single parameter website_id is fully documented in the schema with clear semantics (numeric id, optional, defaults to primary). The tool description does not add extra parameter detail, so the score matches the baseline for complete schema coverage.

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

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

The description clearly states the tool lists appointment types with length, price, and spot counts. It is distinct from sibling tools like list_products or list_images, making its purpose unambiguous.

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

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

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

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior, so the description does not need to restate safety. It adds the 'newest first' ordering as behavioral detail, but does not discuss side effects (which is appropriate given annotations). Overall, it provides marginal added value beyond the annotations.

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

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

The description is a single focused sentence with no redundant words. It efficiently conveys the action, scope, ordering, and key output fields, making every word necessary.

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

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

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

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

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

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

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

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

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

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

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

The description does not mention when to use this tool versus alternatives such as get_conversation or list_leads. While the scope and ordering are implied, there is no explicit guidance on selection criteria or comparisons with sibling tools.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds value by specifying the returned fields (status, page count, stop reason) without contradicting the annotations. No side effects are implied.

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

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

The description is a single, focused sentence that conveys the essential information without any unnecessary words.

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

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

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

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

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

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

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

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

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

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

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

The description provides clear context that this is for retrieving crawl job history, but does not explicitly mention alternatives or when not to use it. However, the purpose is evident enough for an agent to select it appropriately among siblings.

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

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

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

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

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

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

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description covers the purpose, scope, examples, and a key prerequisite. No critical information is missing.

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

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

There is only one parameter (website_id) and its schema description fully explains its meaning and default behavior. The description adds no extra parameter context, but the schema already provides sufficient coverage.

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

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

The description clearly states the tool lists third-party tools embedded in the chat, with concrete examples (booking calendar, form). This distinguishes it from other list tools like list_images or list_webhooks.

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

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

It provides a clear prerequisite (Standard plan or higher) and references the website_id source from list_websites. However, it does not explicitly contrast with alternative list tools, though the name and scope make the intended use clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by stating the output includes descriptions for relevance, which is useful context. However, it doesn't mention pagination, ordering, or response structure. The added context is modest.

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

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

The description is a single, efficient sentence that front-loads the action and resource, then adds the key qualifier about relevance descriptions. There is zero waste; every word contributes.

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

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

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

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

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

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

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

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

The description clearly states the action (list) and resource (images) with a specific scope ('the chatbot may show a visitor'). It also mentions the output includes relevance descriptions. It distinguishes from siblings like add_image/delete_image by the verb, though it doesn't explicitly name them. The purpose is unambiguous.

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

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

The description gives clear context for when to use the tool: to retrieve images the chatbot can show. It implies usage for reviewing available images but does not explicitly state when not to use it or mention alternatives. This is adequate for a simple read-only list.

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

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

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

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

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

The description is a single, compact sentence that communicates the core purpose and the four source categories without any redundant words or tangential details. It is easy to read and appropriately front-loaded.

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

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

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

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

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

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

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

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

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

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

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

The description conveys the general use case—listing all knowledge-base sources for a website—but it does not explicitly explain when to prefer this tool over sibling tools such as get_knowledge_entry, search_knowledge_base, or add_knowledge_text. The guidance is acceptable but could be more explicit.

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

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

The description appropriately indicates a read-only listing operation via 'List' and 'recorded', consistent with the readOnlyHint, idempotentHint, and destructiveHint annotations. It also adds the plan requirement, which is useful context beyond the annotations.

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

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

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

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

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

The description is complete for the tool's primary purpose and integrates well with sibling tools, though it does not describe the output shape. Since no output schema is provided, a brief note on returned fields could enhance completeness, but it is not strictly necessary.

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

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

The schema covers all parameters with descriptions, and the prose adds meaningful defaults for days and limit, clarifies include_resolved is off by default, and points users to list_websites for website_id. This exceeds mere schema repetition.

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

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

The description clearly states the tool lists knowledge gaps recorded by Asyntai, defined as real visitor questions the chatbot could not answer. This distinguishes it from related tools like list_knowledge and search_knowledge_base, and explicitly connects it to add_knowledge_text for follow-up.

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

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

The description gives practical guidance by identifying that the tool is for finding gaps to fill with add_knowledge_text and notes the Standard plan requirement. It does not explicitly enumerate when not to use it, but the purpose is clear enough for an agent to select appropriately.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior, which the description aligns with. The additional mention of 'newest first' provides ordering context beyond the annotations, though it does not describe pagination or error handling.

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

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

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

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

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

Given the lack of an output schema, the description adequately specifies what is returned (email addresses, phone numbers, and page context) and ordering. It omits details like pagination or total count, but the core functionality is sufficiently covered.

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

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

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

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

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

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

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

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

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

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

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

Annotations already 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 mark readOnly/idempotent/non-destructive; description adds relevant plan prerequisite and output contents. No contradiction.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by specifying the output content: members, their reach, and seat counts. It does not repeat the annotations and adds value beyond them.

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

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

The description is a single, compact sentence that front-loads the main verb and resource, then adds the key details. There is zero waste; every element contributes to understanding what the tool does.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description is a single concise sentence that conveys the core functionality and a key constraint without any fluff or unnecessary details.

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

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

The description mentions the return fields (status, priority, visitor details) and the plan requirement, which is sufficient for a simple list tool. It does not specify pagination behavior beyond the limit parameter, but the schema covers that, so the description is reasonably complete.

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

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

The schema descriptions cover all parameters (limit, status, website_id) thoroughly, and the tool description adds no additional meaning to the parameters. Since schema coverage is high, the baseline of 3 applies.

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

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

The description clearly states the tool lists support tickets raised from chat, including status, priority, and visitor details, which distinguishes it from other sibling tools like list_conversations. It also specifies the plan requirement, making the purpose unambiguous.

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

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

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

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

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

Explicitly discloses that the signing secret is never returned and is only shown at creation, which is important security behavior not captured in annotations.

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

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

Two concise sentences, each carrying essential information without redundancy or unnecessary words.

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

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

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

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

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

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

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

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

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

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

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

Provides clear context for listing webhooks, and the sibling names make the distinction obvious, though it doesn't explicitly say 'use this when you need to see existing webhooks'.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful behavioral note that this tool provides the id used by other tools, which is beyond the annotations. It does not mention pagination or return format, but given the annotations cover the safety aspects, the description adds some value, so a 3 is appropriate.

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

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

The description is two concise sentences with no wasted words. The primary action ('List the websites') is front-loaded, and the key usage advice ('Start here...') is included without clutter. Every word earns its place.

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

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

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

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

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

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

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

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

The description clearly states the verb 'list' and the resource 'websites (AI agents)' on the Asyntai account. It also adds the distinguishing detail that this tool returns the 'id every other tool takes', which separates it from siblings like get_website or create_website, making its purpose unambiguous.

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

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

The description provides explicit guidance on when to start here: 'Start here when the account may have more than one.' This clearly indicates the condition for using this tool. However, it does not explicitly mention when not to use it or name an alternative, though the context implies that if you already know the id you might go directly to get_website. This is a clear usage context without full exclusion logic.

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

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

Annotations already declare readOnly and idempotent behavior. The description adds context about what the output contains (languages, greeting, agent name), going beyond the basic 'list' verb without contradicting the annotations.

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

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

The description is a single, well-structured sentence that front-loads the action ('List') and provides necessary details about the output without extraneous words.

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

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

The operation is simple, with read-only annotations covering safety. The description sufficiently communicates the purpose and expected content, making it complete enough for an agent to call correctly despite the lack of an output schema.

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

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

The single parameter website_id is fully described in the schema with clear instructions on its source and optionality. The tool description does not add further parameter-related meaning, so baseline 3 is appropriate.

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

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

The description clearly states the tool lists the languages for which the chat widget has translations, including the greeting and agent name. This distinguishes it from sibling tools like set_widget_translation (which modifies) and other list tools.

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

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

The description implies a read-only retrieval operation but does not explicitly state when to use this versus alternatives (e.g., before setting a translation with set_widget_translation). The guidance is implicit rather than explicit.

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

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

Annotations already declare 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 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.

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

Front-loaded purpose sentence, then mechanism, then the reset edge case, then a plan constraint. Four tight sentences with no filler, though the plan requirement could arguably be trimmed or grouped.

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 mutation with full schema coverage and no output schema, the description covers purpose, mechanism, reset behavior, and the Enterprise-plan prerequisite. Adequate; only the sibling disambiguation 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%, so both parameters are already documented, including the empty-list-makes-public behavior. The description restates that same fact without adding syntax, ordering, 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+resource: restrict retrieval access to one knowledge base entry via tags. The scope ('one entry') is clear. It does not differentiate itself from the sibling set_access_tags, so an agent cannot be fully certain which mutation to pick from the name/description alone.

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

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

The description explains the effect and the empty-list reset case, implying when to use it (to gate a single entry). But it never states when to prefer this over the similarly named set_access_tags sibling, leaving the routing decision 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?

Adds real behavioral context beyond the annotations: it discloses the side effect of rewriting the embed code, that a snapshot with an integrity hash is built, and that the Enterprise plan is required. This is meaningful given annotations only carry destructive/idempotent flags without explaining what changes. It does not describe reversibility of un-pinning, so 4 not 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 tight sentences, front-loaded with the core action, then consequences, then the plan prerequisite. Every sentence carries distinct information with no waste.

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

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

For a mutation tool with strong annotations and no output schema, the definition covers the action, side effects, and plan gate. Missing only return/reversibility behavior, which keeps it short of a perfect score.

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

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

Schema description coverage is 100% (enabled and website_id are both documented, including the 'Omit to use primary website' default). The description adds no parameter-level detail, so the baseline 3 is appropriate per the schema-does-the-work rule.

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 real depth: 'Freeze the chat widget at its current version' plus the integrity-hash consequence. This clarifies the otherwise-ambiguous term 'pinning' precisely. It does not explicitly differentiate from siblings like update_widget_settings, so it lands at 4 rather than 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?

Provides clear context on what turning it on does ('builds that snapshot and changes the embed code') and a prerequisite ('Needs the Enterprise plan'). There are no explicit when-not-use conditions or named alternatives (e.g. vs update_widget_settings), so it stops short of 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, openWorldHint=true and readOnlyHint=false, so the safety profile is carried structurally. The description adds useful semantics that a visitor in that language sees this instead of the default, but it never explains the destructive aspect (that existing custom wording is overwritten) or what happens to omitted fields.

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 tight sentences with zero filler, front-loaded with the action and the fields it touches, followed by the user-visible consequence. Every sentence earns its place.

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

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

For a destructive, non-read-only mutation with no output schema and full schema coverage, the definition is minimally adequate: it conveys scope and effect but omits the overwrite/partial-update behavior, permission requirements, and how website_id defaulting interacts with the change.

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 all five parameters are documented in the schema, so the schema already does the heavy lifting. The description restates the three content fields but adds no syntax, format, or defaulting behavior beyond what the schema provides, 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 (Set) plus resource (chat widget greeting, agent name, bubble text for one language), and even enumerates the three editable fields. It is clear what the tool does, though it never names or contrasts the adjacent update_widget_settings / list_widget_translations 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?

Usage is only implied: the per-language framing ("for one language") hints that this is the tool for localizing wording, and the second sentence describes the resulting effect. There is no explicit when-to-use, no exclusions, and no pointer to list_widget_translations for reading or update_widget_settings for other widget configuration.

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

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

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

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

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

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

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

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

Given three optional parameters and no output schema, the description covers the essential behavior, monitoring approach, and constraint (cap). It does not mention return values, but that is acceptable given no output schema exists.

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

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

Schema descriptions already cover each parameter (max_pages, start_url, website_id). The tool description reinforces the cap behavior but does not add substantially new semantics beyond what the schema provides.

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

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

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

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

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

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

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description reinforces this by explaining the AI is stopped. It adds valuable extra context beyond annotations: the visitor is notified a person joined (a visible side effect) and the Standard plan requirement. It stops short of disclosing what happens to in-flight AI processing or the response shape.

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 with the core action front-loaded, followed by the visitor-side effect, the workflow sequence, and the plan gate. No filler; every sentence carries actionable content.

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 action tool with no output schema, the description covers the action, the user-visible side effect, the follow-up workflow, and the eligibility constraint. An agent has everything needed to call it correctly.

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

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

A single required session_id with 100% schema description coverage pointing to list_active_sessions, so the schema fully documents the parameter. The description adds no parameter-level detail, 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?

States a specific verb (stop) plus resource and actor switch: stop the AI answering a conversation so a human can reply. It clearly distinguishes itself from workflow siblings like send_agent_reply and release_conversation by describing its distinct role.

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 sequencing: use send_agent_reply afterwards and release_conversation when done, plus an eligibility gate (Standard plan or higher). The when-to-use and follow-on alternatives are named, leaving nothing 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 carry destructiveHint=true and openWorldHint=true, but the description adds the crucial context that the change affects how the live chatbot answers every visitor and overwrites existing text — that user-facing impact is not derivable from the annotations alone. It stops short of mentioning permissions or reversibility, so it is strong but not exhaustive.

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 impact, then the safety workflow. No redundant restatement of the title or 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?

For a two-parameter, fully-documented mutation tool with no output schema, the description covers the destructive overwrite, the live business impact, and the read-then-confirm workflow. Nothing needed to call 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 description coverage is 100%, so both parameters (website_id fallback to primary website, full instructions text) are already fully documented in the schema. The description adds no syntax or format detail beyond 'new text', 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 ('Replace one website's AI instructions with new text') and scopes it to a single website, which cleanly separates it from read-oriented siblings like get_ai_instructions and list_websites. The overwrite semantics are made 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?

Gives an explicit prerequisite workflow: read with get_ai_instructions first, and show the user the diff before calling. This names the alternative tool and the condition that governs the sequence, so an agent knows exactly when and how to invoke it.

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

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

Annotations already declare destructiveHint/readOnlyHint/idempotentHint/openWorldHint, so the bar is lower, and the description still adds real context: plan-gated refusal with the required plan named, and the blast radius ('change how the live chatbot behaves for every visitor'). Auth requirements and merge-vs-replace semantics are not stated, keeping it below 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 action, then the prerequisite, then the failure mode, then the impact. No sentence is redundant with the title or 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?

For a mutation tool with no output schema, it covers scope, prerequisite, failure mode, and effect on production traffic, which is enough to call it safely. Minor gaps remain around validation failures for unknown field names and whether changes take effect immediately.

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, and the description goes beyond the schema by explaining the shape of the nested object ('an object of field name to value') and naming example fields that the schema does not enumerate. It still does not describe the website_id fallback behavior, which the schema does.

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 pair and resource ('Turn website features on or off and set their values') with concrete examples (Real-Time Data Feed URL, PII Redaction rules), which clearly distinguishes it from the read-side sibling get_website_features.

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 prerequisite and routes the agent to the alternative reader ('read them with get_website_features first'), plus the condition under which the call is rejected (feature not in plan). It does not spell out when-not to use it, but the workflow ordering 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?

Adds substantial behavior beyond the annotations: changes take effect live for every visitor, plan-gated settings are refused with the required plan, and the write is atomic ('nothing is written unless every value is valid'). These are exactly the destructive/idempotency implications an agent needs and are not derivable from destructiveHint/idempotentHint alone.

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 action, then the input shape, then the two behavioral constraints that matter most (live effect, atomic validation). 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?

Given a mutation tool with a nested-object parameter and no output schema, the description covers effect scope, validation, and plan gating well. It does not describe what a successful call returns or how partial/invalid keys are reported beyond the refusal behavior, leaving 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?

Schema coverage is 100%, so both parameters are already documented in the schema. The description restates the object-of-name-to-value shape and adds the atomicity guarantee, but provides no syntax or key specifics beyond the schema itself, so the baseline 3 is appropriate.

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

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

Starts with a specific verb+resource ('Change one or more chat widget settings') and immediately names the read counterpart it pairs with ('read them with get_widget_settings'). An agent can distinguish this mutation tool from its sibling read tool without opening either 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?

Gives an explicit prerequisite ('read them with get_widget_settings first'), which is real usage guidance. It stops short of stating when not to use it or naming competing alternatives, so it falls short of a full 5.

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