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

No annotations are provided, so the description carries full burden. It transparently explains the three body modes, their wrapping behavior, and how parameters like queryType and queryData are used in update mode. It does not disclose potential side effects or idempotency, but covers the essential behavioral details for a raw API call.

Agents need to know what a tool does to the 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 fairly long but well-structured with bullet points for the three body modes. It front-loads the overall purpose in the first sentence. However, there is some redundancy in listing and describing each mode, and could be slightly more 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 tool has 8 parameters with complex behavior across three modes. The description covers all modes, explains each parameter's context, and gives examples. It lacks description of the return value (no output schema), but given the tool's generic nature, the response is variable. Overall, it is fairly complete for the complexity level.

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

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

With 88% schema coverage, the description adds significant meaning beyond the input schema. It clarifies how parameters interact (e.g., queryType and queryData are required for update mode, extraFields adds top-level fields), and provides context for each parameter's role. For example, 'params' are described as used by GET and POST-raw, and bodyMode alternatives are explained with examples.

Input schemas describe structure but not intent. Descriptions should explain 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 as making a raw call to any DynamicWeb Admin API endpoint, using a specific verb ('Make') and resource ('raw call to any DynamicWeb Admin API endpoint'). It distinguishes itself from sibling tools by being the generic raw call tool, while siblings are specialized for specific 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?

The description provides detailed context on when to use each bodyMode (model for saves, raw for deletes, update for updates) and specifies that GET uses params and POST uses bodyMode. It gives explicit examples for each mode, but does not explicitly mention when to use sibling tools instead of this generic call.

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?

No annotations are provided, so the description must fully disclose behavior. It states it retrieves a schema but does not mention whether it is read-only, has side effects, or any other behavioral traits. For a read-only retrieval tool, this is insufficient transparency.

Agents need to know what a tool does to the 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 with two sentences, no unnecessary words, and front-loads the core purpose. Every sentence earns its place.

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

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

Given the simplicity of the tool (schema retrieval) and absence of output schema, the description is fairly complete. It provides the usage context and purpose, though it could optionally mention that the returned schema is JSON.

Complex tools with many parameters or behaviors need more documentation. 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 meaning by implying that the path and method together identify the endpoint. However, it does not elaborate on the parameters beyond what the schema provides. With 50% schema coverage (method lacks a description), the tool description could have compensated but did not.

Input schemas describe structure but not intent. Descriptions should explain 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 retrieves the full request/response schema for a specific DynamicWeb Admin API endpoint. It uses a specific verb (Get) and resource (schema) and distinguishes from siblings like 'dw_api_call' which actually calls the endpoint.

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

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

The description explicitly advises using this tool before calling an unknown endpoint to understand its parameters. This provides clear context on when to use it, though it does not explicitly mention when not to use it or name 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?

No annotations provided, so description carries burden. States it returns paths with methods and summaries, but does not disclose whether it is read-only or any auth/rate limit requirements. Adequate but minimal.

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

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

Two sentences, front-loaded with purpose and usage guidance. No wasted words.

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

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

With 2 parameters and no output schema, the description sufficiently explains returns. Could mention sorting or pagination, but not necessary for simple search.

Complex tools with many parameters or behaviors need more documentation. 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 50% with keyword description present. The tool description adds context for keyword usage but does not significantly extend beyond the schema for maxResults.

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

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

The description clearly states it searches the DynamicWeb Admin API Swagger spec for endpoints matching a keyword, differentiating it from sibling tools like dw_api_call and dw_api_endpoint_schema.

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

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

Explicitly advises to use when unsure which endpoint to call, with a search by feature name. Does not include exclusions or alternatives, but context is 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?

With no annotations, the description carries the full burden. It only states that it lists areas, but does not disclose any behavioral traits such as being read-only, side effects, or return format. The description is minimal and lacks transparency.

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

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

The description is a single sentence that is front-loaded with the verb and resource. Every word is necessary and there is 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?

Given the tool has no parameters, no annotations, and no output schema, the description is adequate for a simple list operation. However, it does not mention the output format or any additional context, which could help the agent understand what to expect.

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

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

The tool has zero parameters, so per guidelines the baseline is 4. The description adds no parameter information, but it is not needed.

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

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

The description clearly states the verb 'List' and the resource 'DynamicWeb areas (websites/channels)', providing a specific purpose. It is not a tautology and adds value, but does not explicitly differentiate from sibling tools like dw_content_areas.

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

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

No guidance is given on when to use this tool versus alternatives. The description only states what it does, without any context on prerequisites, when not to use, or related tools.

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

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

The description includes a behavioral note about no authentication required, which is helpful. However, it does not mention other aspects like output format, pagination, or any side effects. Since there are no annotations, the description carries the full burden, but the tool is simple.

Agents need to know what a tool does to the 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 with two sentences, front-loading the action and key detail (no auth). Every word adds value.

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

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

Given the tool's simplicity (zero parameters, no output schema), the description is contextually complete for a basic fetch-all operation. It clarifies the resource type and authentication requirement, though it could mention the return format.

Complex tools with many parameters or behaviors need more documentation. 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 schema coverage is trivial (100%). According to the rules, with zero parameters, the baseline score is 4. The description does not add parameter info because none exist.

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

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

The description clearly states the tool fetches all areas (websites) from the DynamicWeb Delivery API. The verb 'Fetch' and resource are specific, but it does not distinguish from the sibling tool 'dw_area_list', which likely serves a similar purpose.

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

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

No guidance is provided on when to use this tool instead of alternatives like dw_area_list or other fetch tools. The description lacks usage context or 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?

No annotations are provided, so the description carries the full burden. It implies a read-only operation but does not explicitly state safety, authentication needs, rate limits, or other behavioral traits. The description adds minimal value beyond the 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?

Three sentences with no fluff: first sentence states purpose, second clarifies output, third gives parameter guidance. Front-loaded and efficient.

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

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

Lacks output schema and does not describe return format, pagination behavior, or handling of large result sets. The description hints at listing all pages but omits how pageSize and page control pagination, leaving gaps for an AI agent.

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

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

Schema coverage is 60% (descriptions for pageId, areaId, url; missing for pageSize and page). The description adds usage context for pageId and areaId but not for pagination parameters. Baseline is 3 given moderate coverage, and the description provides some but not full compensation.

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

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

The description clearly states it fetches pages from the DynamicWeb Delivery API and returns item fields. It specifies three parameter-based access methods (pageId, areaId, url), which distinguishes it from sibling tools like dw_page_list and dw_page_get, though it does not explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 guidance on when to use each parameter (pageId for a specific page, areaId for all pages in a website, url for resolving by path). However, it does not advise when to use this tool over alternatives (e.g., creation or deletion), leaving the agent to infer from 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?

No annotations exist, so the description carries full burden. It describes a read operation but lacks details on error handling, authentication, or side effects, which is adequate but not thorough.

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

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

The description is concise with three clear, front-loaded sentences, each serving a purpose without extraneous words.

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

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

Given no output schema and simple parameters, the description covers core functionality. It could mention the Delivery API context more explicitly but is sufficient for a fetch 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%, so baseline is 3. The description adds context for pageId ('to get all paragraphs for a specific page') but not for itemTypeSystemName, offering marginal additional value.

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

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

The description clearly states the tool fetches paragraphs from the DynamicWeb Delivery API, returns item fields, and distinguishes usage from sibling tools like dw_paragraph_list by specifying the Delivery API context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 advises using pageId to get paragraphs for a page, providing clear usage context. However, it does not explicitly mention when not to use this tool or list alternatives, but the sibling set implies differentiation.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It does not state whether the operation is irreversible, what prerequisites are required (e.g., field existence), or any side effects. A delete operation should at least imply irreversibility or destructive 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 a single, concise sentence that directly conveys the action. It is front-loaded with the key information, though it could be slightly expanded without losing 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 lack of annotations and output schema, the description is incomplete. It does not mention return values, error handling, or confirm whether the field must exist prior to deletion. A more thorough description would include expected outcomes and 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?

Schema description coverage is 0%, and the description adds no meaning to the two parameters. While parameter names are somewhat self-explanatory, they are not formally explained, and the description fails to clarify concepts like 'system name' or provide any example values.

Input schemas describe structure but not intent. Descriptions should explain 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 'Delete a field from a DynamicWeb item type' with a specific verb and resource. It distinguishes the tool from siblings like dw_field_list and dw_field_save by the delete action, but does not highlight what makes this tool unique among similar field 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?

The description provides no guidance on when to use this tool versus alternatives such as dw_field_save or dw_field_list. There is no mention of prerequisites, conditions, or 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?

Despite no annotations, the description discloses the return values ('systemName, type, required') and the read-only nature via 'List,' which suffices for transparency given the tool's simplicity.

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

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

Two short sentences front-load the purpose and return info with zero waste, earning their place.

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

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

The description covers purpose, input, and output adequately for a simple list tool without output schema, though it omits error handling or ordering details.

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

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

With 100% schema coverage, the description reinforces that the parameter is the item type but adds no new semantic details beyond the schema's own description.

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

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

The description clearly states the action ('List all fields') and resource ('a DynamicWeb item type'), making it specific and distinct from sibling tools like dw_field_delete or dw_field_types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 listing fields of an item type but provides no explicit guidance on when not to use it (e.g., for deleting fields) or alternatives among siblings.

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

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

Reveals automatic handling of RichTextEditor configuration, but with no annotations, the description must disclose more. Missing details on permissions, destructiveness, return values, or error states.

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

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

Concise with three short paragraphs; front-loaded with purpose. No redundant information, but structure could be improved with bullet points for parameters.

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

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

Lacks details on output, success/failure indication, prerequisites (e.g., item type existence), and overall mutation behavior. For a tool with 7 parameters and no output schema, more context is needed for effective use.

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

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

Adds value by explaining isNew's role and hinting at type discovery via dw_field_types. Schema covers 57% of parameters with descriptions; the description supplements moderately but does not cover all parameters comprehensively.

Input schemas describe structure but not intent. Descriptions should explain 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 adds or updates a field on a DynamicWeb item type, distinguishing between new (isNew: true) and existing fields. Differentiated from siblings like dw_field_delete and dw_field_list, though not explicitly compared.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 guidance on using isNew flag and recommends dw_field_types for discovering type aliases. Lacks explicit when-to-use or alternatives, such as when to use product field tools or when not to use this tool.

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

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

No annotations; description states it fetches from AddIn registry (not hardcoded) but lacks details on read-only nature, error handling, or performance. Adequate but could add more 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?

Three sentences without waste: purpose, data source, output usage. Front-loaded and efficient.

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

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

Explains output format and how to use it, which is sufficient for a simple list tool. Lacks mention of whether data is cached or always live. Reasonably complete given no output schema.

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

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

No parameters; schema coverage is 100% (trivially). Description adds no extra param info but doesn't need to. Baseline for zero parameters 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 field editor types from the DW AddIn registry, and mentions output format. Implicitly differentiates from sibling tools like dw_product_field_type_list by specifying usage in dw_field_save and dw_itemtype_create, but does not explicitly contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 tells when to use: before using field types in dw_field_save or dw_itemtype_create. Does not provide 'when not to use' or alternatives, but context is 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?

No annotations provided, and the description fails to disclose behavioral traits such as whether the listing is recursive, hidden directories included, or permissions required. It only states the basic action.

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

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

The description is a single sentence which is appropriate for simplicity, but it lacks sufficient detail to be truly concise; it is under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 one parameter, no output schema, and no annotations, the description should provide more context. It does not explain behavior like recursion, return format, or edge cases.

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

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

Schema coverage is 100% with parameter description 'Directory path'. The tool description adds no extra meaning beyond the schema, only confirming 'subdirectories'.

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

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

The description clearly states 'List subdirectories in a DynamicWeb directory.' with a specific verb and resource, and it distinguishes from sibling dw_files_list which presumably lists files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 like dw_files_list. The description is purely functional without 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?

No annotations provided, so description must convey behavioral traits. Only states listing and filtering; does not disclose read-only nature, permissions, limits, or side effects.

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

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

Two concise sentences with no unnecessary words. Front-loaded with primary action.

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

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

Lacks output schema and does not describe return format or pagination. Missing context about depth of listing or what is returned for each file.

Complex tools with many parameters or behaviors need more documentation. 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 description adds 'List files in a DynamicWeb directory' for directoryPath, but does not add significant meaning beyond schema's existing 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?

Specifically states verb 'List', resource 'files in a DynamicWeb directory', and optional filtering by extensions. Distinguishes from sibling tools like dw_files_directories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 basic usage context (directory path, optional filter) but no explicit guidance on when to use this tool versus alternatives like dw_files_directories for directory listing.

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?

No annotations are provided, so the description carries the full burden. It discloses that the operation creates in one step and gives behavioral instructions for allowedChildItemTypes. However, it lacks details on side effects (e.g., systemName uniqueness, reversibility, error behavior) and does not mention return value or authentication needs.

Agents need to know what a tool does to the 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 a clear one-sentence summary, a bulleted list of conventions, and two targeted sentences on allowedChildItemTypes. Every sentence serves a purpose, and key information 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's complexity (10 parameters, nested objects, no output schema), the description covers important usage patterns but omits return value information and error handling. It is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. 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 60% (likely underestimated, as all top-level parameters have descriptions). The description adds value beyond the schema by providing category conventions and usage patterns for allowedChildItemTypes. Baseline is 3 due to high schema coverage, and the description minimally supplements 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 tool creates a new DynamicWeb item type with fields and restrictions in one operation. It identifies the specific verb (create) and resource (item type), and distinguishes from sibling tools like dw_itemtype_update_settings or dw_itemtype_delete.

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

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

The description provides clear context for use, including category conventions and instructions for allowedChildItemTypes. While it does not explicitly compare to siblings, the purpose is unambiguous, and the category rules help the agent decide when to use this tool for creating item types.

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?

With no annotations, the description should disclose behavioral traits. It only states the basic action and does not mention side effects, permissions, reversibility, or cascading deletes. The destructive nature is implicit from the name but not elaborated.

Agents need to know what a tool does to the 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 very concise at 9 words. It is front-loaded with the verb. However, conciseness comes at the cost of crucial details, making it borderline under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 delete operation with one parameter, no output schema, and no annotations, the description lacks essential context such as return value, confirmation, error handling, and impact on related entities. Incomplete for safe use.

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

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

Schema description coverage is 0%, so the description must add parameter meaning. It adds 'by systemName' which is obvious from the parameter name. It does not clarify the format, case sensitivity, or source of the systemName.

Input schemas describe structure but not intent. Descriptions should explain 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 (delete), the resource (DynamicWeb item type), and the identifier (by systemName). It distinguishes from sibling tools like dw_itemtype_create, dw_itemtype_get, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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, no prerequisites, no consequences of deletion, and no mention of when not to use. The description is silent on usage 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?

With no annotations, the description relies on the word 'Get' to indicate a read operation, but it does not confirm lack of side effects or disclose any behavioral traits such as authentication requirements or rate limits. It adds context about restrictions but leaves other behaviors implicit.

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

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

The description is a single, efficient sentence that front-loads the purpose. Every word contributes meaning, with no superfluous 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 simple one-parameter input and no output schema, the description is relatively complete. It specifies the identifier and what is included (restrictions). It could mention the return format or that the systemName is case-sensitive, but the context is sufficiently covered for a straightforward retrieval 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 input schema has 100% coverage with a description for the systemName parameter. The description adds no additional meaning beyond the schema, so it meets the baseline. The parameter semantics are adequately handled by 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 (Get), the resource (DynamicWeb item type), the identifier (by systemName), and includes context (including all restrictions). This distinguishes it from sibling tools like dw_itemtype_list which retrieves multiple items.

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

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

The description implies usage when you have a specific systemName, but it does not explicitly state when to use this tool versus alternatives like dw_itemtype_list or when not to use it. No guidance on prerequisites or context 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 description indicates a list operation, implying it is non-destructive, but with no annotations, it doesn't explicitly state this or disclose other behaviors like rate limits or auth requirements.

Agents need to know what a tool does to the 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 wasted words. Front-loaded with the 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 list operation with no parameters, the description covers the return fields adequately. Could mention pagination but not necessary for completeness.

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

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

No parameters exist, so schema coverage is 100%. The description adds nothing about parameters, but since there are none, this is fine. Baseline 4.

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

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

The description clearly states the verb 'List' and the resource 'all DynamicWeb item types', and specifies the fields returned. It distinguishes from siblings like 'dw_itemtype_get' which retrieves a single item type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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, but the sibling tools imply this is for listing all item types while others cover specific operations.

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

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

No annotations provided, so description carries full burden. It discloses the incremental update behavior ('omitted ones are left untouched'), which is critical. Could mention reversibility or permissions, but the key behavior is covered.

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

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

Four sentences, each valuable: purpose, usage rule, common use case, example. No redundant information, well-structured and 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 7 parameters and no output schema, the description covers usage pattern and partial update behavior. Missing details on error handling or what happens if systemName doesn't exist, but adequate for most scenarios.

Complex tools with many parameters or behaviors need more documentation. 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 (86%), but the description adds important semantics: only modify passed arrays. This clarifies that arrays are optional despite schema showing only systemName as required. The example also provides concrete 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 tool updates restrictions on a DynamicWeb item type, differentiating from sibling tools like 'update_settings' by specifying the resource as 'restrictions'. It also gives a common use case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 advises to only pass arrays to change, with omitted ones untouched. Provides an example with allowedChildItemTypes. Does not explicitly mention when not to use but context from name and sibling tools implies distinction.

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?

No annotations are provided, so the description must disclose behavioral traits. It reveals the partial update behavior (preserving omitted fields) and the admin tab correspondence. However, it does not mention side effects, authentication requirements, rate limits, or error handling, which are relevant for a mutation tool with 12 parameters.

Agents need to know what a tool does to the 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 followed by a third sentence summarizing the admin tab correspondence. It is front-loaded with the action and key behavior (partial update). Every sentence adds value, and there is no 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?

With 12 parameters and no output schema, the description covers the core use case (update settings, partial update) and maps to the UI. However, it lacks details on return values, error scenarios, or prerequisites. The schema descriptions cover parameter syntax, but the description could be more complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema—it groups parameters into 'General, Availability, Title for new items, Advanced sections' but doesn't explain any parameter further. This is adequate but not exceptional.

Input schemas describe structure but not intent. Descriptions should explain 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 it updates settings on an existing DynamicWeb item type, and distinguishes from sibling tools like dw_itemtype_create (create), dw_itemtype_delete (delete), and dw_itemtype_update_restrictions (update restrictions). The verb 'Update' and resource 'Settings fields on an existing DynamicWeb item type' 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 clearly advises to only pass fields to change, with omitted ones preserved, which is a key usage guideline. It also maps the tool to the Settings tab in DW Admin, providing context. However, it doesn't explicitly state when to use alternatives (e.g., create vs update), but the 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?

With no annotations, the description carries full burden but only outlines internal steps without disclosing side effects, permissions, error handling, or return behavior, leaving significant gaps.

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

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

Three sentences, front-loaded with purpose, no wasted words, and structured as numbered steps.

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

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

Lacks output description or return value (no output schema), no error handling guidance, and does not explain what happens after creation despite moderate complexity (7 parameters).

Complex tools with many parameters or behaviors need more documentation. 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 71%, so baseline is 3. The description adds minimal additional meaning beyond the schema, only hinting at parameter usage in steps.

Input schemas describe structure but not intent. Descriptions should explain 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 'Create a new DynamicWeb page under a parent page' with a specific verb and resource, and distinguishes from sibling tool dw_page_set_fields by mentioning it as a follow-up.

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

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

Provides a clear follow-up action (use dw_page_set_fields) but does not explicitly state when to use this tool over alternatives or any when-not-to-use scenarios.

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

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

The description explicitly states that the deletion is irreversible, a critical behavioral trait. However, no annotations exist and the description does not cover other potential behaviors like permission requirements or cascading effects.

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

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

Two sentences with no unnecessary words; efficient and front-loaded with the action.

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

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

For a simple delete with one parameter, the description covers basics but lacks context about implications (e.g., impact on related content areas, paragraphs). More context would help the agent given many sibling tools.

Complex tools with many parameters or behaviors need more documentation. 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 only mentions 'by ID', hinting at the pageId parameter, but adds no detail about format, source, or how to obtain valid IDs. With 0% schema coverage, this is insufficient.

Input schemas describe structure but not intent. Descriptions should explain 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 'Delete' and the resource 'DynamicWeb page by ID', distinguishing it from sibling tools like dw_page_create, dw_page_get, etc.

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

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

The description does not provide any guidance on when to use this tool over alternatives such as dw_page_set_fields or dw_page_list. No prerequisites or context for usage are mentioned.

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

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

With no annotations provided, the description must fully convey behavioral traits. It only states that the tool retrieves a page and all its fields, but omits key details such as read-only nature, error handling (e.g., missing page), or authentication requirements.

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

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

The description is a single, focused sentence with no extraneous information. It front-loads the core action and resource, earning its place.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is nearly complete. It could clarify that this only retrieves pages (not other entities like paragraphs), but sibling tool names provide that context. The phrase 'all item fields' hints at the response richness.

Complex tools with many parameters or behaviors need more documentation. 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% for the single parameter 'pageId', which has a clear description in the schema ('Page ID (numeric string)'). The description adds 'including all item fields', which relates to output rather than parameter semantics, so it provides minimal extra value beyond the schema.

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

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

The description clearly states 'Get a single DynamicWeb page by ID, including all item fields.' It uses a specific verb ('get') and resource ('DynamicWeb page'), and distinguishes from sibling tools like dw_page_list (which lists pages) and dw_page_create (which creates pages).

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

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

No guidance is provided on when to use this tool versus alternatives. While siblings exist for listing, creating, or updating pages, the description offers no contextual hints about selection criteria or prerequisites.

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

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

No annotations provided; description only states it lists pages, but doesn't disclose behavioral traits like pagination, authentication, or effects of omitting filters.

Agents need to know what a tool does to the 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 compact sentence with no fluff. Front-loaded with core action and filtering 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?

Simple tool with optional filters, but missing details like pagination behavior, combined filter logic, and return value structure. Adequate but not complete.

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

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

Schema coverage is 100% with descriptions; description adds no new meaning beyond restating schema fields. Baseline score applies.

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

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

Description clearly states verb 'List' and resource 'DynamicWeb pages', with explicit filtering options. Distinguishes from sibling tools like dw_page_get or dw_area_list.

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

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

Implies usage via filtering, but no explicit guidance on when to use this tool versus alternatives (e.g., dw_page_get for a single page).

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 explains the process: 'Fetches the current page, updates field values in its pageItem structure, then saves.' It also clarifies the fields parameter. However, it does not disclose whether fields are merged or overwritten, error handling (e.g., page not found), or side effects like triggering workflows. With no annotations, the description carries full burden but is partially adequate.

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

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

The description is concise (3 sentences), front-loaded with the main purpose, and free of unnecessary details. Every sentence adds value: action statement, process summary, and parameter clarification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 (fetch-update-save) and the presence of many sibling tools, the description is adequate but not thorough. It does not explain return values, error behavior, or how to obtain pageId. However, for a simple field-setting operation, it provides the essential flow.

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

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

Schema coverage is 100%, so the schema already describes the parameters. The description adds nuance for 'fields' by explaining it is a key-value map with field SystemNames as keys, which slightly exceeds the schema's description. For 'pageId', no additional meaning is added. Hence, baseline 3 with minor enhancement.

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

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

The description clearly states the action: 'Set item fields on a DynamicWeb page.' It specifies the resource (DynamicWeb page) and the operation (setting fields). This distinguishes it from sibling tools like dw_page_get (read) and dw_field_save (field definitions).

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios, or when not to use it. For example, it does not differentiate from dw_page_create (which might set fields on creation) or dw_page_update (which might update other properties).

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 paragraphs are ordered ascending via the sort field and hints at future reordering, but lacks details on error handling (e.g., invalid pageId or itemType), permissions, or side effects. Since no annotations are provided, the description carries full burden, and while it adds context beyond the schema, it is insufficient for a complete behavioral understanding.

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

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

The description is concise with three short sentences: the first stating purpose, the second giving next-step guidance, and the third explaining sort ordering. No extraneous information, and the structure is easy to parse.

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

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

Given 4 input parameters, no output schema, and sibling tools, the description adequately covers the creation step and directs to dw_paragraph_set_fields for content population. However, it does not describe the return value (likely the paragraph ID) or possible errors, making it incomplete for an agent to fully understand the tool's behavior.

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

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

Schema description coverage is 50% (pageId and itemType have descriptions, sort and active do not). The description adds meaning to the sort parameter by explaining the ordering convention and suggesting values. However, it does not explain the active parameter or its defaults beyond the schema, and it does not fully compensate for the missing schema descriptions of all parameters.

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

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

The description clearly states the tool creates a new paragraph on a DynamicWeb page, using 'Create a new paragraph' and specifying the mechanism (ParagraphSave) and item type. It differentiates from sibling tools like dw_paragraph_set_fields by indicating it is for creation only and that field population is a separate step.

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

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

The description provides explicit guidance to use dw_paragraph_set_fields after creation for populating content fields, which helps the agent understand the workflow. It also explains the sort parameter's ascending order and suggests using increments of 100 for easy re-ordering, but does not specify when not to use this tool or mention alternatives for similar operations.

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

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

The description discloses the destructive nature of the action. However, with no annotations, it lacks additional behavioral context such as cascading effects or irreversibility.

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

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

Very concise single sentence with no redundancy. Slightly too terse, but 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 delete operation with one parameter, the description provides the core purpose. However, it omits return value or any post-deletion state, which is acceptable but minimal.

Complex tools with many parameters or behaviors need more documentation. 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 0%, and the description only implies 'paragraphId' is an ID without specifying format, constraints, or source. The meaning is inferred but not elaborated.

Input schemas describe structure but not intent. Descriptions should explain 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 (delete) and the resource (DynamicWeb paragraph) with identifier (by ID). It distinguishes from sibling tools like dw_paragraph_create, dw_paragraph_get, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 like dw_paragraph_set_fields or dw_paragraph_list. No prerequisites or cautionary notes 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?

No annotations provided. Description adds 'including all item fields' but lacks details on read-only nature, error handling, or performance. Minimal transparency for a retrieval tool.

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

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

Single sentence, 11 words, no filler. Every word adds value. Perfectly concise.

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

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

For a simple get-by-ID with one parameter, description is mostly complete. Mentions return includes all item fields. Could specify non-existence behavior, but not essential.

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

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

Schema coverage is 100% with parameter described as 'Paragraph ID'. Description adds no additional meaning beyond schema; baseline score applies.

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

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

Description clearly states verb 'Get', resource 'single DynamicWeb paragraph', and scope 'by ID, including all item fields'. This distinguishes it from siblings like dw_paragraph_list (list all) and dw_paragraph_create.

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

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

Implied usage: use when you need a single paragraph by ID. No explicit when-not or alternatives mentioned, despite multiple sibling tools for different operations.

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

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

With no annotations, the description carries full burden. It does not disclose that this is a read-only operation, any pagination behavior, or output format. The minimal description leaves important behavioral traits unspecified.

Agents need to know what a tool does to the 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, front-loaded and efficient. However, it may be overly terse given the lack of behavioral details.

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

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

For a simple list tool, the description is minimal. It does not cover return format, read-only nature, or distinguish from sibling list tools. The absence of this context reduces completeness given the tool's low complexity.

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

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

Schema description coverage is 100% for the single parameter 'pageId'. The tool description adds no additional meaning beyond the schema's 'Page ID to list paragraphs for', 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 it lists paragraphs on a DynamicWeb page, using a specific verb and resource. However, it does not differentiate from sibling tool 'dw_content_paragraphs' which likely performs a similar function.

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

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

No guidance is provided on when to use this tool versus alternatives like 'dw_paragraph_get' or 'dw_content_paragraphs'. The description lacks any context for 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 the read-modify-write behavior ('Fetches... updates... saves') and explains value formatting for richtext and file fields. With no annotations, this provides good transparency, though it could mention potential side effects or error handling.

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

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

The description is four sentences with no wasted words. It front-loads the purpose, explains the process, describes the fields parameter, and gives examples. Every sentence adds value.

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

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

Given the simple two-parameter schema and no output schema, the description covers the essential aspects: what the tool does, how it works, and how to format values. It lacks error handling details or return value expectations, but is largely complete for this level of complexity.

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

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

Schema coverage is 100% but the description adds significant meaning beyond the schema by explaining that 'fields' is a key-value map of SystemNames, and provides concrete examples for richtext and file/image values.

Input schemas describe structure but not intent. Descriptions should explain 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 'Set item fields on a DynamicWeb paragraph' and explains the fetch-update-save process. However, it does not explicitly differentiate from similar tools like dw_page_set_fields, but the resource-specific verb and context make the purpose clear.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., dw_field_save or dw_paragraph_update). There is no mention of prerequisites, limitations, or 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?

No annotations are provided, so the description bears full responsibility. It discloses that the tool modifies prices in-place (destructive) and returns old/new values. However, it lacks details on permissions required, reversibility, or potential side effects, which would be beneficial for full transparency.

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

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

The description is concise with two sentences and no extraneous information. It front-loads the action ('Apply a percentage discount') and efficiently covers targeting and return behavior.

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

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

Despite lacking an output schema and annotations, the description covers the main aspects of the tool: purpose, targeting, and return values. It could be more complete by mentioning potential defaults or caveats, but overall it provides sufficient context for an agent to use 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 description coverage is high (83%), with most parameters documented. The description adds context beyond the schema by explaining that the discount applies to DefaultPrice, that groupId and productIds are alternative targeting methods, and that the output includes old and new prices. This adds meaningful semantics.

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

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

The description clearly states the tool applies a percentage discount to DefaultPrice across a set of products, modifying the base price in-place. It specifies two targeting options (groupId or productIds) and indicates it returns per-product old/new prices. This distinguishes it from sibling tools, none of which perform bulk discounting.

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

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

The description provides clear guidance on when to use the tool: for applying discounts to multiple products either by group or by explicit IDs. It does not explicitly state when not to use it or mention alternatives, but the context is sufficient for an agent to decide.

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?

No annotations provided, so the description bears full burden. Discloses irreversibility and reveals the internal 3-step process (mark candidates, validate, delete), indicating partial failure behavior and validation steps. This goes beyond a simple delete description.

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

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

Three sentences, each adding essential information: action, irreversibility+precondition, internal steps. No fluff, well-structured, and front-loaded with the core purpose.

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

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

For a simple delete operation with no output schema, the description covers purpose, irreversibility, precondition, and internal process. Could mention handling of partial invalid ids, but overall quite complete.

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

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

Schema coverage is 100% and includes example values for 'ids'. Description does not add extra semantic detail for the parameter beyond the schema. A 4 is appropriate as the schema already does the heavy lifting.

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

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

Clearly states 'Delete one or more DynamicWeb product categories.' Specific verb+resource. Distinguishes from sibling tools like dw_product_category_save (create/update) and dw_product_category_list (list).

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 irreversibility and a critical precondition: fields must be deleted first via dw_product_field_delete, otherwise validation fails. Names the alternative tool, guiding the agent on prerequisites and dependencies.

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?

No annotations provided, so the description carries full burden. It mentions return fields but fails to disclose pagination behavior (pagingSize, pagingIndex) or filtering effects of the search parameter. It is unclear if the operation is read-only, though it's implied by 'List'.

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

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

The description is two sentences, front-loaded with the purpose, and contains no unnecessary words. Every sentence adds value.

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

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

Given no output schema, the description provides return fields (id, name, fieldsCount). However, it lacks details on pagination and search functionality. For a list tool with three optional parameters, it is adequate but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. 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 only 33% (search param has a brief description). The description does not explain any parameters, despite the schema having two undocumented parameters (pagingSize, pagingIndex) with defaults. No additional meaning beyond the schema is 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 verb 'List' and the resource 'DynamicWeb product categories', and specifies the return fields (id, name, fieldsCount). This distinguishes it from sibling tools like dw_product_category_delete and dw_product_category_save.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 listing categories but does not explicitly state when to use this tool versus alternatives like dw_area_list or dw_field_list. No exclusion criteria or usage context beyond the basic listing purpose.

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

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

No annotations provided, so description carries full burden. It discloses it is a save operation (create/update) but does not mention side effects, error handling, or permissions. Minimal behavioral disclosure but adequate for a typical save.

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

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

Two sentences with no fluff, front-loading the core purpose. Every sentence earns its place, making it efficient for an agent to parse.

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

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

Given no output schema and simple parameters, the description is complete enough. It covers main usage and links to related tool for field addition. Could mention return values, but not critical.

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

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

The description adds value by clarifying isNew parameter usage ('set isNew: true to create') and explaining that id is used as CategoryId on fields, which goes beyond schema descriptions. Schema coverage is 75%, so description compensates well.

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

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

The description clearly states it creates or updates a DynamicWeb product category, using verbs 'Create or update'. It distinguishes from siblings like dw_product_category_list and dw_product_category_delete by focusing on save operation, and mentions separate field addition via dw_product_field_save.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 when to use create vs. update via the isNew flag, and indicates that category fields are added separately. It does not explicitly state when not to use, but the context is 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?

Despite no annotations, the description discloses key behaviors: irreversibility and auto-formatting of IDs. However, it does not mention error handling, return values, or permission requirements, which would be helpful for a mutation tool.

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

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

Two sentences: first conveys purpose and irreversibility, second clarifies ID handling. No wasted words; essential information 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?

Adequate for a simple delete tool, but missing details on batch behavior, error responses, and whether deletion is synchronous. Given no output schema and no annotations, more context on usage outcomes would improve completeness.

Complex tools with many parameters or behaviors need more documentation. 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 50%, and the description adds significant meaning by explaining the required ID format and auto-formatting feature. This compensates for the schema's lack of description for languageId, though the languageId parameter is not explicitly detailed.

Input schemas describe structure but not intent. Descriptions should explain 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 deletes one or more DynamicWeb products, emphasizing irreversibility and ID format. This distinguishes it from sibling tools like dw_product_get or dw_product_update.

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

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

The description implies use for deletion (irreversible) but does not explicitly specify when to use it versus alternatives like dw_product_update or dw_product_category_delete. No guidance on prerequisites or when not to 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?

No annotations provided. Description discloses irreversibility and single-category constraint, key behavioral traits for a delete operation. Could mention return value or permissions, but adequate.

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

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

Two sentences: first states action and irreversibility, second gives usage constraint. No wasted words, front-loaded.

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

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

Covers essential aspects: action, irreversibility, usage constraint. No output schema, but not needed for delete. Adequate for its complexity.

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

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

Schema coverage 100%, both parameters described. Description adds value by explaining cross-category usage and enforcing sameness constraint, beyond 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?

Clearly states 'delete one or more product fields from a single category', specifying action and resource. Constraint 'Irreversible' adds clarity. Distinguishes from siblings like dw_field_delete and dw_product_category_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 constraint: 'All ids must belong to the same categoryId' and guidance for multiple categories: 'call this tool once per category'. No explicit alternatives but clear 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?

Without annotations, the description carries full burden. It clearly indicates a read-only list operation and specifies what data is returned. However, it does not mention pagination, sorting, or any limits, which is acceptable for a simple list tool.

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

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

Two sentences: first states the purpose, second lists return fields. No filler, highly efficient. Front-loaded with the action and target 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 tool with one parameter and no output schema, the description covers the essentials: what it does, what it returns, and the input. Lacks details on pagination or error conditions, but adequate for a straightforward list endpoint.

Complex tools with many parameters or behaviors need more documentation. 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 a single parameter described as 'Category id, e.g. 'TechSpecs''. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists all product fields for a category, and specifies the exact return fields: systemName, name, typeId, typeName, required. This distinguishes it from siblings like dw_field_list (likely for content fields) and dw_product_field_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 retrieving product field definitions by category, but does not explicitly state when to use it versus alternatives like dw_field_list or dw_product_field_type_list. No context on prerequisites or 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?

With no annotations provided, the description must disclose behavioral traits. It states the tool can create or update, and explains the SystemName role, but does not mention idempotency, merge behavior, required permissions, or what the tool returns. Important details are missing for a save 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?

The description is concise—5 sentences, front-loading the purpose, then providing type details and a key behavioral note. No superfluous content; every sentence adds value.

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

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

Given 13 parameters, no output schema, and no annotations, the description covers the core purpose and type semantics, but lacks information about return values, error handling, and full parameter details. It is adequate but not comprehensive.

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

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

The schema has only 31% parameter description coverage. The tool description adds meaning for 'type' (listing aliases) and 'systemName' (frontend key role), but does not explain the 9 other parameters like 'required', 'hidden', 'readonly', etc. It partly compensates but not fully.

Input schemas describe structure but not intent. Descriptions should explain 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 'Create or update' and resource 'product field on product category'. It also provides type alias details and frontend key behavior. However, it does not explicitly distinguish from the sibling tool 'dw_field_save', though the 'product' prefix provides implicit differentiation.

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

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

The description advises using 'dw_product_field_type_list' for the full type mapping, which is a helpful reference. But it lacks guidance on when to use this tool versus alternatives like 'dw_field_save' or 'dw_product_field_delete', nor does it specify prerequisites or 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?

No annotations exist, so description carries full burden. It discloses the tool returns a list of types with ID and aliases, implying no side effects. However, it doesn't explicitly state it's read-only or mention any restrictions.

Agents need to know what a tool does to the 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, no wasted words, front-loaded with key purpose. Every sentence adds value.

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

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

For a parameterless list tool, the description adequately explains output and usage. It could mention that it is read-only, but overall it is complete 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?

Input schema is empty, so baseline is 4. Description adds no parameter details because there are none, but it doesn't need to.

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

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

The description clearly states it lists DynamicWeb product field types with TypeId, specifying the resource and action. It distinguishes from siblings like dw_field_types and dw_product_field_list by focusing on product field types specifically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 using the returned 'id' in dw_product_field_save or using a short alias. This helps the agent understand how to apply the output and 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?

With no annotations, the description carries the full burden. It mentions returning the full model with CustomFields but omits behavioral traits like authentication requirements, error handling (e.g., what happens if ID not found), or rate limits.

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

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

The description is a single sentence with no wasted words. It is concise and front-loaded with the core purpose.

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

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

For a simple retrieval tool, the description covers the basic purpose and response content. However, lack of output schema and low parameter coverage reduces completeness. It could mention read-only nature or error behavior.

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

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

Schema coverage is only 33% (only id has a description). The description does not add any additional meaning for languageId or variantId, failing to compensate for the low coverage.

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

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

The description clearly states the action is to 'Get a single DynamicWeb product by ID', specifies the resource, and mentions returning the full model including CustomFields. This distinguishes it from siblings like dw_product_list (list) and dw_product_update (update).

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 (e.g., dw_product_list for multiple products) or prerequisites. The description does not provide context for optimal 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?

With no annotations, the description must disclose behavioral traits. It mentions pagination (pagingSize) and returned fields, but does not cover authentication, rate limits, or whether the operation is read-only (assumed). The absence of destructive hint is acceptable for a list, but more detail on pagination limits would improve transparency.

Agents need to know what a tool does to the 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 covering purpose, filters, outputs, and pagination. No redundant information. Could be slightly better structured, but efficient for an agent to parse.

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

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

Given 5 parameters and no output schema, the description partially covers outputs and filtering but omits details on languageId, pagingIndex, error handling, and rate limits. It is adequate for a simple list tool but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. 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 low (40%). The description adds minimal value: it restates groupId and search (already in schema) and provides a vague hint for pagingSize ('control result count'). It ignores languageId (default only) and pagingIndex, leaving their meaning unclear. For a tool with 5 parameters, this is insufficient.

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

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

The description clearly states the tool lists DynamicWeb products, specifies filtering by groupId or search term, and lists returned fields. It distinguishes from sibling tools like dw_product_get (single product) and dw_product_category_list (categories).

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 (listing products with filters) but does not explicitly state when not to use or compare to alternatives. It lacks guidance on using dw_product_get for individual products or dw_product_update 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?

No annotations are present, so the description carries the full burden. It transparently describes the update process (fetch, overlay, save), input field casing conventions, and custom field keying. It lacks details on authentication or error behavior, but is adequate.

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

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

The description is concise, front-loaded, and contains no extraneous information. It uses clear bullet points for parameter groups. Could be slightly more structured but is effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 moderate complexity with 7 parameters and no output schema, the description provides sufficient behavioral context. It explains the update mechanism and schema management. Missing error handling details, but adequate for most use cases.

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

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

Schema description coverage is 57% (4 of 7 parameters have descriptions). The description adds meaningful context by explaining the roles of fields, customFields, and categoryFields with examples, compensating for the lower 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 it updates an existing DynamicWeb product, outlines the process (fetch, overlay, save), and distinguishes its purpose from sibling tools like dw_product_get and dw_product_field_save. The verb and resource are specific.

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

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

The description explains when to use this tool (update product fields) and mentions managing schema via dw_product_field_save / dw_product_category_save as alternatives. However, it does not explicitly state when not to use this tool compared to other update tools.

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