Wayfront

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

The description's 'List' wording aligns with the readOnlyHint and destructiveHint annotations, and it does not contradict them. It adds functional context about the catalog, though it does not discuss permissions or rate limits; annotations already cover the primary side-effect profile.

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

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

The description is a single, focused sentence that communicates the tool's purpose and key requirement without redundancy or unnecessary detail.

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

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

Given the lack of an output schema, mentioning the automation rules and the supported catalog gives a reasonable sense of what will be returned. It could be more explicit about output shape or filtering, but it is sufficient for a simple read/list operation.

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

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

The schema already provides clear descriptions for both parameters, including the enum action and the meaning of pipeline_id. The description reinforces that pipeline_id is required but adds little beyond the schema's existing parameter documentation.

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

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

Clearly states the tool lists a pipeline's automation rules and the supported catalog of triggers, conditions, actions, and references. The read-only intent is unambiguous and easily distinguished from the sibling automation-write tool.

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

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

Explicitly notes that pipeline_id is required for every action, which gives necessary invocation guidance. It does not explicitly mention when not to use it or contrast with automation-write, but the read-only wording and sibling name make the appropriate 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?

The description discloses important side effects (downstream writes, webhooks, Slack messages) and a restriction (status-sync-managed rules cannot be edited), going beyond the annotations' destructiveHint. This gives the agent a clear picture of consequences.

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 and well-structured, using a few short sentences. It states the core function, key requirements, and important caveats without unnecessary elaboration.

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 write tool with no output schema, the description covers the essential context: it lists supported actions, mentions the need to read the catalog, and highlights side effects and edit restrictions. It does not describe return values, but that is a minor gap for this tool type.

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 description does not add much beyond it. It reiterates that pipeline_id is required and references the 'list' catalog, but these details already exist in the parameter descriptions. The baseline for high coverage is 3, and no significant extra meaning is added.

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's function with a specific verb ('Create, update, toggle or delete') and a clear resource ('pipeline automation rules'). This distinguishes it from the sibling automation-read tool.

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

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

The description advises reading automation-read first for supported triggers/conditions/actions, giving a clear usage order. While it doesn't explicitly say 'use this when you need to modify automations', the intent is obvious and the guidance is helpful.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the specific output scope (definitions, IDs, types, options), which provides useful behavioral 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?

A single, front-loaded sentence that is entirely relevant and contains no filler. 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 read-only list tool with one parameter and no output schema, the description fully conveys what the tool does and what it returns. No critical information is missing for an agent 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?

The single parameter 'action' has 100% schema coverage with an enum description ('Action to perform.'). The description does not add any additional 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 states a clear verb ('List') and a specific resource ('client custom-field definitions'), and enumerates the exact data returned (IDs, types, options). This distinguishes it from the sibling 'client-custom-field-write' and other read 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 name and description make the use case obvious—reading custom-field definitions. While no explicit exclusions or alternative tools are named, the distinction from the write counterpart is implicit and sufficient for an agent to select it.

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

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

Openly describes modifying/clearing data and notes that file-type fields cannot be set via MCP, which is consistent with destructiveHint=true. It does not mention irreversibility, but the destructive nature is conveyed.

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 with no filler; each sentence adds necessary operational context.

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 required inputs, clear/update semantics, read-tool discovery, and a key limitation. No return-value details are provided, but no output schema exists and this is a write 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?

All parameters have descriptive schema text, and value encoding for checkboxes, dropdowns, and null-clearing is explained in detail. There is a slight inconsistency between the required array and the prose requirements, but the field-level descriptions compensate.

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?

Description states a specific action ('Set or clear') on a specific resource ('client custom-field value') and points to the read tool for discovering definitions, so its 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?

Provides usage details: required identifiers, null-clearing behavior, and the file-type-field limitation. It does not explicitly discuss alternative write tools for unsupported fields, but the guidance is clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'visible' qualifier, which implies some accounts may be hidden, but does not explain the mechanism or consequences. It does not contradict annotations.

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

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

A single sentence that is front-loaded with the core action and resource, and includes the key capabilities (filtering, sorting, pagination). No waste, 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 read-only tool with a fully described schema (6 params, nested filters, enums), the description is adequate. It does not explain return formats, but no output schema exists and the action semantics (list vs show) are implicit in parameter names and schema descriptions. The 'visible' nuance is a small 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% with detailed descriptions for all parameters, including enums, defaults, and filter field examples. The description's mention of filtering, sorting, and pagination adds no meaning beyond what the schema already provides, so it stays at baseline.

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

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

The description states the verb (list/show) and resource (client accounts) clearly, and mentions filtering, sorting, and pagination. It is specific enough to differentiate from client-write (which mutates) and client-custom-field-read (different resource), though it does not explicitly name 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?

No guidance on when to use this tool vs alternatives. The description does not mention client-write, client-custom-field-read, or other read tools, nor any conditions that would favor one over the other. The 'visible client accounts' phrase hints at a scope but is not 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?

The description mentions the welcome_email side effect but does not address the destructive implications indicated by the destructiveHint annotation. The statement 'Updating an existing client's profile is not supported' actually conflicts with the annotation that suggests destructive behavior. Important side effects like possible Stripe customer creation or other modifications are not disclosed, leaving the agent underinformed about the tool's behavior.

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

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

The description is brief and front-loaded with the main action, making it easy to scan. It contains only two sentences, which is appropriate for a simple tool. However, the inclusion of contradictory statements adds noise, slightly reducing clarity but not affecting structure.

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 complexity of the schema (17 parameters, nested objects), the description is quite sparse. It does not cover parameter relationships beyond a couple of mentions, and the output schema is absent. While the schema descriptions are rich, the tool description leaves gaps about use cases, edge cases, and side effects, making it only partially complete for a tool of this complexity.

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

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

The schema provides high coverage, but the description adds contradictory parameter guidance. It states 'Requires email' even though email is not in the schema's required list, and mentions client_id as 'Required when updating an existing record' while simultaneously saying updating is not supported. These inconsistencies undermine understanding of parameters despite the schema descriptions.

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

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

The description clearly states the primary purpose: 'Create a client account.' It also explicitly distinguishes from update operations by saying 'Updating an existing client's profile is not supported by this tool,' which helps separate it from other write tools. The verb and resource are specific and unambiguous.

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

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

The description implies when to use it (for creating a client) and explicitly says it is not for updating. However, it does not mention alternative tools (e.g., client-read for reading) or other scenarios where another write tool would be more appropriate. It gives partial guidance but not fully explicit context around alternatives.

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

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

The annotations already establish read-only and non-destructive behavior, and the description adds concrete behavioral details about list/show actions, filtering, sorting, and pagination. There is no contradiction between the description and 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 main description is a single, front-loaded sentence that states the resource, actions, and key capabilities. The longer field lists live in the schema and do not bloat the prose description.

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 adequately conveys that the tool returns coupon data and supports pagination. It does not spell out the exact response shape or error behavior, but the core context for invoking the tool is present.

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 describes all parameters, so the baseline is 3. The description adds available field lists and a filter example, but much of this repeats the schema and the 'Purity filter' phrasing is unclear, providing only marginal additional 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 identifies the tool as reading discount coupons via 'list' or 'show' actions and mentions filtering, sorting, and pagination. It does not explicitly distinguish itself from the sibling coupon-write tool, though the name and actions make the read purpose evident.

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 tool versus coupon-write or other read-oriented sibling tools. It lacks explicit context such as 'use for read-only coupon access' or 'use coupon-write for modifications.'

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

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

Annotations already indicate write and destructive behavior. The description adds useful context by explicitly warning that updates replace supplied discounts and can affect what clients pay, which goes beyond the raw schema.

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, front-loaded with the core action, and packs essential operational details into two sentences without unnecessary 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?

Despite having no output schema, the description covers the necessary context: permissions, required inputs, update behavior, and financial impact. It is sufficiently complete for an agent to decide when and how to invoke the tool.

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

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

Schema coverage is 100% and the description adds meaningful constraints not obvious from types alone, such as 'required for create', 'pass null on update to clear', percentage limits, and fixed-coupon behavior. This strongly supports correct parameter usage.

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?

Description clearly states the tool creates or updates discount coupons, distinguishing it from the read-only sibling coupon-read. The verb and resource are specific and unambiguous.

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

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

Mentions required coupon permission, creation requirements (unique code, type, discounts), and warns that updates replace discount collections. It does not explicitly say 'use coupon-read for retrieval', but the create/update framing makes the intended usage 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 declare readOnlyHint true and destructiveHint false, and the description 'List or show' is consistent with no side effects. There is no contradiction, though the description adds no additional behavioral 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 a single clear sentence, and parameter descriptions are concise without redundant fluff. No unnecessary text is present.

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 tool, the description adequately covers actions and parameter usage, including defaults and action-specific requirements. There is no output schema, so return format is not needed, and the read-only annotation and sibling naming add sufficient context.

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

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

Schema description coverage is 100%, and descriptions clarify action-specific applicability, such as 'Required for show' and 'for list'. The filter description includes an example and the sort description explains the :asc/:desc syntax, adding useful meaning beyond basic 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 explicitly states the verb 'List or show' and the resource 'form folders', along with filtering, sorting, and pagination. The title 'Read Tool' distinguishes it from the sibling form-folder-write tool.

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

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

The description implies usage for read operations but does not explicitly state when to use this tool versus alternatives such as form-folder-write. The read-only annotation and sibling naming provide context, but no explicit 'use this when' guidance is given.

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?

Discloses key behavioral constraints: parent folder must match type and nesting max 5 levels. No contradiction with annotations; readOnlyHint false and destructiveHint false align with a create operation.

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

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

Three short sentences, no filler. All sentences add value.

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

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

Covers creation constraints and points to form-write for filing, enough for a simple create tool without output schema. The presence of form_folder_id for 'show' in schema while action only lists create creates minor ambiguity.

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

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

Schema covers all 6 params with descriptions; description reinforces that name/type are required for create and explains parent_id constraints. form_folder_id is described but action enum only supports create, a minor ambiguity.

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

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

Clearly states the tool creates a form folder and distinguishes it from form-write by saying filing forms goes there. Names the resource and action precisely.

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 required inputs (name, type), parent same type, and 5-level nesting limit, plus directs to form-write for filing. Could more explicitly state when to use this vs read tool, but context is strong.

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 context about the data returned ('forms and their fields and linked services') and mentions filtering/sorting/pagination. Since the annotations already declare readOnlyHint, openWorldHint, and destructiveHint, the description provides a bit more behavior insight without needing to repeat safety 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 a single concise sentence that front-loads the main purpose ('List or show forms') and follows with key details. No fluff or redundant information, making it easy to parse quickly.

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 gives a reasonable idea of what to expect (forms, fields, linked services) and mentions list capabilities. Since there is no output schema, the description provides enough context for an agent to understand the tool's scope, though it lacks details on the response structure or difference between list/show responses.

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 descriptions for all parameters (100% coverage per context), including detailed examples for sort and filters. The tool description itself does not add extra meaning beyond the schema, but the schema is already clear, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'List or show forms and their fields and linked services.' It uses specific verbs (list/show) and identifies the resource (forms), making it easy to distinguish from write tools like form-write.

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

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

The description mentions that 'Lists support filtering, sorting and pagination,' giving some usage guidance for the list action. However, it does not explicitly state when to use this tool versus alternatives (e.g., form-write for modifications) or provide conditions for when not to use it.

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

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

Clearly discloses destructive behavior: 'Updating fields replaces the full list and deletes omitted fields; preserve existing field IDs.' Also notes 'Field edits are blocked for forms with white-labeled services.' These details go beyond the annotations (destructiveHint) by explaining exactly what happens, making behavior fully transparent.

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 five sentences, with the primary purpose stated first ('Create or update forms.'). Each subsequent sentence adds a distinct, necessary detail without redundancy or 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?

For a tool with 11 parameters and nested field objects, the description covers key behavioral rules (replacement/deletion semantics, form-type requirements, white-label blocking) while relying on the fully covered schema for parameter details. It provides sufficient context for correct invocation without over-explaining.

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 all 11 parameters, so baseline is 3. The description adds cross-parameter semantics such as 'Creation requires type, name and the full initial fields list' (conditional requirements) and 'Order/contact forms require email' (domain rules not obvious from individual parameter descriptions), providing additional meaning 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 opens with 'Create or update forms,' which clearly names the verb and resource. It distinguishes this write tool from siblings like form-read and form-folder-write by focusing on form creation/update operations.

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

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

Provides usage guidance such as 'Creation requires type, name and the full initial fields list' and 'Omit fields to change form settings only.' It also notes domain rules like order forms requiring a service-bearing field. However, it does not explicitly state when not to use this tool versus alternatives, though the context makes it inferable.

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?

While annotations already indicate read-only and non-destructive behavior, the description adds transparency by specifying what is returned (canonical source URL and bounded document content), which is not covered by annotations.

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

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

The description is concise, using two sentences to convey the action, the input, and the output. No unnecessary details 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 provides the key contextual details: the source of the ID, the action, and the return type. It could be slightly more explicit about what 'bounded document content' entails (e.g., size limits or format), but it is sufficient 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 single parameter document_id is well described as an ID returned by search-wayfront-docs, with a warning not to guess IDs. This fully covers the parameter's meaning and source.

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 (retrieve) and the resource (Wayfront help-center document), and distinguishes it from the related search tool by specifying that it uses a document_id from search-wayfront-docs.

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 'using a document_id returned by search-wayfront-docs' implies the correct workflow (search first, then retrieve), providing context on when to use this tool. However, it does not explicitly name alternatives or state when not to use it, but the guidance is sufficient.

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 and destructiveHint=false, covering safety. The description's 'Query invoices' and 'get a single invoice' are consistent with read-only behavior and add no contradictions. It doesn't mention auth or rate limits, but with annotations present, the bar is lower and no extra context is strictly required.

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

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

The description is extremely concise—two sentences—with the main purpose front-loaded ('Query invoices') followed by action breakdowns. It avoids redundancy and fluff, making it easy to parse quickly.

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

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

For a query tool with no output schema, the description adequately covers the main operations and required inputs. It doesn't detail return formats or error handling, but these are less critical for a straightforward read-only tool. Given the complexity (nested filter objects and many sort fields), a bit more context on expected output could improve completeness, but it's sufficient as is.

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 with descriptions for all parameters, so the baseline is 3. The tool description adds a bit of context (e.g., invoice_id is required for 'show'), but it mostly echoes the schema's parameter descriptions without significant extra semantic value beyond what's already provided.

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: 'Query invoices' and then defines two specific actions ('list' for querying with filtering/sorting/pagination, 'show' for fetching a single invoice by ID). This makes the resource and operations unambiguous, and it distinguishes itself from other tools by focusing strictly on invoice queries.

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: use this tool when you need to query invoices or retrieve a specific invoice. There are no alternative invoice tools among siblings, so explicit 'when not to use' guidance isn't necessary. However, it doesn't explicitly state alternatives or scenarios, slightly missing the 'explicit' bar.

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 and destructiveHint=false, and the description is consistent with a read-only listing operation. The description adds no additional behavioral details beyond what the annotations 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 concise and efficiently communicates the tool's purpose and key capabilities without unnecessary detail.

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

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

The description provides enough context for invoking a list operation, including filter and sort field lists. It does not describe the return shape, but for a straightforward list operation this is not a significant omission.

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

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

All parameters have descriptions, and the filter parameter includes an example and a list of available fields. The sort parameter also enumerates valid fields. This goes beyond basic schema coverage and helps clarify how to construct queries.

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: listing logs. It identifies the resource ('logs') and the action ('list'), and distinguishes it from sibling tools by the specific log-domain focus.

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 usage context by explaining that the tool supports filtering, sorting, and pagination for log queries. It does not explicitly compare to alternatives, but the purpose is clear enough for an agent to know when to invoke it.

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

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

The annotations already establish readOnlyHint and destructiveHint, so the bar is lower. The description adds a meaningful behavioral prerequisite ('for a visible order') and confirms no side effects beyond listing, complementing the annotations without contradiction.

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

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

The description is two sentences, front-loaded with the primary purpose, and each sentence contributes useful context (what it lists and that order_number is required). No redundant or extraneous wording.

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

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

Given the absence of an output schema, the description hints at response content via 'including whether each message is staff-only'. It covers the essential usage context (visible order, required parameter, supported operations) though it does not specify return format or error behavior, which is acceptable for a read-only 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 descriptions cover all parameters (100% coverage), including detailed explanations for 'sort' and 'filters'. The tool description merely reiterates 'supports filtering, sorting and pagination' without adding beyond the schema, so it meets the baseline but does not elevate it.

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 operation ('List messages'), the resource ('for a visible order'), and includes a distinguishing detail ('including whether each message is staff-only'). It is specific and readily distinguished from sibling tools like order-message-write or ticket-message-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?

The description implies when to use the tool (reading order messages) but does not explicitly contrast it with alternatives such as order-read or ticket-message-read. It provides operational constraints ('Requires order_number') but lacks explicit when-not guidance.

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

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

The description goes beyond the annotations by warning that sent messages cannot be recalled and that the normal notification, webhook, and broadcast pipeline will run. This makes side effects and irreversibility explicit.

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 and well-structured: three sentences cover purpose, requirements, defaults, side effects, and irreversibility without unnecessary filler or repetition.

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

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

For a simple write tool with no output schema and no nested objects, the description includes the necessary purpose, inputs, defaults, and side effects. It does not address error conditions or return behavior, but these are not critical given the tool's simplicity.

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

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

The schema already covers all four parameters with descriptions, and the tool description adds meaningful context around order_number, message, and staff_only behavior. It does not add validation details, but the provided semantics are sufficient for basic usage.

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: 'Post a message to an order.' It identifies the resource, the operation, and the required inputs, leaving no ambiguity about the tool's primary 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?

It provides practical usage details such as requiring order_number and message, the staff_only default, and the client-notification behavior when set to false. It does not explicitly contrast with read-only alternatives, but the write-oriented purpose is clear enough.

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

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

The phrase 'visible orders' hints at permission-based visibility, but this is vague and does not clearly disclose behavioral implications. The annotations already cover read-only and non-destructive behavior, so the description adds little beyond that.

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

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

The description is concise and well-structured, stating the core function in a single sentence without unnecessary detail or repetition. It is immediately scannable and easy to understand.

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?

While the schema provides extensive technical details, the description alone is insufficient for an agent to use the tool effectively. It does not explain how to specify the action, what 'visible' entails, or provide examples. However, given the schema's completeness, the description meets a minimal threshold.

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 comprehensive (100% coverage), including detailed explanations for filters, sorting, and the action enum. The description itself adds no extra parameter semantics, 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 with a specific verb ('List or show'), a resource ('orders'), and additional capabilities (filtering, sorting, pagination). It distinguishes this as a read operation without 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?

The description provides no explicit guidance on when to use this tool versus alternatives (e.g., order-write or other read tools). It does not mention the 'action' parameter's role or when to choose 'list' over 'show', leaving the agent to infer usage from the schema.

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 and destructiveHint=false. The description adds the nuance of 'visible tasks,' implying some tasks may be hidden, which is not covered by annotations. It also mentions filtering, sorting, and pagination, giving behavioral context beyond the safety profile. No contradictions.

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

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

One concise sentence with the core purpose front-loaded. Zero waste. 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 simple read-only nature and the rich schema covering all params, the description is sufficient. It lacks explicit return format details, but with no output schema and the tool being a list operation, the expected response is clear from context. The 'visible' filter is a minor behavioral note not fully elaborated but acceptable.

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 all parameters are documented with descriptions. The description's mention of 'filtering, sorting and pagination' maps to existing params but adds no new meaning. Baseline 3 is appropriate since the schema carries the semantic weight.

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?

Description states a specific verb ('List') and resource ('tasks for an order'), clearly distinguishing it from sibling tools like order-read (orders) and order-task-write (writes). The word 'visible' adds precision. 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?

Description clearly indicates when to use it (to list tasks for an order) and requires order_number. It does not explicitly mention alternatives or when not to use, but the tool name and purpose make the context obvious. No misleading exclusions.

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

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

The description discloses important side effects beyond the destructiveHint annotation, including assignment replacement, workflow reset behavior, bulk action effects, client email notifications, and HTML sanitization needs. This exceeds the baseline set 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 dense but well-organized, front-loading the purpose and then systematically covering action rules, parameter semantics, and warnings. Every sentence adds necessary information without 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 complex write operation with 11 parameters and no output schema, the description covers all critical behaviors, edge cases, and side effects. It is complete enough for an agent to use the tool safely and 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?

Although the schema already describes each parameter, the description adds crucial cross-parameter semantics like mutual exclusivity between for_client and employee_ids, precedence of deadline over due_at, and the meaning of omitting task_id. This goes well 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 actions ('Create, update, delete, complete or reopen order tasks') with a specific resource and verb. It is easily distinguished from siblings like order-task-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?

The description gives detailed action-specific requirements, such as task_id for update/delete and optional task_id for complete/reopen. It does not explicitly name alternative tools to avoid, but the context is clear enough for correct 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 discloses that collection fields replace complete lists and that omitted fields remain unchanged, and that changes can notify clients and trigger integrations. This goes beyond the annotations, which only indicate destructiveHint. It does not explicitly warn about irreversible data loss, but the replace language is explicit enough.

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

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

The description is two sentences, front-loaded with the action and target, followed by crucial behavioral notes. No redundant or irrelevant content. Efficient and clear.

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

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

For a tool with 14 parameters and nested objects, the description gives key operational context: update semantics, replace behavior, and side effects. It does not cover every edge case (e.g., required order_number), but those are in the parameter schema. The description is sufficient for an agent to understand the tool's role and basic constraints.

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 each parameter (e.g., 'Replaces current tags when provided', 'Empty values delete that metadata key'). The main description adds little beyond a high-level summary of field categories. It does not introduce new parameter-specific information that isn't already in the schema.

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

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

The description clearly states that the tool updates an order's various fields (status, dates, notes, service, assignments, tags, metadata, linked orders), and distinguishes it from read-only tools. The name and action enum reinforce the write/update purpose. It is specific and unambiguous.

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

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

The description implies when to use it (when updating an existing order) but does not explicitly contrast with alternative tools like order-read. However, the update semantics and mention of side effects (notifications/integrations) provide sufficient guidance. It could be more explicit about not using it for read-only operations, but the name and annotation cover that.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the word 'accessible', implying permission-scoped results, and clarifies allowed item types in filters. These are useful but modest additions; it does not disclose return format or pagination behavior beyond what schema provides.

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

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

A single sentence conveys the core purpose and the most important filter nuance. It is front-loaded with the verb and resource, and every phrase earns its place with no 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 tool has 6 parameters and a nested filters object, but the schema is rich enough to carry most details. The description omits the distinction between list and show and the requirement for pipeline_item_id in show, both of which are in the schema. Given no output schema, some return-format guidance could help, but the description is adequate 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?

Schema description coverage is 100%, so parameters are already documented. The description adds one meaningful detail: that item types in filters accept user, company, or order, which clarifies the filter values for itemable_type. This is a small increment over the schema, keeping it at baseline 3.

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 ('List or show accessible pipeline cards') and mentions key capabilities (filtering, sorting, pagination). It does not explicitly distinguish itself from sibling read tools like pipeline-read, but the name and phrasing make the target resource 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?

No guidance on when to use this tool versus alternatives. It does not mention pipeline-item-write for mutations or pipeline-read for pipeline-level reads. The description implies a read operation but offers no exclusions or alternate routes.

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 and destructiveHint=true, so the description correctly implies mutation and potential destruction. It adds a useful side-effect disclosure: 'Changes can trigger configured automations,' which is beyond what annotations convey. It does not detail consequences of removal, but the destructive hint covers that baseline.

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

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

The description is three sentences, each earning its place. The first sentence states the core actions, the second details parameter requirements per action, and the third covers pipeline type constraints and side effects. No wasted words, and the most critical information (the actions) 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?

Given the tool has three distinct actions with different parameter requirements, the description is complete: it specifies what is required for each action, which entity types are valid for which pipelines, and warns about automation side effects. No output schema exists, so return format is not expected. It covers all necessary information for an agent to call this 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?

Schema coverage is 100% so each parameter has a basic description. The tool description adds value by grouping parameters by action, clarifying that itemable_ref differs by type (order number vs id), and noting that aliases are accepted for list filters (though this is a write tool, it's still informative). This goes beyond the schema's isolated parameter descriptions.

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

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

The description states the tool's purpose with a specific verb and resource: 'Add, remove or move pipeline cards.' This clearly distinguishes it from sibling tools like pipeline-item-read (read-only) and pipeline-write (likely pipeline configuration). The actions are enumerated, leaving no ambiguity about what the tool does.

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

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

The description provides explicit per-action parameter requirements: 'add requires pipeline_id, stage_id, itemable_type and itemable_ref; remove requires pipeline_item_id; move requires pipeline_item_id and stage_id.' It also clarifies which entity types are valid for sales vs production pipelines, guiding parameter selection. It does not explicitly name alternatives, but the context makes it the obvious write counterpart to pipeline-item-read.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is not burdened with safety disclosure. It adds useful behavioral context by noting 'accessible' pipelines (permission filtering) and that lists support filtering/sorting/pagination. This goes beyond the annotations without contradicting 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?

Two concise sentences with no filler. The purpose is stated first, followed by a summary of list behavior. 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 read-only tool with full schema coverage and safety annotations, the description is adequate. However, it lacks details on the return format (no output schema) and does not clarify what 'show' returns versus 'list'. The absence of output schema info leaves the agent guessing about response shape, which 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?

Schema description coverage is 100%, so all six parameters already have clear definitions. The description summarizes list capabilities but does not add meaning beyond the schema. Since the schema handles parameter documentation, the baseline 3 is appropriate.

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

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

The description states a specific verb ('List or show') and a clear resource ('accessible sales or production pipelines and their stages'), and distinguishes between the two actions. It is unambiguous and differentiates the read tool from its write counterpart by its name and content.

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 pipelines but does not explicitly state when to use this tool over alternatives (e.g., pipeline-write for modifications). It mentions list capabilities (filtering, sorting, pagination) but offers no explicit when-not-to-use or guidance for choosing between 'list' and 'show' beyond the schema.

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 a key side effect: omitted stages are preserved and never deleted, and explicitly routes card changes elsewhere. It does not contradict the destructiveHint annotation, though it does not elaborate on other potential destructive effects or result/error 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 three compact sentences, front-loaded with the main purpose, and avoids repeating detailed field descriptions already covered by 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?

For a 9-parameter write tool with nested stages, the description covers the most important behavioral context: create requirements, update semantics, stage preservation, and scope separation from pipeline-item-write. It is complete enough for normal use, though it does not touch on return values or failure modes.

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 description adds meaningful cross-parameter semantics not present in the schema alone: creation requires type/name/stages, pipeline_id is required for updates, stage id presence means edit vs add, and omitted stages are preserved. This significantly clarifies the nested stage behavior.

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 specific verb-resource pair, 'Create or update pipeline structure', and clarifies that cards belong to a separate tool, distinguishing it from pipeline-item-write. The create/update action 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?

It states when creation is needed (requires type, name, stages), how updates affect stages, and redirects card management to pipeline-item-write. It does not explicitly contrast with pipeline-read, but the write purpose is clear enough.

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

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

Annotations already declare read-only and non-destructive behavior. Description adds that it returns excerpts, source links, and document IDs, which is consistent and provides useful output expectations.

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 efficiently cover purpose, usage scenarios, and output format. No fluff or redundant information.

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

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

For a simple search tool with two parameters and no output schema, the description is complete: it communicates what it searches, why to use it, and what it returns, making it self-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?

Schema descriptions fully cover both parameters: query as a natural-language question, limit with default and max. The description adds no extra parameter details beyond the schema, so baseline 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?

Clearly states the verb 'Search' and resource 'customer-facing Wayfront help-center documentation'. Distinguishes from sibling get-wayfront-doc by noting document IDs are returned for that tool.

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

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

Lists specific use cases (product setup, workflows, behavior, limitations, handoffs) and implies the companion tool for retrieval. Could be more explicit about when not to use, but the given topics are sufficient for typical 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 is consistent with the readOnlyHint and destructiveHint annotations; it only describes read operations and does not imply side effects. It does not add extra behavioral details like auth or rate limits, but the annotations already cover the core read-only nature.

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

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

The description is one concise sentence that enumerates the valid actions and highlights the key list capability. It avoids unnecessary prose and front-loads the main purpose.

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

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

Given the lack of an output schema, the description covers the main operations and the list capabilities. It could be slightly more explicit about the differing outputs of 'show' vs 'get_task_templates', but the action enum and parameter descriptions fill most gaps.

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

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

The schema provides detailed descriptions for most parameters, including the action enum, filter example, and sortable fields. The description adds little beyond those schema details, and the phrase 'Purity filter object' appears to be a typo that could slightly confuse, though the example mitigates it.

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 three read actions ('list', 'show', 'get_task_templates') and the resource type (services). It is readily distinguishable from the sibling service-write tool.

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

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

The description notes that list supports filtering, sorting, and pagination, but it does not explicitly say when to use this read tool versus the sibling service-write alternative. Action-specific requirements are left to the parameter descriptions rather than stated as usage guidance.

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

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

The description clearly warns that sync_task_templates overwrites and deletes omitted templates, that relationship collections replace full lists, and that pricing/recurrence changes affect future delivery. This goes beyond the destructiveHint annotation by specifying exactly which operations are destructive and how to avoid unintended deletions.

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 main description is front-loaded with key warnings, and parameter descriptions are dense but relevant. The overall length is justified by 28 parameters, with minimal fluff, though a few descriptions restate information already implied by the parameter name or type.

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

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

The description covers conditional fields, required-vs-optional behavior for create and update, destructive semantics, unit conversions, and relationship replacement rules. Even without an output schema, an agent has enough context to invoke the tool correctly and avoid common mistakes.

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?

Every parameter is described, and many descriptions add crucial semantics not inferable from the schema alone, such as deadline being in hours, recurring enum meanings, conditional requirements for recurring=2, folder_id null-versus-omitted behavior, and the full-replacement behavior of task_templates. This far exceeds the baseline expected from 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 that the tool creates or updates services and syncs task templates, clearly identifying the resource and actions. It also distinguishes itself from read-oriented tools by instructing the agent to fetch task templates before syncing, making selection 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 concrete usage rules: call get_task_templates before sync_task_templates and retain IDs to avoid deletion, convert deadlines to hours, and understand that relationship collections replace full lists. It could more explicitly contrast with service-read for ordinary reads, but the write-versus-read distinction is clear enough.

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

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

Annotations already indicate read-only, non-destructive, and non-open-world behavior. The description adds no further side-effect or behavioral detail beyond the obvious 'View' action, so it meets but does not exceed the baseline.

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 filler, redundant wording, or unnecessary detail. It is well-structured and immediately understandable.

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 no output schema, the description gives enough context about what is being viewed. It could slightly improve by mentioning that no other actions are supported, but the enum already conveys this.

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 only parameter 'action' has full schema coverage with an enum of ['view'] and a generic description. The tool description adds no additional semantic detail beyond what the schema already makes clear.

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?

Description clearly states the tool's function with a specific verb ('View') and resource ('current workspace branding and settings'), and it is easily distinguished from the sibling 'settings-write' tool.

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

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

The description implies read-only usage but does not explicitly state when to prefer this tool over alternatives such as 'settings-write' or 'workspace-info'. No direct when-to-use or when-not-to-use guidance is provided.

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

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

The annotations already indicate destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate mutation. It adds useful constraints about logo URLs and excluded actions, but does not detail potential overwrite or irreversible side effects. No contradiction with annotations.

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

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

The description is a single concise sentence that lists the affected fields and includes important constraints and exclusions without unnecessary detail or repetition.

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

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

Given the simple update semantics and full schema parameter descriptions, the description provides enough context for an agent to invoke the tool correctly. It includes practical exclusions and URL constraints; a return-value description is not necessary since no output schema is declared.

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

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

The schema already covers 100% of parameters with examples and constraints, so the baseline is 3. The description reinforces the logo URL requirement and adds exclusion context, but does not significantly extend the parameter-level meaning beyond what the schema provides.

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

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

The description uses the specific verb 'Update' and enumerates the exact workspace settings affected (name, colors, timezone, contact link, currency, business information, email sender name, logos). This clearly distinguishes it from the sibling settings-read tool.

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

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

The description clearly implies this tool is for modifying workspace settings, and explicitly lists what it does not do (connect Stripe, set custom domain/sending email, switch live mode). This gives useful exclusionary guidance, though it does not explicitly say 'use settings-read to view settings'.

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 aligns with readOnlyHint and destructiveHint annotations, confirming no side effects. It does not add details about return format or error conditions, but the annotations already cover the key behavioral aspects.

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 immediately conveys the tool's purpose with no unnecessary verbiage. It is optimally concise.

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

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

The description is adequate for a simple read operation. It specifies the subject (notification settings and events) and the scope (already-connected Slack workspace). Absence of an output schema is acceptable given the tool's simplicity, though it could clarify the exact return payload.

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 only parameter 'action' has an enum of ['view'] with a generic description 'Action to perform.' While the schema fully specifies the allowed value, the description adds minimal context beyond what is already evident from the enum.

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: viewing notification settings and available events for a connected Slack workspace. It distinguishes it from the sibling slack-write tool by focusing on read-only actions.

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

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

The description implies usage for read-only inspection of Slack configuration. It does not explicitly state when to avoid using it, but the read-only nature is obvious from the verb 'view' and the annotation, making it sufficient for typical use.

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 and destructiveHint=true, so the mutating nature is known. The description adds valuable behavioral context beyond that: it specifies the partial update semantics (only listed events change) and the dependency on connection/licensing, which are not captured in annotations. This helps an agent anticipate side effects and failure conditions.

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

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

The description is three concise sentences: purpose, behavior, and prerequisite. It is front-loaded with the main action, then clarifies scope and requirements. Every sentence earns its place 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 write tool with two parameters (one required) and no output schema, the description covers the essential aspects: what it updates, how partial updates work, and prerequisites. It does not mention error handling or post-update confirmation, but those are not typically required for a mutation tool. The annotations already signal destructiveness, so nothing critical 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 the schema fully documents both 'action' and 'events' (including nested event fields). The description does not add new parameter-level meaning; it only reiterates the partial update behavior that the schema already hints at via the events description. Baseline 3 is appropriate given full schema coverage.

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

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

The description clearly states the verb 'Update' and the resource 'notification events and channels' for an already-connected Slack workspace, making its purpose unambiguous. It also adds the partial-update behavior ('Only listed events change; others remain unchanged') which distinguishes it from a full overwrite and implicitly from the read sibling.

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

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

It provides clear context for when to use the tool (updating Slack notifications for a connected workspace) and prerequisites (Slack must be connected and licensed, connecting requires the Wayfront interface). It does not explicitly name alternatives like slack-read, but the context is sufficient for an agent to infer when to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the action breakdown (list vs show) but does not disclose additional behavioral traits such as return format, pagination details, or any side effects. It does not contradict the annotations, but the added value 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 two sentences with no redundancy. The purpose is front-loaded, and the action breakdown is immediately useful. Every word earns its place, making it an exemplar of conciseness.

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

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

Given the tool has six parameters and nested objects but no output schema, the description is adequate but thin. It does not describe the response shape, pagination behavior beyond schema defaults, or any constraints on usage. The schema covers parameter details, but the description leaves return-value expectations implicit, which is acceptable for a read-only tool but not fully complete.

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

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

The input schema has 100% description coverage, including detailed parameter explanations (e.g., sort fields, filters object example, defaults). The description adds no parameter-specific meaning beyond what the schema already provides, so it meets the baseline for full schema coverage.

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

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

The description clearly states the verb 'query' with the resource 'subscriptions' and distinguishes the two actions: 'list' for filtered/sorted/paginated queries and 'show' for a single subscription by ID. This is specific and unambiguous, leaving no doubt about what the tool does.

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

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

The description implies usage through the action names: use 'list' for multiple subscriptions with filtering, 'show' for one by ID. However, it does not explicitly state when to use this tool over alternatives or provide exclusions. Since it is the only subscription-specific tool among siblings, the context is clear, but the guidance is not 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 readOnlyHint and destructiveHint annotations already communicate safety, and the description is consistent with them. However, the description adds little beyond the annotation, such as pagination, ordering, or error 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 clear sentence that is immediately understandable and front-loaded with the primary action and resource.

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 no output schema, the description adequately states what is returned (tags and IDs). It is complete enough for basic usage, though it omits potential details like ordering or filtering.

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

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

The schema covers the single parameter with an enum and description, so coverage is high. The tool description reinforces that 'action' is 'list', but it does not add substantial parameter-specific meaning beyond the schema.

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

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

The description clearly states the action ('List'), the resource ('workspace tags'), and the expected output ('their IDs'). It is specific and easily distinguished from sibling tools like tag-write.

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 usage by saying 'List', and the annotation reinforces this, but it does not explicitly mention when to use this tool versus alternatives such as tag-write.

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?

Read-only and destructive hints are already provided by annotations, so the description only needs to add context. It proactively mentions the required permission and the fact that this is a create operation, which is useful behavioral information.

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 with no redundant or filler content. It front-loads the primary purpose and then provides key usage details efficiently.

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

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

The description is adequate for the simple create operation and covers permission and key parameters. It does not describe return values, but no output schema is present and this is not essential for deciding when or how to call the 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?

Every parameter has a schema description, and the tool description adds practical meaning: name is required for creation, sort_order is optional and controls display order, and action is fixed to 'create'. This clarifies how to actually invoke the tool.

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 creates a workspace tag, using a specific verb and resource. This distinguishes it from tag-read and other write tools for different resources.

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 specifies required inputs (name) and the required permission (tag-management). It does not explicitly differentiate from tag-read, but the create action and resource make the primary use case 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?

Describes side effects for each action: 'emails them their login' for create, 'changes their permissions' for update, and 'creates a new permission set' for create_role. It also mentions the constraint that roles cannot exceed your own permissions. While it doesn't dwell on potential destructive consequences, the actions are inherently non-destructive (no delete) and the description covers the key impacts. No contradiction with the destructiveHint annotation.

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

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

The description is compact, using three sentences to cover all actions and key constraints. While it could be formatted with bullet points for clarity, it remains efficient and avoids redundancy. No filler or unnecessary 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?

Provides sufficient context for correct usage: it identifies the three actions, points to the team query tool for reading and role IDs, states admin/owner restrictions, and clarifies the welcome email default. Given the tool's complexity (40 parameters), the description covers the essential operational context without needing to explain every permission field.

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% — every parameter has a description with relevant 'For "action"' qualifiers. The description text adds no extra parameter-level detail beyond what the schema already provides, but it does reinforce the role_id lookup via the team query tool. Baseline 3 applies because schema fully covers parameter semantics.

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

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

Clearly states the tool's purpose ('Manage team members and roles') and enumerates the three distinct actions (create, update, create_role) with specific verbs. It also distinguishes itself from the read side by noting that reading team members belongs in the team query tool.

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

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

Provides explicit guidance on when to use this tool versus alternatives: reading team members is delegated to the team query tool, and role IDs are to be discovered via that query tool. Also states usage restrictions (admin-only for create_role, workspace-owner-only for admin accounts) and notes the welcome_email default.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no behavioral detail beyond what the schema already exposes (action enum). It does not disclose any rate limits, permissions, or response characteristics beyond the read-only nature, which is already known from annotations.

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

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

Two sentences with zero wasted words. The core purpose is front-loaded, and the action breakdown is immediately clear. Structure is exemplary.

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 tool with complete schema documentation and no output schema, the description covers the two actions and their parameter associations sufficiently. It could mention that it is the read-only counterpart to team-management-tool, but that is not essential for correct invocation. Overall, the agent has enough to call 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?

Schema coverage is 100%, so the baseline is 3. The description adds a high-level mapping: 'filtering, sorting, pagination' aligns with filters, sort, page, and limit; 'get a single team member by user ID' aligns with user_id. However, this is mostly a paraphrase of the schema descriptions and adds little new 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 states a specific verb ('Query') and resource ('team members'), and immediately distinguishes two actions with distinct purposes ('list' with filtering/sorting/pagination, 'show' with user ID lookup). This clearly identifies the tool's function and separates it from write-oriented siblings like team-management-tool.

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

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention team-management-tool or any other sibling, nor does it provide exclusions or conditions. The agent must infer from the action names and 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?

The description is consistent with the readOnlyHint annotation and clearly states that it lists templates or returns full source, implying no destructive behavior. It adds useful context about the template type and source exposure, though it does not mention potential output size or permissions.

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 efficiently conveys both capabilities and optional filters. There is no redundant wording or unnecessary detail.

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

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

For a read-only tool with no output schema, the description gives enough context about what actions are available and what the 'show' action returns. It does not describe the list output format in detail, but the purpose is clear and the parameter schema fills most remaining gaps.

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

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

The input schema already covers all parameters with clear descriptions, and the tool description restates the action-based filtering and show behavior. Since schema coverage is 100%, the description adds moderate context but does not significantly deepen parameter meaning beyond what is already provided.

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 resource as workspace Twig templates and states the two supported actions: listing and showing full source. It does not explicitly differentiate itself from template-write or other read tools, but the action set and resource are specific enough.

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 filtering and the show action, but it does not say when to prefer this tool over sibling tools such as template-write or other read tools. There is no explicit 'use this for read-only operations' guidance in the description itself.

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

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

The description clearly discloses destructive behavior by stating that reset permanently deletes a custom page and that no version history exists. It also notes validation behavior (invalid Twig syntax rejected), consistent with the destructiveHint annotation.

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

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

The description is compact and front-loaded, stating the core purpose first and then adding necessary warnings and usage guidance in four sentences. Every sentence contributes operational or safety-relevant information.

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

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

Given the destructive action and lack of an output schema, the description provides the essential context: intended use, required read-before-write flow, reset consequences, syntax validation, and absence of version history. It is complete enough for an agent to invoke the tool safely.

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 coverage of all parameters with detailed descriptions, including action enum semantics, data as full replacement source, template_name requirements, and is_active behavior. The description text itself does not add additional parameter-level meaning beyond that 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 updates or resets workspace Twig templates used by client pages and emails, making its purpose and resource type explicit. It also distinguishes itself from template-read and other write tools by naming update and reset actions.

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

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

It gives explicit instructions to read template-read first before updating to preserve intended content, and explains when to use update versus reset. It also warns that resetting a custom page permanently deletes it and that invalid Twig syntax is rejected.

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 mark the tool as read-only and non-destructive, and the description aligns by saying 'List' rather than modify. It adds behavioral context by noting the 'visible' ticket requirement and that the response includes staff-only status.

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 the main action front-loaded. It avoids redundant wording and includes only the most important usage constraints.

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 helpfully mentions that staff-only status is returned. It covers required input and supported operations, though it does not describe error cases or return shape beyond that one field.

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

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

Schema descriptions cover 100% of parameters with useful detail, including the filter object format and sort field list. The tool description reinforces that ticket_number is required and that filtering/sorting/pagination are supported, but it does not add meaning 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 opens with a specific verb 'List' and identifies the resource as messages for a visible support ticket. It also clarifies the staff-only field is included, which distinguishes it from related read tools.

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

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

It states the required ticket_number and mentions filtering, sorting, and pagination capabilities. However, it does not explicitly compare this tool to siblings like ticket-message-write or ticket-read, so an agent must infer when this is the appropriate read 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?

The description adds meaningful behavioral context beyond the annotations: messages cannot be recalled, and the normal notification, webhook, and broadcast pipeline runs. This is consistent with destructiveHint and readOnlyHint.

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 brief and direct, conveying essential behavior and side effects in three sentences without unnecessary filler or repetition.

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

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

The description covers inputs and side effects, but since there is no output schema, it does not indicate what the tool returns on success or failure. This leaves some ambiguity in expected outcomes for an agent.

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

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

All parameters are described in the schema, and the description adds useful context for staff_only and message. However, there is an inconsistency: the schema lists message as not required while the description says it is required for the only allowed action value, which could confuse an agent.

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

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

The description clearly states the tool's purpose with a specific verb ('Post') and object ('a message to a support ticket'), making it easy to distinguish from related read/write ticket 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 explains required inputs and side effects, but it does not explicitly contrast with sibling tools such as ticket-message-read or ticket-write, or state when this tool should be preferred over them.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a behavioral nuance: 'visible' tickets, indicating that not all tickets may be returned (likely permission-based). It also discloses the two actions (list/show) and pagination/filtering behavior, adding value beyond annotations.

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

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

The description is a single, front-loaded sentence that states the core action and capabilities without excess. Every word contributes to understanding the tool's scope, making it highly efficient.

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

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

Given the tool has no output schema, the description could be expected to mention return value shape, but it doesn't. However, the schema is comprehensive for parameters, and the description covers the two actions and their features. The absence of output details is a minor gap for a read-only tool; the core usage is clear.

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 every parameter (action, page, sort, limit, filters, ticket_number) is already documented in the schema. The description only briefly mentions filtering, sorting, and pagination, which maps to these parameters but adds no new semantic detail. Baseline 3 is appropriate when the schema carries the explanatory burden.

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: 'List or show visible support tickets' with specific capabilities (filtering, sorting, pagination). It distinguishes from ticket-write and ticket-message-read siblings by focusing on ticket viewing. The verb-resource pair is specific and unambiguous.

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

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

The description implies usage for viewing support tickets but provides no explicit guidance on when to choose this tool over alternatives (e.g., ticket-message-read for messages, ticket-write for modifications). No exclusions or conditions are stated, leaving the agent to infer context from sibling names.

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 (destructiveHint, readOnlyHint), the description adds behavioral context: 'Sent messages cannot be recalled' and 'Updates can replace assignments, tags and metadata.' This warns about irreversible actions and replacement semantics, which is valuable for agents.

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 and well-structured, consisting of three short sentences that capture the core functionality, additional capabilities, and a warning. No redundant or vague language is present.

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

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

Given the tool has 11 parameters and nested objects, the description provides sufficient context by outlining the primary operations (create/update) and side effects. It does not explain output or error handling, but the absence of an output schema lowers the need for that detail.

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 description does not add parameter-level details; it relies on the schema descriptions, which are already comprehensive (100% coverage). Since the schema covers all parameters with meaningful descriptions, 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's purpose: 'Create or update support tickets.' It distinguishes itself from related tools like ticket-read and ticket-message-write by focusing on ticket creation/update and mentioning the first client message. The additional note about messages not being recalled reinforces the scope.

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

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

The description implies usage for creating or updating tickets but does not explicitly compare to alternatives. It does not mention when to use ticket-message-write for subsequent messages or ticket-read for viewing tickets. While the intent is clear, explicit guidance would improve selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'Requires user_id', which is also in the schema, and mentions pagination/filtering but not beyond schema. No contradiction, but minimal additional 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?

A single sentence with no filler, front-loading the core purpose. It is appropriately sized and 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 read-only list tool with annotations covering safety and a schema that documents parameters, the description is largely adequate. It omits return format, but no output schema exists, so the description could do slightly more. Still, the operation is simple and well-scoped.

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

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

Schema description coverage is 100%, so all parameters are already documented. The description's mention of 'filtering, sorting and pagination' reiterates schema content without adding syntax or format details. Baseline 3 applies because the schema carries the 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 specific verb ('List') and resource ('CRM activities for a client'), making the tool's purpose clear. It does not explicitly differentiate from sibling read tools like client-read, but the resource is distinct enough. A perfect score would name an alternative.

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

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

The description notes 'Requires user_id' but does not provide guidance on when to use this tool versus alternatives. It does not mention exclusions, contexts, or when to prefer a sibling like user-activity-write. The mention of filtering/sorting/pagination is a capability, not usage guidance.

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

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

The destructiveHint annotation already signals modification, and the description adds useful context about attribution to the authenticated user and the create-vs-complete behavior. No contradiction with annotations.

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

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

The description is concise and well-structured, with two sentences that cover the main actions, required fields, and attribution. No redundant or unnecessary 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?

Given the schema and annotations, the description is adequately complete for a write tool with conditional actions. It covers the primary behaviors and requirements without needing to explain return values since no output schema is provided.

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 high, but the description reinforces conditional requirements and adds the semantic detail that entries and completions are attributed to the authenticated user. This goes slightly beyond the existing parameter descriptions.

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

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

Clearly states the tool creates CRM activity entries or completes scheduled activities, with a specific verb and resource. This distinguishes it from user-activity-read and other sibling write 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?

Provides actionable usage guidance by specifying that create requires content, complete requires activity_id, and user_id is always required. It implies when to use each action, though it does not explicitly call out the read alternative.

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 readOnlyHint true and destructiveHint false; description adds that it does not contact destinations, providing additional behavioral context beyond annotations.

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

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

One concise sentence with no redundancy; clearly structured and easy to parse.

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

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

Sufficient for a simple list operation; no missing critical information like side effects (explicitly noted) or required input (action=list).

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

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

Schema covers 100% of parameters (one 'action' parameter with description), but tool description does not add further meaning to the parameter; baseline of 3 is appropriate.

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

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

Clearly states it lists configured outbound workspace webhooks, a read operation, which distinguishes it from webhook-write and other write 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?

Implicitly indicates use for listing webhooks, but does not explicitly contrast with alternatives like webhook-write; still clear from the verb '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?

Beyond the destructiveHint annotation, the description adds behavioral details: creates one webhook per event, active webhooks send workspace data to the URL, and other actions require webhook_id. This gives the agent a clearer picture of side effects without contradicting the annotation.

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

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

The description is concise and front-loaded with the action list. Every sentence adds value: action overview, per-action requirements, and a documentation link. No superfluous wording.

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

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

Given the tool's complexity (multiple actions with different parameter requirements), the description covers all necessary context: what each action does, required parameters, and a link to more detailed docs. It does not explain output or error behavior, but no output schema exists and this is not essential 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?

The schema descriptions already cover all parameters (100% coverage), including the one-row-per-event note for events and the default for is_active. The description repeats some of this information (create requires URL/events, other actions need webhook_id) but adds no new semantic value beyond what the schema provides. Baseline 3 applies given 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 tool's four actions (create, enable, disable, delete) and the resource (outbound webhooks). It distinguishes from the sibling webhook-read tool by focusing on mutations, and the verb list is specific and unambiguous.

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

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

The description provides explicit usage conditions for each action: create requires a destination URL and event slugs, enable/disable/delete require webhook_id. It notes the one-webhook-per-event behavior and points to external documentation. It does not explicitly name alternatives (e.g., webhook-read for reads), but the mutation focus is clear enough for an agent to select this tool 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 indicate readOnly, non-destructive, and not open-world. The description adds useful behavioral context about summarizing role-level actions and subjection to policies, 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 two concise sentences with no redundant or vague wording. It front-loads the core function and then provides usage guidance and caveats efficiently.

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

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

For a zero-parameter tool with no output schema, the description fully covers what it does, when to use it, and important limitations. No critical context 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 tool has no parameters, so the description does not need to explain parameter behavior. The description appropriately focuses on the tool's purpose and output rather than input details.

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

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

The description clearly states the tool identifies the connected Wayfront workspace and authenticated staff account, and summarizes role-level actions. This is a specific, distinct purpose compared to sibling tools focused on records, messages, or 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?

Explicitly says 'Use this when workspace identity, permissions, or connection type matters,' providing direct guidance on when to select this tool over siblings. The caveat about record visibility and policies adds practical context for use.

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