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

Annotations already mark it as a mutating but non-destructive operation; the description adds behavioral context beyond that by disclosing that one call can build a whole nested subtree. It does not cover edge behavior such as insertion index or dry-run semantics, but those are less central.

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 tightly written sentences; the primary action is front-loaded and the second sentence earns its place by conveying the efficient batching behavior. No filler or redundant restatement of the schema.

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

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

For a tool with four parameters, a nested spec object, no output schema, and no parameter descriptions, this description is not enough to invoke it correctly. The agent still lacks semantics for dry_run, index, and the required spec.type values.

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 burden is on the description. It only clarifies parent_id ('under a parent') and spec.children ('pass children'), while index, dry_run, and the meanings of spec.type/name/style/config/specials remain unexplained.

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 operation — adding an element or nested subtree under a parent — with the verb 'Add' and the target resource. It also distinguishes itself from siblings like sb_set/sb_move by focusing on creation under a parent, and the nested/subtree mention is a unique selling point.

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 guidance on when to use the tool: pass children in one call rather than calling once per node, so the agent knows how to build a full section. It doesn't explicitly name sibling alternatives or exclusion conditions, so it falls just short of full guidance.

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

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

Annotations already signal non-read-only/open/destructive behavior; the description adds meaningful specifics: dry-run default that sends nothing and shows the request, pick/max_items transformations, and a 60 KB list truncation that announces itself. No contradiction with annotations.

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

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

Two sentences, front-loaded with the core purpose, then compactly covers defaults and guardrails. Every sentence earns its place and nothing is redundant.

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

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

For an open-world API executor with no output schema, the description covers the essential safety default and list behavior, and references the source of ids. It does not describe response/error behavior, but this is a modest omission given the open-world nature.

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 29%; the description explains pick, max_items, and dry_run, and shows the id format by example. However, body, query, and path_params are not semantically described beyond their raw object/string types, so the low-coverage gap is only partially compensated.

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

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

States a specific verb-resource pair ('Execute one operation from sb_api_find') and clearly distinguishes it from the discovery tool sb_api_find. The id format example reinforces what operation means.

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

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

The description makes clear the operation comes from sb_api_find, so the intended workflow is find-then-execute. It does not explicitly state when not to use it, but the source reference and dry-run default provide 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?

With readOnlyHint=true, the description correctly reinforces the read-only nature. It adds valuable behavioral context: search returns one line per match, the full call sheet includes parameter types, credential requirements, and body fields with 'traps' from doc comments, which is beyond what annotations provide. The phrase 'read off the handler that decodes them' hints at data source, but it could be clearer about the output format.

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 sentence that efficiently front-loads both modes and their parameters, with no wasted words. It packs key details about output and scope 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 (two modes, 4 params, no output schema), the description provides a complete picture: it explains what each mode returns, the scope (all operations), and behavioral nuances. It lacks explicit guidance on when to use this versus siblings like sb_api_call, but otherwise covers the essentials.

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 baseline is 3. The description adds semantic meaning by explaining that 'query' is a natural language intent and 'id' returns a 'full call sheet' with specific contents (types, credential, body fields with traps), exceeding what the schema alone conveys. It also implies 'tag' and 'limit' usage but does not elaborate on them, so it's above baseline but not perfect.

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 two specific modes: searching platform API operations by intent (with query, returning one line per match) and reading one operation's full call sheet (with id). It distinguishes itself from siblings like sb_api_call by focusing on discovery/documentation rather than execution, and the mention of 'all 524 operations' gives concrete scope.

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

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

The description implies when to use each mode (query for search, id for full details) and notes that it reaches all operations. However, it does not explicitly state when to choose this tool over alternatives like sb_api_call or sb_catalog_search, leaving some inference required.

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 (readOnlyHint=false, destructiveHint=false) provide minimal behavioral info. The description adds only a cryptic hint about the action parameter ('makes a button a purchase control') but does not disclose side effects, reversibility, permissions, or error behavior. For a tool that performs a binding operation, this is a significant gap.

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

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

The description is very concise (two sentences) and front-loads the core purpose. Every sentence adds something, but the second sentence is under-specified and could be clearer. It is appropriately sized for a simple tool, though it lacks important 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 tool with 5 parameters (3 required) and no output schema, this description is insufficient. It does not explain the id or dry_run parameters, what the binding actually does to the page, whether it is reversible, or what the expected return is. An agent would need to inspect the schema and make many assumptions.

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% (field, action, source are described; id and dry_run are not). The description adds a small extra hint about action, but it is vague compared to the schema's own description ('Pass product.id + specials.boundProductId'). Overall, the description does not substantially compensate for the undocumented 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 states a specific verb ('Bind') and resource ('node to real store data'), and clarifies the outcome (shows actual products, not placeholder text). However, it does not explicitly differentiate this tool from its many siblings like sb_connect or sb_node_read, so an agent must infer the distinction.

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

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

No guidance is given on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or conditions. The agent is left without direction on selecting this tool among the 30+ siblings.

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

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

The description discloses that each match returns four fields and that detail:true adds platform AI hints, which is useful behavior beyond the readOnlyHint annotation. It does not explain what the four fields are, but it already goes beyond what the annotation alone provides.

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

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

Two sentences with no filler. The core purpose is front-loaded, and the detail:true versus sb_traits_for guidance is packed efficiently into the second sentence.

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 read-only annotation and simple schema, the description is mostly complete: it states what to search by, mentions the result shape, and routes follow-up actions. The absence of an output schema makes the 'four fields per match' note valuable, though the exact field names are left unspecified.

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 67%; detail and limit have schema descriptions, but query does not. The description adds meaning to detail ('platform's AI hints') and implies query semantics via the tool purpose, but it does not clarify limit behavior or query formatting, so it only partially compensates.

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

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

The description opens with a specific verb and resource: 'Find an element type by what you want it to do.' It clearly distinguishes the search use case from the sibling sb_traits_for, which is for reading trait details after choosing an element.

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

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

It provides actionable guidance: pass detail:true for AI hints, or use sb_traits_for after selecting a match. This gives a clear context for using the tool and names a relevant alternative, though it does not enumerate exclusions for every sibling.

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 annotation already marks the call read-only, so no safety contradiction exists. The description adds meaningful behavior beyond that: it authenticates through environment variables unless credentials are passed explicitly, and it is intended as the initial bootstrap 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?

Two short sentences with no filler; the main purpose, ordering requirement, and credential fallback are each stated once 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?

For a simple two-parameter bootstrap tool, the description covers purpose, output ('list the sites'), ordering, and credential handling. It remains slightly incomplete because it does not clarify whether login is a persistent session or how it relates to sb_site_list, but no output schema exists so the stated output is still 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 0% and the schema gives only type names, but the description clarifies that email and password override environment-provided SB_EMAIL and SB_PASSWORD. This is useful semantic info for deciding whether to pass the parameters at all.

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 action ('Log in and list the sites this account can operate') with a clear resource. It is not a tautology and is easy to understand, but it does not explicitly distinguish itself from the nearby sb_site_list tool, which likely also relates to listing sites.

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 instruction 'Call this first' gives explicit ordering guidance, and the note about reading SB_EMAIL and SB_PASSWORD tells the agent when parameters can be omitted. It does not state when not to use it or name alternatives such as sb_site_list, so it falls short of full alternative routing.

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

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

Annotations already indicate this is not read-only and not destructive. The description adds useful behavior beyond that: the copy gets fresh ids, includes the full subtree, and is placed immediately after the original. It does not disclose return values or side effects, but the core behavioral profile 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?

Two short sentences: the first is technically precise and front-loaded, the second adds a relatable use case. The second sentence is somewhat stylistic but not bloated; no essential structural waste.

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

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

For a tool with no output schema and an undocumented parameter, the description is not complete. It leaves 'dry_run' undefined, and since there is no output schema, the agent is not told what the tool returns. The common happy path is inferable, but edge usage is under-specified.

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 compensate for both parameters. It implies that 'id' identifies the node to copy, but it never explains the 'dry_run' parameter or how it affects the operation. An agent cannot fully understand parameter semantics from this definition.

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 ('Copy'), the exact resource ('a node and everything under it'), and key behavioral details ('under fresh ids, right after the original'). This clearly distinguishes duplication from siblings like sb_move or sb_remove without needing to open the schema.

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

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

The description gives a concrete designer use case ('build one card, duplicate it twice'), which implies when to use it. However, it does not explicitly state when not to use it or contrast it with alternatives like sb_move or sb_add, so the agent must infer the appropriate 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 cover readOnlyHint=false and destructiveHint=false, so the description's bar is lower. It does not contradict annotations and adds a small amount of behavioral context through examples of possible actions. However, it does not disclose whether the action replaces existing settings, whether it is reversible, or any side effects beyond setting a click action. It adds minimal value beyond what annotations already provide.

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

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

The description is a single, front-loaded sentence that states the main purpose immediately, then gives illustrative examples and a clear exclusion. There is no filler, and the structure is efficient and easy to parse.

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

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

Given the tool has 5 parameters (2 required, one nested object), no output schema, and no annotation of behavior beyond read/destructive hints, the description is too thin. It fails to explain key aspects like the action format, payload usage, dry_run semantics, trigger defaults, or what success/failure looks like. An agent would likely need to inspect the schema or guess, making the description incomplete for safe and correct invocation.

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

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

Schema description coverage is only 40% (action and trigger have some description), and the tool description provides no additional parameter meaning. It does not explain what 'id' refers to, what values 'action' accepts (beyond the schema's vague hint), the purpose of 'payload', or the effect of 'dry_run'. With low schema coverage, the description should compensate but does not, leaving most parameters semantically undefined.

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

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

The description clearly states the tool's function: assigning a click action to a node, with concrete examples (open cart, go to a page, open a pop-up). It also explicitly distinguishes itself from sb_bind for purchase actions, making the purpose unambiguous and differentiating it from 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?

The description provides an explicit when-not-to-use instruction: 'A purchase is not one: use sb_bind action.' This gives clear guidance on choosing the right tool for a specific case. The general usage (assigning click actions to nodes) is also implied by the opening phrase, giving sufficient context for an agent to select it appropriately.

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

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

Annotations already declare openWorldHint=true and destructiveHint=false, so safety is partly covered. The description adds meaningful context beyond that: it specifies that content is added as real elements styled with the current page's tokens, clarifies that it is not a clone (source layout and CSS are not copied), and notes that dry run returns what was found. It still omits side effects like image uploads, but the added behavioral detail is solid.

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

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

Three sentences, front-loaded with the core action and target. The subsequent sentences each add a distinct clarification (not a clone; dry run behavior) without repetition or filler.

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

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

For an eight-parameter import tool with no output schema and annotations only covering basic safety, the description gives a good high-level purpose but leaves notable gaps. It does not mention that images are uploaded by default (upload_images=true), the node/section limits, or the site_id parameter, all of which are behaviorally significant for correct invocation.

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

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

Schema description coverage is 63%, so the schema already documents several parameters (url, max_nodes, max_images, upload_images, nav_timeout_ms). The description only adds meaning for dry_run ('returns what was found') and does not explain site_id, max_sections, or provide guidance on the limit parameters, so it neither fully compensates for the coverage gap nor is empty.

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 chain (read a page, add its structure and content) and a clear target (the OPEN page), and it explicitly distinguishes itself from a clone. However, it does not name or differentiate from sibling tools like sb_import_site, leaving the agent to infer the scope difference between an individual page import and a site import.

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 what the tool does but offers no when-to-use guidance, no prerequisites, and no alternatives. It does not say when to prefer this over sb_import_site or other import tools, leaving selection entirely to inference.

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

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

Annotations mark it as a write (readOnlyHint=false), open-world, non-destructive, but the description adds meaningful context beyond them: output pages are DRAFTS, not published, and dry_run returns the page list before any creation occurs. It does not cover auth requirements or rate/timeout behavior, keeping it below the top band.

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

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

Three short, front-loaded sentences: action and scope first, the clone caveat second, the dry-run behavior last. No filler, and every clause carries information the agent needs.

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 13-parameter import with no output schema, the description covers the core concept (source, draft output, dry-run preview) adequately. It omits detail on many knobs (include/exclude, image handling, limits), but the essential mental model for invoking it correctly is present.

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

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

Schema coverage is 69% across 13 parameters, so the schema does most of the documentation. The description adds only indirect meaning — the sitemap-vs-links sourcing hint relates to depth, and the dry-run sentence relates to dry_run — while most parameters remain unexplained in prose. Baseline 3 is appropriate.

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

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

The description gives a specific verb and resource ('Read a WHOLE site from one URL'), explains the sourcing mechanism (sitemap or page links), and states the output artifact (a DRAFT page per page found). It also explicitly contrasts the behavior with a clone, letting an agent separate it from a copying/duplication tool.

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

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

It implies usage through the dry-run note ('Dry run returns the page list before anything is created'), which tells the agent a preview path exists, but it never names alternatives (e.g. sb_import vs sb_page_create) or states when-not to use this tool. Guidance is inferred rather than explicit.

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

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

Annotations already provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds context beyond these: it explains that writes appear live in editors, the agent is shown by API key name, and that it always yields (safe concurrency). It also clarifies authentication requirements (SB_TOKEN or SB_EMAIL/SB_PASSWORD). This is valuable behavioral disclosure without contradicting the annotations.

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

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

The description is three sentences, with the core action and effect front-loaded. It includes relevant details (visibility, naming, concurrency safety, auth) without excessive verbosity. It could be slightly tighter, but it is well-structured and each 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 simple join operation, the description covers the main behavioral aspects, safety, and authentication. It does not describe a return value (no output schema exists), but that is not critical for a side-effect action. It does not mention prerequisites like having a site ID or being connected, but the single parameter and context make this reasonably complete.

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

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

The schema defines a single parameter site_id (string) with zero schema description coverage. The description does not explain what site_id refers to or how to obtain it. It only mentions 'the site's live-edit room' but never explicitly maps site_id to that. Since coverage is 0%, the description should compensate, but it does not. The parameter name is somewhat self-explanatory, but no guidance is given on values or format.

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 action ('Join the site's live-edit room as a visible peer') and explains the observable effect (writes appear in editors, agent shown by API key name). This clearly distinguishes it from siblings like sb_page_open or sb_connect, which handle different operations. The purpose is unambiguous.

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

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

The description notes it 'always yields, so it is safe beside a human,' which implies it's suitable for concurrent use with human editors, but it does not explicitly state when to choose this tool over alternatives or when to avoid it. No comparison to siblings like sb_connect or sb_page_open is given. The guidance is implied rather than explicit.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, so the description does not need to repeat those. It adds valuable context about the platform's own renderer, the outputs (screenshots, boxes, defects), and the node_id framing behavior, which goes beyond the structured annotations. 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 two sentences: the first front-loads the core purpose and outputs, the second gives usage guidance. Every word serves a purpose, with no filler or repetition.

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

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

The description covers the main outputs (screenshots, boxes, defects) and gives purpose, but it does not specify the response structure or how to interpret the defect data. It also omits details on the widths array and with_boxes parameter, leaving some ambiguity for a tool with 6 parameters and 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?

Schema description coverage is 67%, so the baseline is 3. The description adds meaning for url (via published storefront mention), format (jpeg/png), node_id (frames one element), and box_depth (bands and children), but it does not clarify the widths array format or with_boxes behavior, which lack schema descriptions. It partially compensates for the coverage gap 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 tool saves, renders, and returns screenshots at multiple widths, measured boxes, and layout defects, giving a specific verb and resource. It also mentions node_id to frame one element, but does not explicitly contrast with sibling tools like sb_outline or sb_node_read, though the features are distinct enough.

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

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

The description implies usage for visual evaluation with 'Judge your work from these, not from memory,' giving context on when to use it. However, it does not explicitly state when not to use it or name alternatives among the many sibling tools, leaving routing to inference.

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

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

Annotations already provide readOnlyHint=true, so the read-only nature is known. The description adds that it is a library and supports search/filter/pagination, but it doesn't describe the return format, default pagination limits, or any side effects (none expected). Since annotations cover safety, this is acceptable but not rich.

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 starts with the core purpose ('The site's media library'), then provides usage guidance and parameter hints. It is concise and front-loaded, though the phrase 'Reuse an image before adding another' is more of a policy than a functional description, which is acceptable.

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

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

For a read-only listing tool with all optional parameters, the description covers the main usage patterns. However, it doesn't explain the return value, the role of site_id, or default pagination behavior. Since there is no output schema, a bit more detail on what is returned 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?

The schema only documents 'media_type' (with an example). The description covers 'search' (search by name), 'media_type' (filter by type), and 'limit'/'offset' (page with limit/offset). It does not mention 'site_id', which remains undocumented. Given low schema coverage (20%), the description compensates well for most parameters but misses site_id.

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 identifies this as the site's media library and lists operations (search, filter, page) that imply a listing/retrieval tool. It doesn't use an explicit verb like 'list' or 'get', and it doesn't differentiate from sibling list tools such as sb_page_list, but the name 'sb_media_list' clarifies the action.

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 instruction to 'reuse an image before adding another' clearly indicates when to use this tool: to find existing media before uploading new ones. It also outlines usage patterns (search by name, filter by type, page with limit/offset). However, it doesn't explicitly name alternatives like sb_media_upload or state 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?

Annotations establish a non-read-only, non-destructive operation; the description adds valuable behavioral detail beyond them by explaining the return value (URL), accepted input sources, the query/pick search behavior, and the ability to upload several images at once. It does not explain edge effects like dry_run or failure modes, but it remains consistent with the annotated safety profile.

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

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

Three compact sentences front-load the core purpose and then add the necessary source modes and search behavior. There is no filler or repetition; every clause earns its place, and the most important usage guidance is stated early.

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

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

Given a 9-parameter tool with no output schema, the description provides a strong overall mental model: what it does, what it returns for media, the input modes, and batching behavior. However, it leaves several parameters unexplained and does not describe what dry_run or folder_id/site_id do, so it is not fully complete at the invocation 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?

Schema description coverage is only 44%, so the description must compensate. It meaningfully clarifies the key mode semantics (path vs URL vs query+pick, and pick accepting one or many), but it never explains name, dry_run, site_id, folder_id, or orientation. Thus it partially closes the coverage gap but does not fully compensate for the undisclosed 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?

Description clearly states the action ('put an image into the media library'), the resource, and the key output ('get its URL back'). It also distinguishes itself from siblings by naming the downstream tool sb_set and declaring 'The only way to add an image', so an agent can identify it confidently.

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 tells an agent when to use it: to add an image, it takes either a local path, a URL, or a search/query flow. It additionally explains how query and pick work together, and 'The only way to add an image' strongly signals it over alternative siblings. It lacks explicit conditions for when to avoid it, but the guidance is otherwise clear.

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

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

Annotations already indicate this is a mutating, non-read-only operation (readOnlyHint=false) that is not flagged destructive. The description adds the exact behavior—reparenting and index placement—which goes beyond the bare flags. However, it does not disclose side effects such as reordering of siblings, required permissions, or the meaning of dry_run.

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

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

A single, front-loaded sentence with no filler or repetition. Every word contributes to the action and target, making it easy for an agent to parse quickly.

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

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

For a simple action, the description plus schema is minimally sufficient: required parameters are clear and the operation is obvious. It is not complete as a standalone contract because dry_run behavior, return value/output, and guidance among sibling tools are absent, but the core invocation path is understandable.

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 0% schema description coverage, the description must carry parameter meaning. It does map 'a node' to id, 'another parent' to parent_id, and 'at an index' to index. It leaves dry_run completely unexplained and the ordering semantics of index implicit, so compensation is only partial.

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 operation ('Move'), a specific resource ('a node'), and the destination semantics ('to another parent at an index'). This is enough to distinguish sb_move from sibling mutation tools like sb_add, sb_set, sb_remove, and sb_duplicate without needing to open the schema.

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

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

The description gives no explicit when-to-use or when-not-to-use guidance, no prerequisites, and no mention of alternatives. It relies entirely on the verb 'move' to imply the use case, which is below the level of clear 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?

The readOnlyHint annotation already covers the safety profile, and the description adds useful behavioral context by listing what the full node result contains: style, config, specials, per-breakpoint overrides, and bindings. This goes beyond the annotation and sets expectations for the response content, though it does not discuss error behavior or invalid IDs.

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

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

The description is a single front-loaded sentence with a dash-separated list of content categories. Every word adds information, and there is no redundant phrasing or filler.

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

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

For a simple one-parameter read tool with a readOnly annotation and no output schema, the description covers the key invocation context: a single node, full detail, and the major content sections returned. It is nearly sufficient but lacks explicit guidance on when to choose this over sibling read-ish tools like sb_outline, sb_look, or sb_traits_for.

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 0%, and the only parameter 'id' is documented only as a string. The description implies the id identifies a node but does not state its format, how to obtain a valid value, or any constraints. With the schema providing no semantics, the description does not compensate for the gap.

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 'One node in full' and enumerates the content returned (style, config, specials, per-breakpoint overrides, bindings), clearly identifying a single-node read operation. The name and 'one node' scope distinguish it from search/list siblings like sb_catalog_search and sb_page_list, though the description never explicitly uses a verb like 'read' or 'retrieve'.

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

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

The phrase 'One node in full' implies this tool is for retrieving complete node details rather than just outlines or traits, but there is no explicit when-to-use guidance or comparison with read-like siblings such as sb_outline, sb_look, or sb_traits_for. Usage context is implied, not stated.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds useful behavior: it returns a compressed tree, never the raw document, and reveals the included node attributes. It does not cover depth-related behavior, but the read-only nature and output scope are clearly communicated.

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 short, front-loaded with the core idea, and every sentence earns its place. It efficiently communicates what the tool returns and what it never returns, without unnecessary fluff.

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

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

For a simple read-only outline tool with one optional parameter and no output schema, the description covers the return shape and the key non-behavior. The main gap is the missing semantics of the depth parameter, but the overall context is still adequate for an agent to use the tool correctly in common 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 0%, and the description does not explain the depth parameter at all. While the schema gives the parameter name, type, and bounds, the agent is left to infer what the depth controls and what the default behavior is when omitted. The description should compensate for the lack of schema descriptions but does 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 that the tool returns the open page as a compressed tree and lists the exact fields included. It distinguishes the output from the raw document of the page, which differentiates it from raw page retrieval, though it does not explicitly name sibling alternatives.

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

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

The description gives clear context: use this when you need a compact structural overview rather than the raw page JSON. The explicit warning 'Never the raw document' effectively tells the agent when not to expect full content, but it does not name specific sibling tools or elaborate on when to choose 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?

Annotations declare readOnlyHint=false and destructiveHint=false, but the description adds little beyond that. It mentions 'seed:false for blank' and 'Any other type is empty', but these are cryptic and do not clarify side effects, required permissions, or the nature of the write operation. No contradiction exists, but disclosure is 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?

The description is a single dense, cryptic sentence that is hard to parse. It front-loads jargon ('store type', 'bound buy box', 'ROOT') without definitions. It is not concise in a helpful way; it sacrifices clarity for brevity.

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 11 parameters, a nested object, and no output schema, the description is severely inadequate. It does not explain the full creation flow, what happens to each page type, how routing works in practice, or any post-creation effects. An agent cannot reliably call this tool based on the description alone.

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 45% (5 of 11 params have descriptions). The tool description adds some meaning for 'seed' (blank page) and 'type' (route mapping), but it does not compensate for the many undocumented parameters like 'slug', 'site_id', 'dry_run', or 'settings'. The added value is insufficient for the low schema coverage.

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

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

The description never explicitly states that this tool creates a page. It discusses 'store type', documents, routing, and references to sb_page_open, but the primary action (creating a page) is only implied. The verb is absent, making the purpose vague and confusing.

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

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

There is no clear guidance on when to use sb_page_create versus alternatives. It mentions sb_page_open but only in the context of seeding roots, not as a decision point. No conditions or exclusions are provided, leaving the agent to guess.

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

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

The readOnlyHint annotation already marks this as read-only, and the description adds the output shape (slug and live status). It does not mention ordering, pagination, or behavior when site_id is absent, but those are not major concerns for a simple list 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 a single concise sentence with no redundant wording, and the core purpose is front-loaded.

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

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

For a simple list tool, the description provides the output fields and read-only nature, but it omits the only parameter from the schema and does not clarify usage boundaries relative to sibling tools. 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 input schema has one optional site_id parameter, but the description does not clearly explain its meaning, whether it filters results, or what happens when it is omitted. The phrase 'on the site' gives some context but leaves a significant gap in parameter understanding.

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

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

The description clearly identifies the resource (pages) and the nature of the output (all pages with slug and live status), even though it uses the declarative 'Every page' rather than an explicit verb like 'List'. It is reasonably distinct from sibling tools like sb_page_open and sb_page_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?

The description implies this is the tool to call when all pages and their live status are needed, but it does not explicitly state when to prefer it over alternatives such as sb_page_open, sb_page_create, or sb_site_list, nor does it mention the effect of omitting site_id.

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

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

While the readOnlyHint annotation declares safety, the description adds behavioral context by explaining the tool is a prerequisite for mutations and returns an outline. It does not explicitly state it is read-only, but the annotation covers that.

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

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

The description is two concise sentences, front-loaded with the primary purpose and followed by clear usage instructions. No filler or redundant information.

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

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

The description provides sufficient context for a straightforward tool: it explains when to call it and how to obtain identifiers. It does not detail return format or error cases, but these are not critical for an outline-returning 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?

The schema has no parameter descriptions, and the description only indirectly hints at page_id's purpose via the reference to finding page IDs. site_id is completely unexplained, leaving agents to infer its meaning.

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

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

The description clearly states the action (open a page for editing) and the return value (outline), and distinguishes it from sibling tools by specifying it should be called before mutation operations and referencing how to find page IDs.

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 the tool ('Call before any sb_add / sb_set / sb_move / sb_remove') and provides guidance on obtaining page IDs via sb_api_find.

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 destructive and idempotent behavior; the description adds valuable transparency by explicitly calling out the cascading republish side effect.

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

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

The description is concise and front-loaded, with no redundant wording; the cascade note is purposeful and directly relevant to the tool's 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?

The description covers the main purpose and an important side effect, but it omits parameter semantics, especially dry_run and site_id, so it is not fully complete for invocation.

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

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

Schema descriptions are absent and the description does not explain page_id, site_id, or dry_run, leaving parameter meaning mostly to inference from names.

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

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

States a specific action ('Compile the draft into the live page') with a clear subject and verb, and the cascade explanation helps distinguish it from related sibling tools.

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

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

The intended use is implied by the description, but it does not explicitly mention when to prefer this tool over alternatives 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?

Annotations already mark this as destructive and non-read-only, so the description's core mutation is consistent. It adds valuable behavioral context beyond annotations by explicitly disclosing the cascading 'whole subtree' effect, which is the most important consequence of this operation. It stops short of full transparency because it does not mention dry_run behavior, irreversibility, or return value, but the key surprising behavior is disclosed.

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

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

The description is one short, front-loaded sentence with no filler; it places the action verb first and immediately gives the removal scope. Every word contributes to meaning.

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

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

For a simple destructive tool, the core behavior and scope are stated, and the destructive annotation covers the safety profile. However, the optional dry_run parameter—likely the only safe way to preview the cascading removal—is not mentioned, and there is no output schema to describe what the tool returns. An agent could still call it correctly, but not with full understanding of its safety options.

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 0% schema description coverage, the description must compensate, but it only indirectly clarifies that `id` identifies the node to remove. The `dry_run` parameter is not addressed at all, and neither parameter gets explicit meaning beyond its name and type. The description leaves the agent to guess whether dry_run previews deletion or has some other effect.

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

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

The description uses a specific verb ('Remove') and names the exact resource ('a node and its whole subtree'), clearly distinguishing this destructive operation from siblings like sb_move, sb_set, sb_add, or sb_duplicate. There is no ambiguity about what action the tool performs.

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

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

The description implies use when a node and all of its descendants need to be deleted, which is reasonable guidance from the action verb. However, it does not explicitly state when to prefer alternatives or note that the cascade is the key reason to choose this tool over a more targeted mutation. No exclusions or alternative routing are provided.

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

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

The annotation readOnlyHint=true covers safety, so the description does not need to reiterate that. However, the description does not state what the tool actually returns or what side effects (if any) it has beyond reading. It lists areas of focus (visitor experience, conversion blockers) but remains vague about the behavioral outcome, such as whether it produces a report, a score, or just passes/fails. No contradiction, but limited added context beyond the annotation.

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

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

The description is two sentences and relatively compact. It front-loads the core concept ('What a VISITOR would meet') and adds a usage instruction. However, the jargon ('blank band, placeholder, dead binding') may confuse without context, but it is still concise overall.

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

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

With no output schema and only this description, the tool's behavior and return value are not fully specified. The description lists what the tool considers (page elements and conversion blockers) but does not explain what the agent will receive after calling it (e.g., a list of issues, a success/failure flag, or a report). For a review tool that is meant to be used before finishing a page, the expected output is critical. This is a 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?

The tool has zero parameters, so the description is not required to explain any. The baseline for no parameters is 4, and the description does not introduce any parameter-related ambiguity. It correctly focuses on the tool's purpose rather than parameter details.

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

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

The description implies a review/audit of a page from a visitor's perspective, mentioning specific elements like 'blank band, placeholder, dead binding' and conversion blockers. However, it does not state a clear verb+resource (e.g., 'reviews the page for issues') and does not distinguish it from sibling tools like sb_outline or sb_look, which might also inspect pages. The purpose is inferable but not explicit.

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

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

It explicitly instructs to 'Run it before calling a page finished,' which is a clear usage context. It does not mention when not to use it or alternatives, but the timing guidance is specific and actionable. It implies this is a pre-publication check, which is useful.

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 writes are per breakpoint by default, that base:true targets the fallback layer, and that edits batch into one save/frame. However, it does not explain what happens when writing to an existing key (overwrite vs merge), nor does it mention the unset mechanism for removing keys (which is described in the schema but not the tool description). With minimal annotations (readOnlyHint=false, destructiveHint=false), the description carries the burden and only partially covers behavioral traits.

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

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

The description is two sentences, front-loaded with the action. It is concise and avoids fluff, but uses domain jargon ('live frame', 'fallback layer') that may require additional context. It is appropriately sized and well-structured, though a bit cryptic for an external user.

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 9 parameters, nested objects, and no output schema, the description should carry more weight. It covers breakpoint, base, and edits, but omits the 'id', 'keys' shape, 'dry_run', and the practical use of 'unset' (only mentioned in schema). This leaves the tool underspecified for an agent to call correctly without further inference or external knowledge.

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 22% (only 'state' and 'unset' have descriptions). The tool description adds meaning to several parameters: it explains the namespaces (style, config, specials), the base flag, the breakpoint behavior, and the edits batch. However, it does not explain the shape of the 'keys' object, the 'id' parameter, 'dry_run', or how 'unset' works (though unset has a schema description). It partially compensates for the low coverage but leaves key parameters undocumented.

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 (write) and the resource (style, config, or specials keys on a node). It explicitly mentions the ability to write to one node or many via edits, and the phrase 'one save, one live frame' conveys a batching behavior that distinguishes it from per-node mutation tools. Though it does not name sibling tools, the purpose is unambiguous and 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 provides usage context for breakpoint and base:true ('Per BREAKPOINT by default; base:true writes the fallback layer'), explaining when to use base. However, it does not explicitly state when to choose this tool over alternatives like sb_add or sb_remove, nor does it list exclusions. It implies usage but lacks direct comparison or when-not-to-use guidance.

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

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

The readOnlyHint annotation already establishes the operation is safe and non-mutating. The description adds the account-scoping detail ('this account can operate') but does not disclose return format, ordering, pagination, or failure modes. With annotations covering the safety profile, a 3 is appropriate.

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

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

The description is a single, efficient sentence with no filler. It states the action, resource, and scope immediately, earning its place entirely.

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 zero-parameter read-only list tool, the description is largely sufficient. The only minor gap is that no output schema exists and the description does not specify the exact shape of the returned site list, but 'List the sites' strongly implies a straightforward enumeration.

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

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

There are zero parameters, so the description does not need to explain any. The empty schema is fully covered, and the baseline for a zero-parameter tool 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 uses a specific verb ('List') and resource ('sites') with a clear scope ('this account can operate'). It clearly identifies the tool's function and is easily distinguishable from sibling tools like sb_page_list or sb_media_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?

The description implies usage: call this when you need to see which sites are available to the account. However, it does not explicitly state when to use this over alternatives or mention any exclusions, so the guidance is only implied rather than direct.

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

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

Annotations only declare not-readOnly, not-destructive, open-world; the description adds real behavioral weight by disclosing that checkout CREATES and PUBLISHES a page, that form seeds a field document, that chrome writes one shared header, and that dry run returns a plan instead of executing. It does not cover permissions, idempotency, or whether re-running overwrites existing pages, so it stops short of full disclosure.

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 ordering rule is front-loaded and each sentence maps to one action, so nothing is padding. It is dense and jargon-heavy ('field document', 'siteChrome', 'part that cannot be guessed'), which costs a little readability, but the structure is functional.

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

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

For a 9-parameter mutation tool with no output schema and incomplete schema coverage, the description explains the action semantics well but never says what a call returns on success, how errors surface, or what headline/page_name/site_id do. It is minimally sufficient to choose an action, not fully sufficient to invoke confidently.

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 schema coverage at only 44%, the description's explanation of the action enum (checkout vs form vs chrome), what 'name' and 'template' mean for action:"form", and what 'footer' means for action:"chrome" carries the load for the most important parameters. However, headline, page_name, site_id, and dry_run semantics are never explained in prose or schema, leaving meaningful gaps.

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 names three concrete flows (checkout, form, chrome) and states exactly what each produces: a published checkout page, a seeded form from a platform template, or a single shared header. That is a specific verb+resource per action, and it makes the tool's scope distinguishable from publishing/navigation siblings like sb_publish and sb_page_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?

It states the sequencing constraint ('must happen in a fixed order') and the failure condition ('/checkout 404s without all four'), which tells the agent when the checkout action is required. It also implies a relationship to sb_review (the siteChrome gap) but never names an explicit alternative tool or a when-not-to-use condition, keeping it below a 5.

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

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

The annotation readOnlyHint=true already indicates a read-only operation. The description adds context that these are 'saved' templates, implying a listing of pre-existing sections. It does not contradict the annotation, and it provides a small amount of extra context beyond what the annotation conveys, but it does not disclose any additional behavior such as return format, pagination, or filtering.

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 (two sentences) but not well-structured for an action-oriented tool. The first sentence is a noun-phrase definition, not an imperative or verb-led description, so the primary purpose is not front-loaded. The second sentence directs to a sibling, which is useful but does not clarify the tool's own action. It is efficient but structurally weak.

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 no output schema and only one optional parameter, the description fails to explain what the tool returns, how the site_id parameter affects results, or any other usage details. An agent cannot know what to expect from the call or how to interpret the response. The description is inadequate for safe and correct invocation.

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

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

The input schema has one parameter (site_id) with no description, and the schema description coverage is 0%. The description does not mention this parameter at all, leaving the agent to guess its purpose (likely identifying the site). With zero coverage, the description is expected to compensate, but it fails to do so, making this a critical gap.

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 identifies the resource as 'the store's saved section templates' and distinguishes it from sb_template_use by stating that the sibling is for applying them. However, it never states the actual operation (e.g., 'list', 'get', 'browse'), leaving the agent to infer that this tool retrieves or lists templates. The purpose is clear in context but not explicit, so it does not fully meet the standard of a specific verb+resource.

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

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

The description mentions sb_template_use as an alternative for applying a template, but it does not state when to use this tool itself. There is no explicit guidance such as 'use this to view available templates before applying' or any conditions or prerequisites. The implied usage (to see templates) is not clearly articulated, so the guidance is minimal.

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 this is not read-only and not destructive. The description adds useful behavioral detail: site's own templates are copied by the server, while built-in layouts are composed against the page's tokens rather than copied. This clarifies the side-effect model beyond the boolean hints. It does not address dry_run semantics or reversibility, but the core behavior is transparent.

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

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

One dense sentence, front-loaded with the core action and all key distinctions (own template copied vs built-in composed). No fluff, though the grammar is slightly convoluted.

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

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

The description covers the main template-id and page-id semantics and the own-vs-built-in distinction, but omits dry_run and site_id behavior and says nothing about return values or side effects. Acceptable for selecting the tool, incomplete for fully invoking with all options.

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 schema description coverage at 0%, the description must compensate, but it only indirectly clarifies template_id and page_id. It says nothing about dry_run or site_id, leaving two parameters semantically unexplained. Some value is added for template selection, but the compensation is incomplete.

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

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

The description opens with a specific verb, 'Instantiate a section template into a page,' and clarifies the two source types: the site's own templates (server copies) and BUILT-IN layouts listed by sb_templates. This clearly distinguishes the tool from siblings like sb_templates and states the exact action.

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 about when to use the tool (to instantiate a section template) and refers to sb_templates for built-in layouts, giving the agent a pointer to a sibling tool. It does not explicitly state when not to use this tool versus alternatives, but the built-in vs. site-own distinction is a strong usage signal.

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 (readOnlyHint=false, destructiveHint=false), the description explains the tool operates in two modes: read-only when empty, and patch when colors/text_styles are supplied. It also discloses that unmentioned fields are preserved, which is valuable behavioral context. It does not contradict the annotations, since PATCH is consistent with readOnlyHint=false and 'kept' fields align with destructiveHint=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?

The whole description is two sentences that pack the core function, the read/patch duality, and the merge behavior without repetition. The cause-effect phrasing 'so one token repaints every page at once' is concise and adds the key consequence. No wasted or unrelated 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?

The description tells an agent how to read and how to patch safely, and the merge behavior is well communicated. But it omits what dry_run actually does, what site_id refers to, and what the result of the operation looks like. With 4 parameters and no output schema, these missing pieces keep the description from being fully complete.

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

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

The description adds meaning to colors and text_styles by tying them to the PATCH operation and merge semantics. However, dry_run and site_id are not described in either the schema parameter descriptions or this prose, and at 50% schema coverage the description needs to compensate for those gaps. It fails to do so, leaving the agent to guess at those two 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 identifies the resource ('the site's palette and type scale') and the actions ('read' / 'PATCH'), which clearly differentiates this from page, media, and publish tools. It does not explicitly name sibling tools for disambiguation, so it stops short of full sibling differentiation.

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

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

The description gives explicit invocation guidance: call with no arguments to read the current theme, and call with colors/text_styles to update (PATCH) the saved document. It also explains the partial-update behavior ('what you do not name is kept'). It does not compare against other tools or provide when-not-to-use scenarios, but the intended usage branches are clear.

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

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

The readOnlyHint annotation already covers safety, and the description adds useful behavioral context: the tool exposes inspector structure, control-level write targets, AI hints, and the ability to narrow into one control for fuller detail. This goes beyond the annotation without contradicting it.

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

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

The description is compact and front-loads the core purpose before giving usage guidance. The wording is somewhat dense and uses jargon like 'DECLARED control,' but every clause contributes meaningful information.

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

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

For a simple read-only tool with no output schema, the description gives a reasonable sense of the returned content and how to narrow it. It is incomplete mainly because the required type parameter is not explicitly defined, and there is no mention of response shape or potential size of the inspector output.

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 control parameter is well explained by both the schema and description, including the hint to narrow to one control. However, the required type parameter has no schema description and the description only implies its meaning through 'this element's INSPECTOR,' leaving the agent to infer what values type should take.

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

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

The description clearly identifies what the tool returns: the inspector structure for an element, including tabs, groups, control names, what each control writes, and AI hints. It is tied to 'this element' and styling, which gives it a distinct identity among the sibling tools, though it does not explicitly name a sibling it differs from.

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 says to read this before styling an element, and explains the optional control parameter as a way to read one control in full. This gives a clear when-to-use signal, though it does not state when not to use it or name alternative tools.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely non-structured traits: the undo stack is IN THIS PROCESS ONLY, is capped, and disappears when the process exits. It also warns there is no enumerable list of undoable items, which is important agent-facing 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?

Front-loaded with the core action and scope before the caveats, and the page-detour is functional routing rather than filler. Some prose is showy ('anything with a shape', 'That one survives everything') and could be trimmed, but no sentence is wasted.

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

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

For a 2-parameter tool with no output schema, the description covers session scope, capping, ephemerality, and the page alternative well. Missing details are the meaning of dry_run and behavior when index is out of range, which leaves a small gap.

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

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

The description gives no meaning for either parameter. The schema documents only 'index' (1 = most recent write) and leaves 'dry_run' entirely undescribed at 50% coverage, so the description fails to compensate for the gap. 'No argument lists what is undoable here' gestures at the parameterization but adds no usable 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?

States a concrete verb and resource: it restores what a PUT made through sb_api_call replaced (settings, products, forms). The name sb_api_call is called out as the writer being reversed, which separates it from read/create siblings. 'Anything with a shape' is a bit loose but the core purpose is unambiguous.

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

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

Explicitly routes the agent: use this for non-page objects, but for a PAGE the platform history endpoints (GET .../pages/{pageId}/history or versions) are 'the better answer whenever the thing to recover is a page'. That is a real when-to-use/when-not-to-use split. It stops short of stating prerequisites for invoking undo here (e.g., that a prior sb_api_call write must exist in the same session), so it is not a full 5.

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