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

Annotations are minimal, so the description carries full burden. It discloses that the backend appends to the end, rejects duplicate element ids, defaults dry_run=true, caches payload as draft_id, and returns draft_id on validation failure. It also requires WEBCAKE_API_BASE and WEBCAKE_JWT, providing ample behavioral context.

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

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

The description is a single dense paragraph that covers all aspects, though it repeats the dry_run explanation and could benefit from bullet points for readability. It is front-loaded with the core action but lacks structure.

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

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

No output schema is provided, and the description does not mention what successful real call returns (e.g., updated page or status). It assumes knowledge of 'sparse nodes' and 'factory defaults', and does not explain return values. This leaves 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 100%, but description adds significant meaning: for 'sections', it explains sparse nodes and server hydration; for 'dry_run', it clarifies default and purpose; for 'draft_id', it describes cache usage. This goes beyond the schema's basic descriptions.

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

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

The description clearly states the tool appends sections to an existing page without re-sending the whole source, distinguishing it from create_page. It specifies the verb 'appends' and the resource 'SECTIONS to an existing page', and contrasts with the 'incremental-build path' that avoids large payloads.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 explains when to use this tool (for incremental section addition), when not to (instead use patch_page for fixing errors), and provides alternatives (calling patch_page with draft_id). It also details the dry-run vs. real call workflow and how to handle validation failures.

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

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

Discloses many behaviors beyond annotations: auto-fixes layout defects, dry_run default, draft_id reuse, organization resolution algorithm, auto-publish failure handling, token masking, and preview link expiration. Annotations only indicate readOnlyHint=false and openWorldHint=true, so description carries full burden.

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

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

Dense with information but slightly verbose. Front-loaded with main action but could benefit from bullet points for readability. However, every sentence provides value and avoids fluff.

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

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

Given 6 parameters, no output schema, and minimal annotations, the description covers all essential behavioral context: creation, publishing, validation, organization handling, error scenarios, and caching. No gaps.

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

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

Schema coverage is 100%, but description adds significant meaning: source parameter explains sparse author elements, organization_id details resolution logic, dry_run and publish defaults, draft_id reuse case. Adds value beyond schema definitions.

Input schemas describe structure but not intent. Descriptions should explain 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 page, saves the source, and auto-publishes. It uses specific verbs ('persists', 'creates', 'saves', 'auto-publishes') and distinguishes itself from siblings like update_page, patch_page, and publish_page.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 when-to-use guidance: dry_run for validation, draft_id for reusing cached sources, organization_id resolution with fallback logic. Also specifies when to skip auto-publish (publish:false) and alternative for permanent URLs (publish_page with custom_domain).

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral details: filters are AND-combined, results include specific fields, and it requires WEBCAKE_API_BASE + WEBCAKE_JWT. No contradiction.

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

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

The description is concise: three sentences covering purpose, filter behavior, and result content. It is front-loaded with the primary use case. Every sentence adds value without redundancy.

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

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

Given the tool's complexity (4 parameters, no output schema, read-only annotations), the description covers result fields, filter logic, and authentication requirements. It could mention pagination (though limit is in schema) but overall complete for a search tool.

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

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

Schema coverage is 100%, so descriptions exist for each parameter. The description enriches these by explaining filter combination logic and giving an example query (name='sale' + domain='shop.com'), which adds meaning beyond the schema.

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

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

The description clearly states the tool searches pages by multiple criteria (name, domain, page_id) to locate a page for editing. It distinguishes from siblings like list_pages and get_page by specifying the use case of locating a page to then pass its ID to update_page/add_section.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 tells when to use the tool (to find a page for editing) and provides an alternative: using list_pages for a simple list when no filters are applied. It also explains the AND-combination of filters, giving clear guidance on usage.

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

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

Annotations provide readOnlyHint=true, and the description does not contradict it. It adds detailed behavioral context, such as the return format for both single and batch modes, the concept of a 'sparse skeleton node', and backward compatibility. Minor omissions (e.g., error handling) are acceptable given read-only nature.

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

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

The description is a single paragraph without bullet points, but it is information-dense and avoids redundancy. Every sentence adds value. Could be slightly more structured for readability, but overall concise 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 the absence of an output schema, the description compensates well by explaining the response shape for both modes and the purpose of the skeleton node. It covers key aspects like batch mode and backward compatibility. Some details (e.g., potential errors) are missing, but it is sufficient for a read operation.

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

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

Schema coverage is 100%, but the description adds significant meaning beyond schema: it explains the advantage of 'types' over 'type', provides example values, and clarifies the backward-compatibility behavior. This substantially aids the agent in correct invocation.

Input schemas describe structure but not intent. Descriptions should explain 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 returns detailed usage for one or many element types, distinguishing between single and batch mode. It specifies the contents: summary, when to use, specials fields, sparse skeleton node, and filled example. This provides a specific verb+resource definition.

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

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

The description gives explicit guidance on when to use the 'types' parameter over 'type' ('Prefer `types` when fetching more than one') and includes an example. It does not explicitly mention when not to use the tool or alternatives among siblings, but the context is clear for batch vs single usage.

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

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

Annotations already declare readOnlyHint=true, so the description adds little behavioral context beyond the content list. It doesn't disclose any side effects or permissions, but the read-only nature is clear.

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

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

The description is a single, well-structured sentence that front-loads the purpose and lists the specific topics. 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?

For a zero-parameter reference tool with no output schema, the description adequately covers what the tool provides. It lists the key conventions, making it complete for its purpose.

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

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

The tool has zero parameters and 100% schema description coverage. The description does not need to add parameter information. Baseline 4 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 explicitly states what the tool returns: 'page-building conventions reference' with detailed contents (output shape, coordinate system, event vocabulary, workflow). This clearly distinguishes it from sibling tools like get_page_schema or list_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?

The description implies the tool should be used when conventions are needed but does not explicitly state when or when not to use it. No alternatives or exclusions 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?

The description adds substantial behavioral context beyond annotations: it calls a public API, resolves to outlined variant with filled fallback, normalizes underscores, and details the return object shape. It also provides rendering instructions (svgMask, styles.background, square box). This goes well beyond the readOnlyHint/openWorldHint annotations.

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

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

The description is dense and well-organized, starting with purpose, then usage, parameter details, return format, and rendering. While it is long, every sentence provides valuable information. Slight trimming could improve conciseness, but the structure is logical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 and no output schema, the description covers purpose, parameter semantics, return format, and even post-processing (rendering). It is fully complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% for the icons parameter, but the description adds significant meaning: acceptable formats (ms:, fa:, Iconify ID, bare name), normalization (underscores to hyphens, outlined variant), and example values. This substantially enhances understanding beyond the schema 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 tool resolves icon-font names into inline SVG markup via the public Iconify API. It specifies the resources (Material Symbols/Font Awesome names, Iconify IDs) and differentiates from siblings like ingest_html/ingest_url which surface the icons but do not convert them to SVG.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the tool: after ingest_html/ingest_url to get SVG for icon references like 'ms:verified' or 'fa:chart-line'. It includes acceptable input formats and normalization rules. However, it does not explicitly state when not to use it or describe alternatives beyond the implicit 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?

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds value by explaining the compact behavior, the re-hydration process, and authentication requirements (WEBCAKE_API_BASE, WEBCAKE_JWT). No contradictions.

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

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

The description is fact-rich and front-loaded with the main purpose. It could be slightly more concise, but every sentence provides necessary 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?

Given the complexity (compact mode, output structure, auth), the description covers the output fields, behavior, and prerequisites. Though no output schema exists, the textual description is sufficient.

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

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

Schema coverage is 100%, and the description adds significant meaning to the compact parameter by describing what 'compacted' entails and the re-hydration workflow. The page_id parameter is adequately covered.

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

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

The description clearly states it fetches a page's decoded source tree, listing the structure (page, popup, etc.). It distinguishes from sibling get tools like get_page_schema by focusing on the full source tree.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 workflow context, explaining how to edit the compacted output and send it back to update_page/patch_page. However, it does not explicitly state when to avoid alternative tools like get_page_schema.

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

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

Annotations already declare readOnlyHint=true, so the description's statement of returning full JSON Schema aligns and adds detail (Draft 2020-12, structure). No hidden behaviors or contradictions.

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

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

Single sentence, front-loaded with verb and object, no wasted words. Perfectly concise for the tool's simplicity.

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

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

For a zero-parameter read-only tool, the description fully covers what it does and what it returns. No output schema exists but the description specifies the return structure sufficiently.

Complex tools with many parameters or behaviors need more documentation. 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 100% with empty schema). Baseline is 4 as per rule. Description adds no param info because none are 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 uses specific verb 'Returns' and resource 'full JSON Schema of a Webcake page source object' with clear purpose 'for structural reference and validation'. It distinguishes from siblings like validate_page or get_page by stating it returns the schema itself.

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

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

The description clearly implies when to use (when needing schema for reference/validation) but does not explicitly mention when not to use or name alternatives. However, the context of sibling tools and the tool's name make the use case unambiguous.

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

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

Beyond the readOnlyHint annotation, the description details non-destructive parsing behavior, auto-detection and conversion of absolute-canvas exports, auto-repair of garbled text, and image handling policies, fully disclosing tool behavior.

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

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

The description is verbose and dense, containing much information in a single paragraph. Though well-organized with bold emphasis, it could be more concise without losing critical 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?

Given the complexity of parsing HTML with multiple modes and integrations, the description is comprehensive: it covers output structure, error handling, cross-tool interaction (upload_images, create_page, add_section), and accounts for different builder formats, leaving no gaps.

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

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

Schema coverage is 100%, but the description adds substantial meaning: it explains how detail and intent affect output, the sections parameter's context for canvas mode, and the impact of image handling, going well beyond the schema definitions.

Input schemas describe structure but not intent. Descriptions should explain 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 parses an HTML string into a reference AST, detailing the output components (title, description, sections, etc.) and special handling for absolute-canvas exports, distinguishing it from sibling tools like ingest_url.

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

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

The description provides explicit guidance on when to use different detail levels (compact vs full), the intent parameter (adapt vs clone), and mentions auto-detection of absolute-canvas exports, image re-hosting requirements, and mojibake auto-repair, leaving no ambiguity about usage.

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

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

Discloses timeout (10s), size cap (2MB), no JS execution, auto-detection of absolute-canvas exports, and return behavior (warning for empty body). Annotations readOnlyHint and openWorldHint are consistent; description adds rich 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?

Very long and detailed, covering many scenarios. While well-structured with logical flow, the verbosity could be reduced without losing critical 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?

Completely covers return values (AST, warning, deterministic source), image handling (re-host via upload_images), and edge cases (client-rendered, truncated canvas). No output schema, but description makes tool usage clear.

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

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

Schema coverage is 100%, but description adds extensive value: details on detail levels (compact vs full with design token extraction), intent (adapt vs clone), and sections (absolute-canvas mode, truncation handling).

Input schemas describe structure but not intent. Descriptions should explain 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 a public webpage and parses it into a reference AST, distinguishing from ingest_html and noting fallback to screenshot for client-rendered 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?

Provides explicit guidance on when to use (e.g., detail:'full' for clone-faithful rebuilds) and when to fall back (client-rendered pages), and names related tools like ingest_html, upload_images, search_images.

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

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

Annotations include readOnlyHint=true and openWorldHint=false. The description aligns by stating 'Pure math — no env, no network.' It adds behavioral details: honours page margins, returns results in same order, and flags off-canvas/over-wide inputs via 'notes'. No contradictions.

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

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

The description is well-structured with a clear hierarchy: purpose, modes, constraints. Each sentence contributes useful information. Slightly lengthy but justified given the complexity of the tool.

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

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

Given 16 parameters, high schema coverage, and no output schema, the description explains the core functionality, input patterns, and constraints. It could address error handling or edge cases like overflow, but overall it is sufficiently complete for an AI 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 already covers 100% of parameters with descriptions. The description adds meaning by explaining mode behaviors (e.g., 'row stacks on mobile'), the relationship between 'count' and 'items', and default values, enriching comprehension 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 explicitly states it computes exact on-canvas coordinates for both breakpoints, lists four distinct layout modes, and distinguishes from sibling tools by emphasizing its pure math nature. It clearly defines what the tool does.

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

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

The description advises against hand-computing or writing scripts, implying when to use. It explains the four modes and their stacking behavior, providing context. However, it does not explicitly state scenarios where this tool would be inappropriate or suggest alternatives, leaving minor room for interpretation.

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

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

Annotations already declare readOnlyHint=true, and description adds detail about output format (grouped by category, summary, container info). No contradictions; it enhances 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?

Single sentence with no wasted words, front-loaded with action and resource, structured with logical groupings of output 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?

Given no parameters and annotations, the description fully covers what the tool does and returns. No output schema, but description explains output content adequately.

Complex tools with many parameters or behaviors need more documentation. 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, and schema coverage is 100% (empty). Description does not need to add parameter information; baseline for 0 params is 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', the resource 'supported element types', and specifies grouping by category, one-line summary, and container flag. It distinguishes from sibling tools like 'get_element' (singular) and 'new_element' (creation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 browsing all element types but does not explicitly state when to use or not use this tool versus alternatives. Context from sibling tools suggests it's for overall 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?

Annotations already declare readOnlyHint and openWorldHint, so the bar is lower. The description adds value by specifying output fields and the default org concept, plus authentication requirements (WEBCAKE_API_BASE + WEBCAKE_JWT). No contradictions.

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

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

Two sentences deliver purpose, output fields, a usage hint, and authentication prerequisites. No wasted words; front-loaded with 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 parameterless list tool with annotations, the description fully covers what is returned, the significance of the default org, and environment requirements. No gaps given the tool's simplicity.

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

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

Input schema has zero parameters and 100% coverage. Per guidelines, baseline is 4. The description does not add parameter detail, but none is 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 tool 'Returns the account's Webcake organizations' with specific fields (id, name, is_default). It adds context about the default org, distinguishing it from other organization-related calls. No sibling tool duplicates this purpose.

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

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

The description explains when to use this tool (to get organizations, especially the default org for page routing) but does not explicitly exclude alternatives or compare to siblings. The context is clear, but lacking exclusions prevents a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds value by specifying the ordering (most-recent first) and the exact fields returned. No contradictions with annotations.

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

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

The description is two sentences, front-loaded with the core purpose, and every word contributes. No extra 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?

The description covers purpose, fields, and ordering, but lacks information on pagination, limits, or whether the list is complete. Given no output schema, missing pagination details reduces completeness for a list operation.

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

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

The tool has no parameters, and schema coverage is 100% (no properties). The description does not need to add parameter meaning beyond what the schema provides; baseline for 0 parameters is 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 tool lists pages owned by the account, specifies returned fields (id, name, organization_id, updated_at), and indicates ordering (most-recent first). However, it does not differentiate from sibling tools like find_pages, which may filter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 only usage guidance is authentication requirements (WEBCAKE_API_BASE and WEBCAKE_JWT). No context on when to use this tool versus alternatives like find_pages or get_page, and no exclusions or prerequisites 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?

Description adds value beyond annotations by detailing the return structure (fresh id, seeded styles, specials) and the correct usage pattern. Annotations already indicate readOnlyHint, which is consistent.

Agents need to know what a tool does to the 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 that is front-loaded with purpose, followed by concise usage guidance. No unnecessary words.

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

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

Given no output schema, the description adequately explains the return value and usage. For a tool with 2 simple params, it covers all necessary information.

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

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

Both parameters have schema descriptions. The description reinforces the 'type' parameter's role and clarifies that 'name' overrides the layer label. Adds meaningful context 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 it returns a default element node for a given type in the SPARSE authoring shape. Differentiates from sibling tools like get_element by focusing on generating a fresh node.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 instructions on how to use the returned node: fill in specials and coordinates, omit certain fields. Lacks explicit when-not-to-use but context makes it clear this is for initial element creation.

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

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

Annotations already declare readOnlyHint=true, so no side effects. The description adds value by detailing the return shape's structure and how width parameters affect settings.width_section, giving behavioral context beyond the annotation. Consistent with openWorldHint=false.

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

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

Single paragraph, front-loaded with purpose and return shape. Slightly verbose in repeating the shape, but each sentence adds value (width guidance, coordinates context). Could be trimmed slightly, but overall well-structured for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 3 optional params, no output schema, and annotations providing safety, the description covers the return structure, width behavior, and usage context. It is complete enough for the agent to select and invoke correctly, with no obvious gaps.

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

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

Schema covers all 3 parameters with descriptions. The description adds meaning beyond schema by explaining usage rationale (e.g., choosing 1200 for wide/editorial pages, 960 for narrow) and how parameters set canvas width upfront. This enhances the agent's understanding beyond enum 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?

Description clearly states it returns an empty page skeleton, specifies the shape (page:[], popup:[], settings, options, cartConfigs), and distinguishes from siblings like create_page by being a read-only template initializer. The verb 'returns' and resource 'top-level page source' 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?

Provides explicit guidance on when to use desktopWidth 1200 vs 960 (wide/multi-column vs narrow/simple, cloning reference), implying use as a starting template. Does not explicitly state when not to use or give alternatives, but context from sibling tools and the description's conditional advice is sufficient.

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

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

Beyond the annotations, the description discloses the default dry_run=true no-write behavior, that dry_run=false saves, that the whole merged tree is validated and blocks on errors, that update ops shallow-merge and cannot delete stray keys, that empty patches trigger the retry commit path, and that credentials are required differently for draft_id vs page_id. No contradiction with readOnlyHint=false/destructiveHint=true is present.

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

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

The description is front-loaded with purpose and every major behavioral rule is packed in without filler. It is quite long and partially duplicates op semantics already present in the schema, so it does not quite reach a perfect conciseness score, but the draft/commit/retry complexity justifies most of the length.

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

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

For a complex 5-parameter tool with no output schema, the description covers target selection, draft provenance, op semantics, dry-run default, validation behavior, auth requirements, and retry path. The only gap is that the exact response/preview shape is not described, but everything needed to invoke the tool correctly is covered.

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

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

Even though the schema already documents all 5 parameters at 100% coverage, the description adds operational meaning: op defaults to 'update', replace is needed for additional-properties errors, sparse elements are hydrated from factory defaults, omitted patches mean commit-the-cached-draft, and page_id can override the stored target for draft patches. This materially helps an agent build correct argument objects.

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

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

The opening sentence states a specific verb and resource: 'Edits a page by element id WITHOUT re-sending the whole source', and immediately distinguishes it from a whole-source update path. It also clarifies the two target kinds (live page vs cached draft), so an agent can tell this tool apart from update_page and sibling create/edit tools.

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

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

The description explicitly positions this as the fix-after-error and retry path: 'Use this to fix the elements a failed create_page/update_page/add_section reported instead of rebuilding.' It also explains when to commit a cached draft as-is with empty patches, when dry_run should be set, and when page_id vs draft_id apply. This is strong usage guidance with clear alternatives.

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

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

The description goes far beyond the annotations (destructiveHint, openWorldHint) by detailing the build process, domain resolution, preview link expiration, fallback to legacy route, and required environment variables. No contradiction with annotations.

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

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

The description is lengthy but every sentence provides necessary detail for complex behavior. It is front-loaded with the main purpose. A slight reduction in verbiage could improve conciseness, but the current structure is justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 (4 parameters, no output schema, destructive action), the description is remarkably complete: it covers build process, domain resolution, dry_run, fallback, preview expiration, and required environment variables. No significant gaps.

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

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

With 100% schema description coverage, the description still adds significant meaning: e.g., for custom_domain it explains 'OMIT to reuse...', for dry_run it clarifies 'Set false to actually publish'. This enriches the schema definitions.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Publishes an EXISTING page LIVE') and the resource (page via editor's publish_html route). It distinguishes from sibling tools like create_page and update_page by emphasizing the 'existing' and 'live' aspects, providing specific technical details about the build process.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 extensive when-to-use guidance, including dry_run default, domain handling, and fallback behavior. It explains the purpose of each parameter and scenarios like omitting custom_domain. However, it does not explicitly mention when to use sibling tools as alternatives beyond the implied 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?

Annotations already declare readOnlyHint and openWorldHint, so the tool is read-safe and open-world. The description adds critical behavioral details: the underlying engine (Microlink), rate limiting (HTTP 429 with fallback to skip), preview expiration, and the need for a self-hosted Playwright for tiles. No contradictions.

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

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

The description is comprehensive but somewhat verbose. It is well-structured with clear sections (AGENT-FIRST, ENGINE, NOTE, TALL PAGES) and front-loads the core purpose. However, some details could be more concise without losing utility.

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

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

While the description covers many aspects, it does not fully specify the normal success response format (e.g., what fields are returned, how the image is encoded). It mentions an 'ok' field for errors but not the success structure. Given no output schema, this leaves a gap in understanding what the tool returns.

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

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

The schema covers all 5 parameters with descriptions, but the description adds practical guidance beyond the schema: for width (recommended values), for tiles (requires Playwright, fallback), and for url/page_id precedence. This extra context improves usability significantly.

Input schemas describe structure but not intent. Descriptions should explain 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: render a public URL to a PNG for visual comparison, specifically for the fidelity-check step in a clone loop. It distinguishes between using a page_id or a URL, and mentions it's an alternative to the agent's own screenshot capability, making it unique among siblings.

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

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

It explicitly tells when to use (for visual fidelity check) and when not to (if agent has screenshot capability). It provides limitations: rate limit (~50/day), preview expiration (~10 min), and fallback behavior for tiles. It also suggests alternatives (agent's own tool) and best practices (call promptly after create/publish).

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

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

Adds context beyond annotations: explains the use of a hosted proxy, optional API key, sizing guidelines to avoid pixelation or bloat, and pick behavior. No contradictions with readOnlyHint and openWorldHint.

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

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

Long but well-structured with clear sections (sizing, batch mode, exclusions). Front-loaded with main purpose. Every sentence adds value, though could be slightly trimmed.

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

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

Comprehensive coverage for a tool with 8 parameters and no output schema. Explains response fields, sizing strategy, authentication, and when to avoid use. Fills gaps left by missing 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?

Schema coverage is 100% with descriptions. The description adds extra context for parameters like pick, queries, and orientation, such as suggesting when to use batch mode and size selection tips. Baseline 3 raised to 4 due to added 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 specifies the tool searches Pexels stock photos by English subject queries, returns hotlinkable URLs, avg_color, and photographer info. It distinguishes from sibling tools like upload_images and get_icon_svg by stating when to use each.

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

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

Explicitly states when to use (image slots with no source image) and when not (use upload_images if user supplies images). Also provides guidance on batch mode with queries parameter for multiple images.

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

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

Beyond the destructiveHint annotation, it reveals validation-first behavior, the default dry_run=true mode with draft caching and token masking, retry semantics for timed-out/failed updates, and the required WEBCAKE_API_BASE + WEBCAKE_JWT context. No contradiction with the annotations.

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

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

The description is dense and front-loaded, starting with the core overwrite operation, then validation, dry-run behavior, draft_id retry, and credentials. The draft_id explanation is somewhat redundant with the schema field description, and the paragraph could be split into scannable points.

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

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

For a destructive, credential-requiring update tool with no output schema, it covers validation, dry-run default, draft_id retries, and authentication. However, it leaves the exact response shape unspecified and does not resolve how dry_run=false is actually passed given the schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful context for draft_id reuse and the dry-run default, but the described dry_run=true/false switch has no corresponding schema property while additionalProperties is false, and the draft_id sentence largely mirrors 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 states a specific verb and resource: 'Overwrites an EXISTING page's source.' The parenthetical 'source-only; re-render in the editor for preview/publish' clearly distinguishes this tool from preview/publish workflows and from partial-edit or create sibling tools.

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

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

It gives clear context that this is the full source-overwrite operation, defaults to a validating dry run, and requires an explicit dry_run=false to actually save. It does not explicitly name alternatives like patch_page or validate_page, so it misses the explicit when-not-to-use bar for a 5.

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

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

Discloses all key behavioral traits beyond annotations: 200 MB cap, parallel processing of 20 entries, collection filing vs public CDN fallback, dry_run behavior, local path restrictions per transport mode, and that it does not touch page data. No contradiction with annotations.

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

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

Front-loaded with core purpose, but the description is lengthy due to comprehensive detail. While every sentence adds value, conciseness is slightly sacrificed for completeness.

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

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

Fully adequate given complexity: no output schema, but description explains return values (images map, collection flags), error cases (organization_required), and all edge cases. Leaves no significant gap.

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

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

Adds extensive meaning beyond input schema: for urls, details accepted formats and limits; for dry_run, explains default false and preview behavior; for in_folder, clarifies scope and fallback; for organization_id, covers required conditions and auto-select logic. Schema coverage is 100%, but description amplifies significantly.

Input schemas describe structure but not intent. Descriptions should explain 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 conversion of external image URLs/data URIs/local paths into Webcake-hosted URLs via download and re-upload. Differentiates from sibling search_images with explicit directive to use that tool for stock photos.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 specifies when to use (page built from reference HTML/URL, user-supplied images, local files) and when not (stock photos). Also covers crucial do-nots like never uploading local files to third-party hosts, and details on dry_run and organization handling.

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?

Automatically fixes layout defects deterministically and returns auto_fixed, errors, and warnings. This adds behavioral context beyond readOnlyHint annotation, though persistence side effects are not detailed.

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

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

The description is lengthy and dense, listing many validation rules in a single paragraph. It could be more structured (e.g., bullet points) for readability, though it is front-loaded with the main 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?

Explains return structure (auto_fixed, errors, warnings) but lacks detailed output format (e.g., error object fields). Given no output schema, more completeness would be beneficial.

Complex tools with many parameters or behaviors need more documentation. 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 describes the 'page' parameter adequately. The tool description adds behavioral context but does not enhance parameter-specific meaning beyond what the schema provides.

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

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

The description clearly states the tool validates a page source against schema, semantic rules, and form-data bindings, with auto-fix behavior. It distinguishes itself from sibling tools like get_page_schema and create_page.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 during page creation/editing but lacks explicit guidance on when to use versus alternatives like update_page or patch_page. No 'when-not' or direct comparison.

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