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

Annotations already declare this a non-read, non-destructive mutation, so the safety profile is covered. The description usefully discloses the recursive nesting behavior, but it omits the existence of a 'render-inference guard' (only hinted at in the schema's force param), says nothing about what happens on failure or partial subtree insertion, and never mentions dry_run's purpose — noticeable gaps for a mutating tree 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?

Two short sentences, zero filler, with the core capability (nested subtree in one call) front-loaded ahead of the efficiency instruction. Everything present earns its place.

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

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

This is a mutating tool with a deeply nested spec object, five parameters at 20% schema coverage, and no output schema — so the description should say what the call returns (e.g., created node id) and how index/force/dry_run behave. It covers the recursive spec shape but leaves the agent without enough to call it correctly for positional inserts or guarded overrides.

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 20%, so the description must compensate and largely does not: index (insertion position), dry_run, and parent_id semantics are unexplained, and 'force' carries only the cryptic schema note about a render-inference guard. The only value added is the hint that spec.children holds nested specs rather than requiring repeated calls.

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 (add) and resource (an element or nested subtree under a parent), and the 'one call builds a complete section' framing clarifies the recursive/batch nature that a naive reader would miss. It does not name which sibling to use instead (sb_move, sb_set, sb_duplicate), so differentiation is implicit rather than explicit.

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

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

Gives one real usage rule — 'pass children rather than calling this once per node' — which tells the agent how to batch efficiently. But there is no statement of preconditions (must a page be open? does the parent have to exist?), no when-not-to-use case, and no named alternative for single-node inserts or moves.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds two things annotations cannot: requests are dry-run unless dry_run=false is passed, and oversized list responses self-report at 60 KB. It does not describe what a dry run actually returns, nor auth/permission expectations for an open-world mutation tool.

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

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

Three tight clauses: the two invocation modes and the dry-run default are front-loaded, then the shaping parameters, then the truncation warning. No filler; every clause carries an operational fact.

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 14-parameter open-world, destructive HTTP proxy with no output schema, the description covers the critical decisions (id vs method+path, dry run, field shaping, list capping, truncation). It stops short of describing dry-run output shape or error behavior, which an agent would want before committing to a real send.

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 64%, and the description compensates for the weakest entries: pick (field selection, dotted paths), max_items (caps lists), item_offset (skips items within the response after API paging). Several parameters (query, body, path_params, site_id, merge semantics) remain undocumented in both places, so it adds real value but does not close 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?

States a specific verb+resource ('Call an operation... or a route') and immediately distinguishes the two invocation modes: by catalog id from sb_api_find, or by raw method+path for routes the catalog lacks. An agent can tell this apart from sb_api_find, which only looks operations up, without opening either schema.

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

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

Gives a clear routing rule: prefer an id from sb_api_find, fall back to method+path only when the catalog lacks the route. Also signals the default-safe posture ('dry run by default'), so an agent knows it must opt in to a real send. No explicit when-not-to-use or sibling alternatives (e.g. why not sb_live_join or sb_node_read) beyond the catalog fallback.

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?

readOnlyHint=true is consistent with the discovery semantics. Beyond that, the description discloses what the call sheet contains (parameters, credential, body fields, handler caveats) and the scope (all 949 operations), which are non-obvious traits not carried by annotations. Minor gap: no indication of how many results a query returns or in what form.

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 compact clauses that front-load the two modes, followed by a short payload inventory and a scope statement. No filler.

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

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

With no output schema, the description usefully enumerates what a call sheet returns, and the read-only nature is covered by annotations. Remaining gaps – result counts for queries and the relationship between sb_api_find and sb_api_call – keep it short of full completeness.

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

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

Schema coverage is 100%, so the schema already documents id, tag, limit, and query in detail. The description reinforces the query/id distinction but adds no format or interaction semantics, such as whether tag combines with query or how limiting works – baseline 3 is appropriate.

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

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

States a specific verb ('Find') and resource ('API operations'), and clearly names its two modes: intent search via query and call-sheet lookup via id. It does not explicitly differentiate itself from discovery siblings like sb_catalog_search or the execution sibling sb_api_call, but 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?

'Find API operations by intent (query), or get a call sheet (id)' gives implicit mode-selection guidance: use query when you don't know the operation, use id when you do. There is no explicit statement of when not to use it, nor a pointer to sb_api_call as the follow-up for actually invoking an operation.

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 state readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-read-only, non-destructive mutation. The description confirms the page rendering change and button behavior change, but it does not explain reversibility, permissions, or the force and dry_run behaviors.

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 compact sentences with the core purpose front-loaded and no wasted text. The second sentence adds useful action-specific context without bloating the definition.

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?

This is a six-parameter mutation tool with no output schema and only limited annotations, so the description should carry more behavioral context. It covers the core binding and action semantics, but omits dry_run and force behavior and does not route the agent away from sibling tools.

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

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

Schema coverage is 67%: source, field, force, and action have schema descriptions, while id and dry_run do not. The description adds meaning for action by saying it makes a button a purchase control, but it does not compensate for the undocumented id and dry_run 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 and resource: bind a node to real store data so placeholders are replaced with actual products. It also clarifies that action turns a button into a purchase control. It is clear, but it does not distinguish this tool from nearby siblings like sb_set or sb_connect.

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

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

The description implies the use case: replacing placeholder content with real store data and configuring purchase buttons. However, it gives no explicit when-not-to-use guidance or alternatives, and it does not mention prerequisites or how this differs from sb_set or sb_connect.

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 readOnlyHint=true; the description adds meaningful behavior beyond that — the query-omitted browse mode, that it is the sole discovery path for types you would not search for, and the detail:true effect. It says nothing about return size, limit interactions, or pagination, which keeps 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?

Compact and front-loaded: the primary verb opens the sentence, with browse mode and the detail/icon notes following. Some clauses are tightly packed together, which slightly reduces readability 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 read-only search with no output schema and 3 parameters, the description covers the key non-obvious behaviors: browse-by-omission, detail hints, and special query syntax. Return shape and limit/pagination behavior are unaddressed but are less critical given the readOnlyHint.

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% (query has no description at all). The description compensates by documenting the special query syntax "icon:<word>" and clarifying what detail:true returns (AI hints), which the schema only partially covers via its useWhen/avoidWhen/contentTips note.

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

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

The description states a specific verb and resource ("Find an element type by what it does") and gives an agent enough to distinguish it from other search-ish tools. It references sb_traits_for as a related tool, though it does not sharply contrast against the many other siblings in this catalog.

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 real usage conditions: omit query to browse every type (the only way to encounter an unsearched-for type), and use detail:true for AI hints. It names sb_traits_for as a related route but stops short of an explicit when-not-to-use rule or a clear boundary between this and unrelated 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?

Beyond the destructiveHint/openWorldHint annotations, it discloses non-obvious behaviors: scss/typescript compile on write (with compile_error), set merges named fields rather than replacing the row, and enabled site-wide 'none' files are served at their url. It does not explicitly state that 'remove' is irreversible or mention auth/permission requirements for a destructive write tool, leaving a 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 resource and scope are front-loaded, and nearly every clause carries factual weight (extensions, compile, merge, json/text constraints). It is very dense and occasionally cryptic ('the custom-code element', terse merge phrasing), costing a bit of readability but not wasting space.

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 11-parameter destructive mutation tool with no output schema, it covers scope, compile behavior, merge semantics, and format constraints well. Gaps remain around dry_run, position, enabled behavior, and what set/remove return, but overall it is sufficient to call 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 coverage is only 9%, so the description must carry the burden — and it does substantially: it explains placement enum values, language inference from file extension, id create-vs-merge semantics, page_id scope (site-wide vs single page), and action values. It leaves several of the 11 parameters unexplained (dry_run, position, enabled, name), preventing a top score.

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 a concrete resource (custom code files: tracking pixels, analytics, widgets, CSS) and its injection points (head/body_start/body_end), plus the action set (list/set/remove). This lets an agent distinguish the resource from generic page/node tools. The sibling differentiation 'Not the custom-code element' is real but cryptic — it doesn't name the sibling or explain the difference, so the boundary is only partly drawn.

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 concrete selection logic: no page_id = site-wide, page_id = one page; no id = create, with id = merge over stored row; json/text require placement 'none'. These conditions steer correct invocation. It stops short of explicit naming of an alternative tool, relying on the vague 'not the custom-code element' note.

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?

Adds substantial behavior beyond the annotations (readOnlyHint=false, destructiveHint=false): nodes get fresh ids, the copy lands right after the original, cross-site copies push images into the target library, untransportable references are blanked and listed, and the open page becomes the target. This is exactly the side-effect disclosure a mutation tool needs.

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

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

Core behavior is front-loaded in the first sentence. The em-dash framing line ('The move a designer makes constantly') is flavor rather than functional detail, but the rest is dense and earns its place.

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

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

For a 7-param mutation tool with no output schema, the description covers the primary flow and cross-site effects well but omits what force's guard override entails, what dry_run returns, and what index does. Adequate but with visible gaps.

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

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

Schema coverage is only 29%, but the description meaningfully explains to_page_id/to_site_id (paste target, cross-site semantics), which is the highest-value pair. However, force, index, dry_run, and id remain undocumented in both schema and description, leaving real 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?

States a concrete verb and resource ('Copy a node and everything under it, under fresh ids, right after the original') with precise scope. An agent can immediately distinguish it from siblings like sb_add and sb_move without opening any 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?

Clearly explains the two invocation modes: default in-place duplication right after the original, versus pasting elsewhere via to_page_id/to_site_id. It does not name sibling alternatives or state exclusions, but the when-to-use context is strong.

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

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

The annotations already mark the tool as non-read-only and non-destructive, and the description adds useful semantic context: 'A wrong one is refused with the list.' However, it does not disclose side effects, return values, or the meaning of force/dry_run beyond what the schema provides.

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

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

The description is two focused sentences with no filler. It front-loads the main purpose and immediately presents the key alternative, 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?

The description covers the primary use case and the main alternative, but the tool has 6 parameters, no output schema, and sparse annotations. An agent would still lack guidance on force, dry_run, payload, and the expected result of the 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 description adds meaning to the action parameter with examples ('open the cart, go to a page, open a pop-up') and clarifies the exclusion of purchase actions. With schema description coverage at only 50%, it does not compensate for undocumented parameters like payload, force, dry_run, and trigger.

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 and resource: 'Give a node a click action' with concrete examples like opening the cart, going to a page, or opening a pop-up. It also explicitly excludes purchase actions and points to sb_bind, which clearly differentiates it from sibling tools.

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

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

It gives an explicit when-not condition: a purchase is not a click action and should use sb_bind instead. This directly tells the agent the main decision boundary between sb_event and its 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?

Annotations already flag destructiveHint and openWorldHint, and the description adds real value on top: it discloses the permission model, that functions run with the site's secrets/collections/fetch, that 'remove' deletes, and that 'test' actually invokes the function with a method/path/body. It does not explain dry_run, which is the one safety-relevant gap for a destructive tool with a test path.

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?

Extremely dense but earns nearly every token; the resource definition and the sb_code exclusion are front-loaded before the action map. The action list is crammed into a single run-on clause, which slows parsing for a 17-parameter tool but wastes little space.

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-action, 17-parameter tool with no output schema, the description covers the core dispatch logic and the risky operations well. It falls short on parameters that gate behavior (dry_run, enabled, language, site_id) and does not say what list/get/logs/usage return, leaving genuine holes.

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 6% (only 'id' is annotated), so the description has to carry the load and it does for the ambiguous cases: id-vs-create/merge on set, key+value on secret, and the full test payload shape. However six parameters (dry_run, enabled, language, content, limit, site_id) are never mentioned anywhere, including the limit's 1-200 bound, so an agent still guesses at them.

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 definition names the resource and its runtime ('server-side TS/JS at /_wb/fn/<slug>') and immediately differentiates it from the nearest confusable sibling with 'Not sb_code'. An agent can decide between sb_function and sb_code without opening either schema.

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

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

It gives an explicit exclusion (not sb_code) and an authorization precondition ('Owner/admin only'), plus action-level guidance embedded in the list (no id creates; id merges). What is missing is any statement of when a given action should be chosen over a sibling like sb_add or sb_set, which is left implicit.

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 say readOnlyHint=false and destructiveHint=false, and the description goes further by disclosing exactly what happens: real elements are added to the OPEN page, foreign layout/CSS is discarded, and dry run returns findings instead of mutating. It does not mention that image copying uploads into the media library or the cost/latency of fetching a remote origin, which the schema only partially covers.

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

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

Three tight sentences, front-loaded with the core action, then the key scope caveat, then the dry-run behavior. Every clause carries information an agent needs and there is no filler.

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

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

For an 8-parameter mutating tool with no output schema, the description covers the essential behavior and the dry-run return path. It leaves a gap around prerequisites (an OPEN page must already exist, likely via sb_page_open) and around image-upload side effects, which matter 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 coverage is 63% and the description only adds semantics for dry_run ('returns what was found'). dry_run, site_id, and max_sections carry no description in either place, and nothing explains how max_nodes/max_images bound the import beyond what the schema already says.

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+destination: read a public URL page and add its structure/content as real elements into the currently OPEN page, styled with the page's own tokens. It also clarifies scope negatively ('Not a clone: the source's layout and CSS are not copied'), which separates it from a full-site importer like sb_import_site.

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

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

Usage is implied — reach for it when you want a page's content merged into the open page — but no alternative is named and no when-not condition is given. The sibling sb_import_site (site-level import) is never referenced, so the agent must infer the boundary itself.

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

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

Annotations already declare readOnlyHint=false (so the agent knows it mutates) and openWorldHint=true. The description adds valuable context beyond annotations: 'Dry run returns the page list before anything is created', clarifying the dry_run side effect, and 'Not a clone' sets expectations about output nature. However, it doesn't address permissions required, rate limits, or what happens to the site's existing pages (creation vs. overwrite), leaving some mutation risk opaque.

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 that front-load the core action ('Read a WHOLE site from one URL') and then add the dry run note. It's efficient with no fluff, though the second sentence is a fragment that could be integrated more smoothly.

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 14-parameter, mutation-heavy tool with no output schema and 71% schema coverage, the description is somewhat thin. It doesn't explain return values beyond the dry run case, doesn't mention failure modes or whether existing pages are affected, and omits guidance on common pitfalls like theme being 'SITE-WIDE'. It's adequate but leaves notable gaps.

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

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

Schema coverage is 71%, so the schema covers most parameters, but several key parameters lack descriptions (e.g., dry_run, exclude, upload_images, site_id). The description adds meaning for the overall import behavior (sitemap vs. link crawling, draft creation) but doesn't compensate for the gaps in the schema's parameter documentation, such as the exact format of include/exclude paths or the effect of 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 states a specific verb+resource ('Read a WHOLE site from one URL' and 'give each page found its own DRAFT page'), and clearly distinguishes the tool from the sibling 'sb_import' by specifying site-level reading. It's clear what the tool does, though the phrase 'built from this site's tokens' is a bit jargon-heavy and 'Not a clone' adds ambiguity about what exactly is produced.

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 guidance versus alternatives like sb_import or sb_page_create. It mentions dry run behavior but doesn't say when to prefer this over a single-page import or manual page creation. No exclusions or prerequisites are mentioned.

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

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

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 already declare this a non-read-only, non-destructive write; the description adds genuinely useful behavior — that a URL is returned and is directly usable by sb_set, and that bulk picks stock a site in one call. It says nothing about permissions/auth, duplicate handling on re-upload, or what the response looks like when several files are uploaded (single URL vs list).

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

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

Front-loaded with the core action and return value, then the search workflow, then a differentiation tagline; four short sentences with little waste. The search/pick mechanics are dense but each sentence carries information.

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

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

With 10 parameters, no output schema, and 50% coverage, the description should close more gaps than it does — notably what `dry_run`, `site_id`, and `folder_id` do, and whether calling with no arguments is an error. The return-value hint partially compensates for the missing output schema, but key behavioral surface remains undocumented.

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?

At 50% schema coverage, the description usefully explains the non-obvious `query`/`pick` pairing and the path-vs-URL input modes that the schema only gestures at. However, four parameters — `dry_run`, `site_id`, `folder_id`, and `orientation` — get no explanation in either the description or the schema, and the description never states that some combination of inputs is required despite zero required params.

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?

"Put an image into the media library and get its URL back" gives a concrete verb, resource, and outcome, and "the only way to add an image" separates it from the listing sibling sb_media_list. The search-then-pick mode is also named up front, so the agent knows this tool both searches and writes.

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 spells out the intended workflow: use `query` to search real photographs, then `pick` the id(s), or pass a local path/URL directly, plus the bulk-stocking scenario. It does not explicitly say when not to use it (e.g. use sb_media_list to view existing assets), so it falls short of full routing 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 declare readOnlyHint=false and destructiveHint=false, and the description adds the core repositioning behavior. However, it does not disclose side effects such as whether children are preserved, what happens to the old parent, or what force/dry_run actually do at runtime.

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

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

The description is a single concise sentence with no filler. The essential operation and target are front-loaded.

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

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

For a mutating tool with five parameters, no output schema, and an unexplained guard flag (force) plus dry_run, this description is too thin. An agent would need to infer conventional semantics for the optional parameters and possible side effects.

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 phrase 'another parent at an index' gives meaning to the required parameters id, parent_id, and index. Since schema description coverage is only 20%, the description should also clarify optional parameters, but dry_run is left undocumented and force is only explained in the schema.

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

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

The description names a specific verb (Move), a resource (node), and a target location (another parent at an index). This clearly distinguishes it from sibling tools like sb_remove, sb_duplicate, and sb_add.

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 tool's intended use is implied by the action word 'move', but there is no explicit guidance on when to choose it over alternatives such as sb_duplicate, sb_set, or sb_remove. No exclusions or decision criteria 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 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 mark it as read-only, and the description adds meaningful behavioral context: it returns a compressed tree with specific fields and explicitly warns that it never returns the raw document because real pages can be hundreds of KB. It does not cover pagination, auth, or full return format, but it significantly enriches the safety and scope picture 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?

Two short sentences with no filler. The core behavior and the key contrast with raw document output are front-loaded 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?

The description gives a useful picture of the return structure and distinguishes it from raw document output, which matters because no output schema exists. However, it leaves the depth parameter unexplained and does not help an agent choose between this outline view and related sibling tools, so it is only minimally complete for a tool with two operational parameters.

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

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

Schema description coverage is only 50%: the chrome parameter is documented in the schema, but depth is undocumented there and is not mentioned in the description at all. The description adds no semantic meaning for either parameter, so an agent must infer what depth controls and how chrome affects output.

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 this tool returns the open page as a compressed tree, lists the fields exposed, and explicitly contrasts it with raw JSON document output. However, it does not name a specific sibling tool or clearly differentiate itself from tools like sb_page_open or sb_node_read.

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

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

The phrase 'Never the raw document' implies this is a lightweight overview tool for structure rather than full page retrieval, which gives some usage context. But there is no explicit guidance on when to use this instead of alternatives such as sb_page_open, nor are prerequisites or exclusions 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=false and destructiveHint=false, so the safety profile is covered. The description adds useful behavior — that store types carry bound content like the buy box and that missing published pages cause 404s — but it does not describe persistence, idempotency, or what the created page/response contains.

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?

It is short and front-loads type information, but the syntax is dense and jargon-heavy ('arrives with the document the editor gives a merchant', 'bound buy box'), which costs comprehension. Most sentences carry information, but the phrasing obscures rather than streamlines.

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 11-parameter creation tool with a nested settings object, no output schema, and only 45% schema coverage, the description leaves too much undocumented. Key creation options and the return behavior are unexplained, making it inadequate given the tool's complexity.

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

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

Schema coverage is only 45% across 11 parameters, so the description must compensate. It usefully enumerates the type values (product, category, search, blog, post, complete, account) despite zero schema enums and clarifies slug/type routing, but chrome, locale, headline, settings, site_id, is_homepage, dry_run, and name receive no additional meaning.

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

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

The name and route references imply page creation, but the description never states the core verb+resource plainly — it opens with 'A store type ... arrives with the document', which is hard to parse. It does specify available types and their distinct behavior, distinguishing it from siblings like sb_page_open and sb_page_list, but an agent must infer that this tool creates a page.

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

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

It gives a conditional ('seed:false for blank') and points to sb_page_open for seeding ROOT, which is genuine when-to-use routing. However, it never explains when to choose create versus sb_page_update or sb_duplicate, and prerequisites (auth, site context) are only implied.

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

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

The 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?

Annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds workflow context (it is a prerequisite that returns an outline and can target a form's field document), but the phrase 'open a page for editing' sits in mild tension with a read-only hint and could suggest a state change or lock that the annotation denies.

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

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

Three short sentences, front-loaded with the action and its prerequisite, with no filler. The closing fragment 'fields, specials.formRules on its root' is terse to the point of being cryptic but does not waste space.

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 prerequisite tool with no output schema, the description supplies the essentials: it returns an outline, must precede the edit tools, and offers two ways to identify the target. The remaining gap is the undocumented site_id and the exact shape of the returned outline.

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. It explains page_id (find via sb_api_find) and form_id (its field document, fields, specials.formRules on its root), but site_id is left entirely unexplained despite having no schema description.

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

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

States a specific verb and resource ('Open a page for editing and return its outline'), so the core action is unambiguous. It routes to sb_api_find and names edit-related siblings, but never explicitly distinguishes itself from sb_outline or sb_node_read, which also surface page content.

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

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

Provides a concrete precondition ('Call before any sb_add / sb_set / sb_move / sb_remove') and tells the agent how to obtain the needed id via sb_api_find 'list pages'. It also covers an alternative entry path (form_id edits that form's field document), though it never states when this tool should not be used.

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, idempotentHint=true, destructiveHint=false. The description adds real value beyond these: the dry_run default of true (a safety mechanism aligning with non-destructive behavior), the draft-only mutation scope, and the re-publishing note for published pages. It is consistent with the annotations and enriches the behavioral contract.

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 dense sentences with no filler. The main action is front-loaded, and scope, draft handling, and dry_run safety are packed into ~40 words. Every sentence earns its place.

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

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

For a batch-capable mutation tool with no output schema, it covers the core operation, scope control, draft-only behavior, and dry_run safeguard. Minor gaps: site_id semantics and what the dry_run listing actually returns are not specified, but the operation is well understood without them.

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%, so the description must carry the parameter meanings. It covers dry_run (default true, lists what would change) and page_id (target one page, or omit for all pages), but site_id is entirely unmentioned. Two of three parameters are meaningfully explained, compensating partially but not fully for the missing schema documentation.

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

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

The description states a specific verb (rename), resource (page root), and precise condition (root not 'ROOT', e.g., sppro_1 or rt_<hex> left by older seeds). It clearly distinguishes from siblings like sb_page_create, sb_publish, and sb_page_state, all of which handle different operations.

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

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

The description gives clear context: it's for fixing legacy malformed page roots, with scope (one page vs every page via page_id) and a draft-only restriction with published pages listed for re-publishing. It doesn't explicitly name alternatives or state when NOT to use it, but the legacy-seed trigger and draft-handling make the use case well understood.

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 say readOnlyHint=true, and the description adds substantial behavioral context: the hydrate gate silently discards documents with a missing root, the Go renderer lacks this gate, and this explains the live-has-data-but-canvas-empty state. It also clarifies the tool reports draft-vs-live differences and recovery points, going well 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 core purpose is front-loaded, but the second sentence is dense and rambling, with a long parenthetical about hydrate gates and renderer differences stuffed into a clause about blank rendering. The information is valuable, but the structure makes it harder to parse than necessary.

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

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

There is no output schema, so the description carries the burden of explaining what the tool reports; it covers copy identity, blank-canvas behavior, draft/live changes, and recovery points. It is complete enough for an agent to know when and why to call it, though 'recovery points' and 'what this session holds' remain somewhat underspecified.

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 50%, with site_id undocumented, and the description does not mention parameters at all. It indirectly refers to 'this page,' aligning with page_id's default, but it adds no meaning for site_id or how the page context is resolved.

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 (this page's three copies) and the specific diagnostic outputs: which copy is draft/published/session, whether the canvas will render blank, whether the draft differs from live, and where recovery points are. This is distinct from sibling tools like page_open, node_read, or outline, so an agent can tell what this tool is for.

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

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

Usage is implied through the scenario described: diagnose which copy is which, understand why the editor canvas is blank while live data exists, or locate recovery points. However, there is no explicit statement of when to choose this over sibling diagnostic tools, nor any exclusions or 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 already declare this is a non-read, non-destructive mutation, so the safety profile is covered. The description adds genuinely non-obvious behavior: it reads the page first and merges settings key by key so unnamed keys survive. It omits mention of dry_run and any auth/permission requirements, keeping it below a 5.

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

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

Three dense but front-loaded sentences with no filler; the editable-fields list and the merge caveat come first, with template semantics last. Slightly packed, but every sentence carries load.

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 12-parameter tool with a nested SEO object, no output schema, and low schema coverage, the description covers most meaningful parameters and the key merge behavior. Gaps remain around dry_run and site_id, but an agent has enough to call it correctly.

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

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

Schema description coverage is only 17%, so the description must compensate, and it largely does: it explains seo is merged key by key, and clarifies render_for (move entities onto this page) vs render_default (return to type default) and default_template. Only page_id, site_id, and dry_run are left without added 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?

States a specific verb ('Edit') and resource ('a page'), then enumerates exactly which fields are editable (name, slug, home flag, order, SEO, members_only). The template-page sentence further narrows the scope to a distinct behavior class, making it clearly distinguishable from siblings like sb_page_create and sb_page_repair.

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

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

Provides clear context for when the template-specific parameters apply (on a template page such as product, category, post) and what default_template/render_for/render_default accomplish. It does not explicitly name an alternative tool or state exclusions, so it falls short of full when/when-not 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 declare destructiveHint=true and readOnlyHint=false, and the description adds genuinely new behavioral context beyond them: writes are dry runs by default, and restore actually rewrites the draft. It does not say whether a restore is itself reversible, how autosave history interacts with named versions, or what permissions are required.

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

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

The scope statement is front-loaded and the per-action detail is packed into one dense sentence with no filler. It is telegraphic to the point that the quoted action names plus braces require careful parsing, but nothing 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 7-parameter tool with no output schema and near-zero schema coverage, the description covers the action semantics, the recovery scoping, and the dry-run safety default. Missing are site_id behavior and any notion of what list returns (ordering, limits), which an agent would need for real use.

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

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

Schema description coverage is only 14%, so the description carries most of the burden and does so well: it binds label to save, version_id/history_id to restore, and explains the dry_run default. The one gap is site_id, which is neither described in the schema nor mentioned here; page_id is the only parameter documented by the schema itself.

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 first sentence names the resource precisely ('A page's platform recovery points, everyone's edits included') and distinguishes it from the closest sibling by explicitly noting that sb_undo covers a different scope. Each action is then given a concrete verb and object (list = named versions/autosave history, save = snapshot the draft, restore = put the draft back), so an agent can tell exactly what the tool does without opening the schema.

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

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

It routes the agent away from sb_undo with an explicit scope boundary and clarifies which action to pick for each intent (browse vs snapshot vs roll back). It stops short of stating exclusions or prerequisites, e.g. whether restore requires a prior list call or whether saving is allowed on published pages.

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?

Goes well beyond annotations (destructive/idempotent/readOnly=false) by disclosing the cascade to pages sharing changed global sections, warning about shipping shared edits nobody published, and explaining the 60s storefront cache so an old page isn't mistaken for a failed publish. This is exactly the behavioral context an agent needs before a destructive write.

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-loads the core action and packs cascade/cache caveats into two dense sentences. Slightly parenthetical-heavy, but every clause carries operational 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?

With no output schema, the description supplies return-shape detail (id, publishedAt, fromVersionId, would_cascade) and the caching caveat, which is a lot for a destructive tool. Only the uncovered params (page_id, site_id, publish_drafts) keep it from full completeness.

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

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

Schema coverage is only 40%, so the description must compensate. It richly explains dry_run and verify (beyond the schema), but page_id, site_id, and publish_drafts are not addressed in the description, leaving gaps in a 5-param tool.

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

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

States a specific verb+resource: compile the draft into the live page, plus reports the resulting revision (id, publishedAt, fromVersionId). The operation is unmistakable. It does not explicitly distinguish itself from siblings like sb_page_version or sb_undo, which keeps it just shy of a 5.

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

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

Gives clear operational context: dry_run lists would_cascade and warns FIRST, and verify:true is the follow-up confirmation step. This implies a sensible workflow without stating exclusions or naming an alternative tool directly.

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, so the destructive nature is known. The description adds valuable context beyond the annotation by specifying that the whole subtree is removed, not just the node itself. However, it does not mention irreversibility, dry-run behavior, or any side effects beyond the subtree scope.

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

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

The description is a single sentence with no filler. Every word contributes meaning, and the most important scoping detail ('whole subtree') is included. It is appropriately concise and front-loaded.

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

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

Given that this is a destructive tool with no output schema and three parameters, the description is too thin. It does not clarify what a successful removal returns, what dry_run does, how force behaves, or whether the operation can be undone. The annotations cover safety but not runtime behavior.

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

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

Schema description coverage is only 33%, and the main description does not explain any parameters. The required 'id' is implied by 'Remove a node' but not explicitly tied to the parameter, and 'dry_run' has no semantic guidance at all. The description fails to compensate for the sparse schema documentation.

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

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

The description uses a specific verb ('Remove') and a clear resource ('a node and its whole subtree'), and it is easily distinguished from sibling tools like sb_add, sb_set, or sb_move. It also adds the important scoping detail that the entire subtree is affected, which makes the purpose unambiguous.

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

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

The description gives no guidance about when to use this tool versus alternatives, when not to use it, or what prerequisites apply. While the verb 'Remove' implies usage, there is no explicit routing or exclusion compared with related operations like sb_undo or sb_set.

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?

readOnlyHint=true is consistent with an inspection tool, and the description correctly frames it as a check rather than a mutation. It adds useful domain detail about what is examined but says nothing about the nature of the findings or what output to expect. With annotations already carrying the read-only safety profile, a 3 fits.

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, but they are dense and jargon-heavy ('blank band', 'dead binding'), requiring interpretation. The action verb and when-to-run guidance are pushed to the second sentence, so it is not 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 review tool with no output schema, the description should signal the shape of the findings an agent will get back. It covers what is checked and when to run it, but the return behavior and whether it reports or fixes are left implicit.

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

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

The schema documents nothing (0% coverage), but the description compensates by explaining that page_id restricts the review to that single page, implying the default covers the whole store. With only one optional parameter, that is sufficient to use it correctly.

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 concretely says what it detects: visitor-facing page defects (blank band, placeholder, dead binding) and store checkout blockers (checkout page, gateway, delivery, cart link). This goes well beyond the opaque name 'sb_review' and lets an agent distinguish it from siblings like sb_page_state or sb_look. It stops short of a clean verb ('reviews/audits'), staying in descriptive phrasing.

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?

'Run it before calling a page done' is an explicit trigger condition, and 'page_id: only that page' clarifies the scoped mode of use. It lacks explicit alternatives (e.g. sb_page_repair for fixing what it finds), so it does not reach the when/when-not bar of a 5.

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

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

Annotations already cover the safety profile (readOnly=false, destructive=false), and the description adds real behavior beyond that: bulk edits coalesce into "one save, one live frame", and writes land on the breakpoint layer by default with `base` targeting the fallback layer. It omits the render-inference guard and the existence of `dry_run`, but the layer/atomicity semantics are a meaningful addition.

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 dense sentences with no filler, and the primary write scope is front-loaded before the layering caveat. The phrasing "one save, one live frame" is terse to the point of jargon, which costs a little clarity against its 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?

A 10-parameter mutation tool with nested `edits`, no output schema, and no annotations on reversibility. The description covers the core write semantics but leaves out `dry_run` (the main safety valve) and `force`, so an agent cannot fully plan a safe call from 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?

At 30% schema coverage the description must compensate, and it does explain the two highest-risk knobs (`base` and the default breakpoint scoping) plus the id-vs-edits split. Several parameters — `dry_run`, `namespace`, `keys`, and the per-edit `breakpoint`/`state` fields — remain undocumented in the description, relying on the schema's own partial descriptions.

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

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

States a specific verb and resource (write style/config/specials keys) and explicitly covers both modes: one node via `id`, many via `edits`. It does not name a sibling to differentiate from (e.g. sb_bind, sb_remove), so it stops short of the top of the scale, but an agent can tell what this does without opening the schema.

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

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

Gives one concrete selection rule — `base:true` for values that should not vary, otherwise per-breakpoint is the default — which is genuinely useful. However, it never says when to reach for this tool instead of alternatives like sb_bind or sb_remove, and says nothing about when to prefer `edits` over a single call.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's contribution is limited to the account-scope qualifier ("can operate"), which usefully implies results are permission-filtered. It does not disclose pagination, ordering, or whether "operate" means view-only versus edit rights.

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 seven-word sentence with zero padding and the resource front-loaded after the verb. Brevity is appropriate here, though "operate" is slightly ambiguous and one more clause on scope would still have been cheap.

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 no-parameter, read-only listing tool this is close to sufficient, but with no output schema the agent gets no sense of what a site record contains or whether results are truncated. A brief note on return shape or pagination would close the remaining 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?

Zero parameters, so there is no parameter semantics to explain; baseline of 4 applies. The empty schema with additionalProperties=false is consistent with the description's claim of a no-argument listing call.

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

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

States a specific verb ("List") and resource ("sites"), which separates it from the page/media-focused list siblings (sb_page_list, sb_media_list). The scope note "this account can operate" adds a permission qualifier, though it never names an alternative tool explicitly.

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

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

No explicit guidance on when to call this versus siblings such as sb_page_list, sb_import_site, or sb_catalog_search. The only hint of applicable context is the phrase "this account can operate," leaving the agent to infer that this is the entry point for enumerating accessible sites.

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 substantial side effects beyond annotations: checkout saves fields with real payment/delivery options and PUBLISHES the page, overlay_attach re-reads the page afterwards, app installs may create pages, global_detach removes a shared section reference, and dry_run returns the plan. These details are especially useful because the annotations only state broad safety/open-world hints.

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 content is dense but justified by 12 actions and many caveats; however, it is delivered as one enormous run-on sentence with semicolons and em dashes rather than a scannable structure. The purpose is front-loaded, but readability and action comparison suffer from the lack of formatting.

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 12-action mutation tool with no output schema, the description covers most behavioral and sequencing context an agent needs to select an action correctly. It still leaves some gaps around unmentioned parameters and non-dry-run return behavior, but overall it is substantially 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?

With 20 parameters and only 65% schema description coverage, the description does meaningful work by tying action-specific parameters to behavior, such as kind/list_id for overlay_attach, global_id for attach/detach, global_kind defaults, and node_id for menu/promote/template_save. However, some parameters such as site_id, page_name, headline, and menu_id remain unexplained in both schema and description.

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

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

The description clearly defines a multi-action store setup/maintenance tool and enumerates each action's concrete effect, from creating and publishing checkout to attaching shared globals. It distinguishes this tool from siblings by naming sb_review's siteChrome gap, open_cart controls, and editor-equivalent behavior.

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

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

It gives explicit when-to-use guidance for each action: checkout_sync after adding shipping or switching on a gateway, chrome when sb_review reports siteChrome missing, global_attach for a page missing the site header, and global_promote/template_save for sharing sections. It also explicitly warns when not to use chrome because it would wrongly build a second header.

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 establish write-but-non-destructive (readOnlyHint=false, destructiveHint=false). The description adds real behavioral context beyond that: insertion happens 'above the footer', and a foreign site's template is copied in whereas built-in layouts are composed against the page's own tokens. It does not, however, explain what dry_run controls.

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 leads with the action and then qualifies the source types. Efficient, though the nested parenthetical makes the back half slightly hard 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?

No output schema, so return values need not be covered, and annotations carry the safety profile. But for a four-parameter mutation tool at 0% schema coverage, the silent dry_run parameter — likely the safe way to preview this operation — is a meaningful omission.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies the non-obvious semantics of template_id (two distinct sources) and implies the target page, but says nothing about dry_run or site_id, leaving half the parameters unilluminated.

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 ('Add') and resource ('a section template to a page') and disambiguates the two template sources — an sb_templates row that gets copied versus a built-in layout composed against page tokens. This distinguishes it well from a generic add tool, though the dense phrasing requires a second read.

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

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

It references sb_templates as the listing source for template_id, implying this is used after looking up a template, but never states when to use it versus siblings like sb_add or sb_page_create, nor any prerequisites. Usage is inferable but not explicit.

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

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

It discloses important mutation semantics beyond the annotations: PATCH behavior, preservation of unnamed values, preset precedence over text styles, breakpoint-specific writes, and site-wide locale scope. It does not explain the dry_run flag or return behavior, which are meaningful gaps for a mutation tool.

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

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

The description is compact and front-loads the core concept before explaining field behavior. Some phrasing is awkward and compressed, such as the presets clause and the breakpoint sentence, which slightly reduces immediate clarity.

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

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

Given the nested object schema, no output schema, and only minimal annotations, the description covers the main mutation semantics well. But it omits dry_run, site_id context, and any indication of what a read returns, leaving the definition only partially complete for an agent 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?

The description adds useful meaning for colors, text_styles, presets, locale, and breakpoint objects, including merge and precedence behavior. With 67% schema description coverage, it still leaves site_id and dry_run undocumented in both schema and description, which matters for correct invocation.

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

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

The description clearly identifies the resource as the site's palette and type scale, and explains its role as the layer that element style presets resolve from. It does not explicitly differentiate from sibling tools such as sb_set or sb_traits_for, so it stops short of a 5.

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

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

It says to call the tool with no arguments to read the current theme, and explains that colors/text_styles/presets PATCH the saved document. However, it gives no explicit guidance on when to use this tool versus alternatives, nor any when-not conditions.

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 declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive mutating tool. The description adds useful constraints (writes limited to 'registry fields only', 'machine-fill missing'), but omits the dry_run parameter entirely and says nothing about side effects or reversibility for the write/auto actions.

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 dense pipe-delimited line that is front-loaded with the domain and then enumerates actions. It is compact, but 'as the editor does it' is cryptic filler and the run-on structure trades readability 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 12 parameters, no output schema, and 0% schema description coverage, the definition is too thin for the tool's complexity. Critically, the dry_run safety flag is never mentioned, and there is no explanation of what write/auto actions return or how they modify content.

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% across 12 parameters, so the description must compensate. It partially does: 'add/remove' maps to the locales params, 'node id+field+value' maps to the entries fields, and 'machine-fill' maps to source=machine. But most parameters (dry_run, offset, locale, site_id, page_id, entity_type, all, from) remain undocumented anywhere.

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 lead 'Multilingual, as the editor does it' is vague about the resource and verb, but the following pipe-delimited action list (status, locales, page, write, auto, review) reveals that this is a multilingual translation-management tool. An agent can infer the domain but must decode the terse sub-command markers to understand what the tool actually does.

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

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

The parentheticals act as light usage notes ('write (node id+field+value; registry fields only)', 'auto (machine-fill missing)', 'review (approve)'), implying when each action applies. However, no alternative tools are named and there is no explicit when-to-use/when-not-to-use guidance relative to siblings like sb_review or sb_set.

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

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

Beyond the destructiveHint/openWorldHint annotations, it discloses that an undo itself becomes a redoable entry, that it is process-scoped and capped while platform history survives restart, and that concurrent edits cause refusal. This is exactly the non-obvious behavior an agent needs before calling a destructive tool.

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

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

The core action and its sources are front-loaded and dense with useful information, but the trailing sentence about arguments is somewhat disjointed and the dry_run gap makes the parameter story feel incomplete rather than tight.

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 no required parameters, the description supplies most needed context: concurrency refusal, scope limits, and redo semantics. The unexplained dry_run behavior and lack of any hint about what the call returns keep it short of complete.

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

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

Schema coverage is 67%: `all` and `index` are documented in the schema, and the description adds that no argument enumerates undoable items. However, `dry_run` is left completely unexplained in both schema and description, leaving a meaningful gap for a destructive operation.

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

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

The description states a specific verb and resource ('Put back what a write replaced') and enumerates the write sources it reverses (sb_add, sb_set, sb_duplicate, PUT via sb_api_call), which lets an agent distinguish it from siblings like sb_page_version or sb_page_repair.

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 conditions for use and one exclusion (a page is refused if someone else saved it since) and implicitly routes persistent history lookups to the platform's page history endpoint. It lacks an explicit 'use X instead when you need Y' framing for the process-vs-restart tradeoff, so not a 5.

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