Benchlight

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

Annotations cover the safety profile (non-read-only, non-destructive, non-idempotent, closed-world), and the description adds real context on top: the output is a draft with no publishing, no subscription activation and no email side effects. It does not explain whether the draft persists or must later be committed via save_booking_draft, which would complete the picture.

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 followed by a constraint and a scope boundary; every sentence carries information. Slightly terse given the complexity of the underlying config payload, but no waste.

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

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

This is a mutating create tool with a free-form nested config object, no output schema and no annotations explaining consequences, yet the description never describes the config shape, what success looks like, or how the resulting draft relates to save_booking_draft/get_booking_draft. An agent knows the tool exists but not how 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 0% across 3 required parameters, and the description supplies no parameter meaning at all. The critical gap is 'config', a nested object with no declared properties and additionalProperties=true — the only hint the description gives is the vague phrase 'services and availability', which is far short of what is needed.

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

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

The verb 'Draft' plus the resource (services and availability for an existing website) gives a rough idea, but 'Draft confirmed services and availability' is abstract and never says what a 'booking draft' actually is. It does not distinguish itself from sibling save_booking_draft or create_store_draft, leaving the agent to infer the division of labour.

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 precondition 'for an existing website' and the scope exclusions ('No publishing, subscription activation or email') imply when this tool applies, and 'Do not invent service durations or business hours' constrains input. However, no alternative is named, so there is no guidance on create_booking_draft vs save_booking_draft or vs create_website.

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-only, non-destructive, non-idempotent write, and the description adds genuinely non-obvious context: the result is editable, partial input is accepted, and no subscription is charged, nothing is published, and no customer email is sent. It stops short of saying what happens on repeated calls or what the draft's lifecycle states are.

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 with the core action front-loaded and the strongest reassurance (no subscription/publication/email) placed last. The final sentence is telegraphic to the point of being fragmentary, 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 two-parameter write with annotations but no output schema, the description covers preconditions and side effects but omits what the call returns, which matters because creating a draft is only useful if the agent learns the draft identifier for a later save_store_draft. The unexplained site_kind enum compounds the gap.

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

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

Schema description coverage is 0% and both parameters are required, yet the description explains neither. 'Attached to an existing website' loosely hints that site_id must reference an existing site, but the site_kind enum values (free/project/offer) are left entirely undefined 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?

States a specific verb and resource ('Create an editable draft') and scopes it to 'an existing website', so an agent knows this is a draft-creation operation rather than a live-publish step. It does not explicitly name the nearest sibling (create_booking_draft) or explain the store-vs-booking distinction beyond the tool name.

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?

'Optional detail never blocks drafting' implies a create-then-fill workflow (follow with save_store_draft), but the alternative tools and the condition choosing between them are only implied. The absence of subscription/publication requirements is stated as a condition, which is useful, but there is no explicit when-not guidance.

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

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

Beyond the annotations (which say non-idempotent, non-destructive, closed-world), the description adds crucial traits: the draft is private and not published, external-file/form/server-code pages are refused with file and reason named, and the request_id retry semantics. This is rich context the structured fields do not carry.

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

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

Dense but front-loaded with the core action and return value, then the input modes and constraints. Every sentence carries information, though the paragraph could be broken into clearer chunks for scanning.

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 names the return (preview link) and failure modes. For a five-parameter nested-input mutation it is nearly complete, though it could note what happens to the draft afterward or size limits for full 5-level coverage.

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 80% so baseline is 3. The description adds meaning for 'files' (complete static site, relative paths, all assets) and 'business' (starter layout details), plus the request_id duplicate-prevention behavior, going beyond the schema's own notes.

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 ('Saves a new private website draft'), names the return ('private preview link'), and enumerates the two accepted input modes (files vs business). It is clearly distinguishable from siblings like get_website, list_websites, and update_website.

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

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

It states the two mutually exclusive input modes and their content requirements, plus which pages are refused and why. It lacks explicit routing to sibling alternatives (e.g., use update_website to modify an existing draft), so it falls short of 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so 'Read-only' in the description is redundant rather than additive. The one piece of genuine context is that the id is 'stable' and 'opaque' — useful for an agent reasoning about caching and not parsing it — but there is no disclosure of auth/permission requirements or failure modes.

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 the return payload front-loaded and the safety note trailing. Every clause earns its place 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?

An output schema exists, so return-value structure need not be explained, and with no parameters there are no input semantics to cover. The description supplies exactly the scope and safety framing an agent needs to call a zero-arg identity lookup correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; by the stated baseline this is a 4. The empty object schema is consistent with the description and introduces no ambiguity.

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

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

States a specific verb and resource ('Returns the Benchlight account this connection uses') and names what is returned (opaque id, email). It is clear, though it doesn't explicitly contrast with the nearest sibling, get_capabilities, which is the only other non-website-scoped tool.

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

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

'the account this connection uses' implicitly tells an agent this is a context/identity lookup, and it is a zero-argument tool so misuse risk is low. But there is no explicit when-to-use statement or pointer to an alternative, so usage must be inferred.

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

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral context by scoping the data returned: no guest details or payment information.

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

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

The description is two tight sentences with no filler. The core read behavior is front-loaded, and the privacy scope statement follows immediately.

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 read-only nature is well covered by annotations, and the description adds useful data-exclusion context. However, with no output schema and 0% schema parameter coverage, the definition does not explain the calendar_id parameter or the shape of the returned draft services and availability.

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

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

Schema description coverage is 0%, and the sole required parameter calendar_id is not mentioned in the description at all. The schema only says it is a string, so the agent gets no explanation of what calendar_id means, where to obtain it, or what format is expected.

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 read operation and identifies the resource as saved draft services and availability. It is clear enough to distinguish a read from sibling write tools like save_booking_draft and create_booking_draft, though it does not explicitly name those alternatives.

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

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

The word 'Read' and the contrast with 'saved draft' imply this is the retrieval counterpart to save/create booking draft tools. However, it gives no explicit when-to-use guidance, prerequisites, or named alternatives, so usage must be inferred.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, and the description's trailing 'Read-only' merely repeats that. It does add real value by disclosing that the payload includes negative information ('what is not available through the connection'), which shapes how an agent should interpret the response, but it says nothing about response size, caching, or freshness.

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 lists the returned content categories in priority order, followed by a two-word safety note. The 'Read-only' sentence is redundant against the annotations, a minor piece of dead weight, but the description is otherwise 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 parameters, no output schema, and rich annotations, the description's job is mainly to convey what comes back — and it does so by naming the four content categories. Slightly more detail on the shape of the values (e.g., that limits are reported per file type) 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It correctly avoids inventing parameter semantics that do not exist.

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

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

The description uses a specific verb and resource ('Returns what this Benchlight connection supports') and enumerates the concrete contents: file types, size limits, draft/preview lifetimes, and unsupported features. That resource is naturally distinct from the sibling tools (create_website, list_websites, get_website), though the description never explicitly contrasts itself with them.

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 only implied: an agent can infer this is a discovery/metadata call to make before creating drafts, but there is no explicit 'use this when...' or 'do not use for...' statement. No alternatives or preconditions are named.

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, idempotentHint, and openWorldHint, so the safety profile is covered; the description earns credit for adding the RDAP data source, the four possible status values, the semantic caveat on 'not_found,' and the explicit note that no price is returned. It stops short of mentioning lookup latency or rate limiting, which keeps it from 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 tight sentences, front-loaded with what is looked up, followed by return values and then the misinterpretation warning. No filler or repetition of the schema.

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

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

With no output schema, the description supplies the return-value vocabulary (registered/not_found/unknown/unsupported) and the key semantic caveat an agent needs to reason over the result. For a one-parameter read-only lookup, nothing material is missing.

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

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

Schema description coverage is 0% for the single 'domain' parameter, so the description must carry the burden; the example 'yourbusiness.com' gives an implicit format cue, but it never states whether bare domain, subdomain, IDN, or URL input is accepted. Partial compensation only.

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 ('looks up whether the domain registry has a registration record for a name') and names the data source (RDAP). It is plainly distinct from every sibling (create_website, list_websites, get_website, etc.), none of which deal with registry records.

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 establishes the use case clearly—checking registry data for a domain name—and explicitly warns that 'not_found means no record was found: it does not mean the name can be bought,' which prevents the obvious misuse. No alternative tool is named, but no sibling overlaps this function, so there is little to route to.

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 real behavioural detail beyond the annotations: links expire after 60 minutes, anyone holding the link can view the version, and each call generates a new link (consistent with idempotentHint=false). It does not cover permission requirements for generating the link, but the expiry and access scope are the operationally important facts.

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, zero filler, with the core action and scope front-loaded and the expiry/access caveats immediately after. Every sentence carries distinct 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 two-parameter tool with annotations and no output schema, the description is nearly sufficient: it explains what the return value is (a link), its lifetime, and its access model. Only site_id semantics are left unexplained.

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

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

Schema coverage is 50%: version_id is documented in the schema and the description's "latest by default" merely restates that. site_id is undocumented in both places, and the description adds no meaning about what it identifies or how it constrains the 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?

"Creates a private preview link for a draft version" states a specific verb and resource with scope clarified by "the latest by default." Siblings are all website/account CRUD operations, so the intent is unambiguous, though no sibling is named as an alternative.

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

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

The description implies the use case (previewing a draft before it is live) and notes the default version, giving clear context. However, it never states when not to use it or how it relates to sibling tools such as get_website or update_website.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the baseline is covered. The description adds real behavioral context not found in annotations: imported text is untrusted content and no order addresses or payment credentials are returned, which is useful for both security and expectation-setting.

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 short sentences and front-loads the purpose before the security caveats. There is little wasted text, though the first sentence is somewhat vague rather than crisp.

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 one-parameter read tool with rich annotations, the description covers safety and sensitive-data exclusions but omits what the store_id parameter means and what 'missing sale-critical facts' actually refers to. It is adequate but not complete.

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

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

Schema description coverage is 0% and the only parameter, store_id, is not mentioned in the description. The description does not explain that the draft retrieved is scoped by store_id, so it adds no semantic meaning beyond the bare schema type.

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, 'Read', and a resource, 'saved catalog and missing sale-critical facts', but never explicitly says this is a store draft or ties it to the tool name. An agent can guess the domain, but it is not clearly distinguished from siblings such as get_website or get_booking_draft.

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

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

There is no guidance on when to use this tool instead of alternatives like get_website, save_store_draft, or create_store_draft. The read-only nature is implied, but no selection conditions or exclusions are 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, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds real value by clarifying that data is stored metadata rather than a live site fetch, but it says nothing about error behavior for an unknown site_id or whether version lists are bounded.

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

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

Two short sentences, front-loaded with the action and scope, followed by the contents of the return and the 'does not visit' caveat. Nothing is redundant with the title and no sentence is 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 carries the return-value burden and does so well by listing versions, latest version id, published state, hosting and domain records. Minor gaps remain around failure modes for an unknown site_id and any size limits, but nothing essential to calling it correctly is missing.

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

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

Schema coverage is 100% and the single site_id parameter is already documented as 'the id of a draft or website in the connected account.' The description reinforces that same framing ('draft or website in the connected account') but adds no new syntax, format, or sourcing hint, so the baseline 3 applies.

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

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

States a specific verb and resource ('Returns one draft or website') with explicit scope ('in the connected account') and keyed lookup ('by site_id'). It then enumerates exactly what comes back (versions and latest version id, published state, hosting and domain records), which cleanly separates it from list_websites and get_website_files.

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

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

Gives a clear usage context (single-resource lookup by site_id) plus an explicit exclusion: 'It does not visit the website,' which steers the agent away from expecting live rendered content. It stops short of naming the sibling to use instead for live/preview content (e.g. get_preview_link) or for file listings.

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

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

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, and the description adds substantial context beyond that: a 100 KB response cap, text files returned with contents, binary files returned as listings only, unreturned files explicitly listed as left out, and starter-layout drafts returning business details. This is unusually transparent about response shape and limits.

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

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

The description is front-loaded with the core return behavior and contains no filler. It is dense, especially the first long sentence enumerating file types and contents, but every clause conveys functional 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?

There is no output schema, so the description must explain return values, and it does: file contents versus listings, size limit, left-out files, paths filtering, starter-layout business details, and default latest version. An agent has enough information to call the tool and interpret the result 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 100%, so the schema already documents site_id, version_id, and paths. The description reinforces that version_id defaults to latest and that paths restricts the response, but it adds no syntax or format detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb and resource — 'Returns the files of a private draft version' — and immediately distinguishes this from sibling tools such as get_website or get_preview_link by focusing on draft file contents. It also clarifies that the result includes text file contents but only lists images, fonts, and other binaries.

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 by the draft-file scope and by 'paths limits the response to the named files,' but the description does not explicitly say when to choose this over get_website or get_preview_link. There are no stated exclusions or alternative-tool routing, leaving the agent to infer the appropriate context.

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

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

Annotations already declare readOnly, idempotent, closed-world, and non-destructive, so the safety profile is covered. The description adds a useful privacy disclosure — no guest contact information is returned — which is real behavioral context an agent could not derive from the structured fields.

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

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

Two short sentences, front-loaded with the scope and followed by the return-content caveat. No filler, no repetition of the title.

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

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

For a parameterless read with no output schema, the description gives the broad return scope and a privacy note, which is reasonably complete. However, it never resolves its overlap with list_websites and list_store_websites, leaving the main selection question unanswered.

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

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

The tool takes zero parameters, so the baseline is 4; there is no argument semantics for the description to explain. Nothing is misstated about 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?

It states a specific verb and resource ('Read this account's websites and booking drafts'), but the combination of websites plus booking drafts is ambiguous against siblings like list_websites, list_store_websites, and get_booking_draft. An agent cannot confidently tell from the description alone which list tool returns what.

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

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

There is no indication of when to use this versus list_websites or list_store_websites, nor any prerequisite or exclusion. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds useful context beyond them: the results are scoped to 'this signed-in account' and the call incurs no payments or publication side effects.

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

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

Two short sentences with no filler, and the primary action is stated first. The second sentence is a compact constraint rather than padding, though 'No payments or publication' is slightly telegraphic.

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

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

For a zero-parameter, read-only listing with rich annotations and no output schema, the description conveys what is returned (websites and existing store drafts) and the account scope. Only the exact return shape is unspecified, which is acceptable at this complexity.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It correctly implies an unfiltered listing of everything in the account.

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 ('Read') and resource ('websites and existing store drafts') in the signed-in account, so the operation is clear. However, it does not distinguish itself from the sibling tools list_websites and list_booking_websites, and the mismatch between the tool name (list_store_websites) and the broader phrasing ('websites and existing store drafts') leaves mild ambiguity about scope.

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

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

There is no statement of when to use this tool versus list_websites or list_booking_websites, which are obvious alternatives. 'No payments or publication' hints at a read-only scope but is not framed as a when/when-not condition or an alternative selection rule.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that — ordering (newest first) and that drafts are private and status is included — but says nothing about pagination, result limits, or how many records come back, which matters most for a list tool.

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

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

One front-loaded sentence carries the scope, ordering and payload; nothing is buried. The trailing 'Read-only.' restates readOnlyHint from the annotations, so it is mild redundancy rather than waste.

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

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

For a no-parameter list tool with no output schema, the description tells the agent what entities come back, in what order, and with what field — enough to call it correctly. The one remaining gap is pagination/volume behavior, which the description should ideally state since no output schema exists.

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

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

There are zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies the tool takes no arguments.

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 ('Lists') and two precise resources ('private website drafts' and 'the websites in the connected Benchlight account'), plus ordering ('newest first') and returned field ('current status'). It is clearly distinguishable from get_website by plurality, though no sibling is named 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?

Usage is only implied: an agent can infer this is the enumeration entry point versus get_website for a single record, but the description never states when to use this over the sibling tools or any preconditions. 'Read-only' hints it is safe to call freely but is not framed as 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 establish that this is not read-only or destructive, but the description adds meaningful behavior: saving only seller-confirmed durations/hours, using the validated editor API, and avoiding publication, payment activation, and notifications. It does not mention auth requirements or idempotency behavior, but the added draft/approval context is valuable.

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-load the core save behavior, then add exclusions and the approval path. There is no wasted text.

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 mutation tool with a nested config object, 0% schema description coverage, and no output schema, the description is incomplete. It does not explain required parameter semantics, config shape, versioning behavior, or the return payload that would include edit_url.

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 carry parameter meaning, yet it never explains calendar_id, version, or the nested config structure. It only conceptually indicates that config contains service durations and business hours, which is insufficient for a 3-required-parameter mutation.

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 (save) and concrete resource content (seller-confirmed service durations and business hours), and clarifies the operation is a draft-save using the editor's validated API. It does not explicitly distinguish itself from create_booking_draft, but the draft/no-publication framing makes its role reasonably clear.

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

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

It states an important usage constraint: no publication, payment activation, or notifications, and directs the agent to open edit_url for explicit owner approval. However, it does not explicitly say when to use this versus create_booking_draft or save_store_draft, leaving sibling selection partly inferred.

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

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

With annotations already declaring readOnly=false, destructive=false, idempotent=false, and openWorld=false, the description adds useful behavioral constraints: it uses store-editor validation, forbids inventing prices/stock/safety claims/policies, and requires confirmed flags only for seller-confirmed facts. It does not explain version-conflict or validation-error behavior, but it adds substantive context beyond the annotations.

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

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

Three sentences, front-loaded with purpose, then guardrails, then the publishing limitation. Every sentence carries relevant behavioral guidance with no repetition or wasted framing.

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 complex mutation with a nested catalog, three required parameters, and no output schema, yet the description focuses almost entirely on behavioral guardrails. It mentions edit_url in passing but leaves the agent without parameter semantics or validation details needed 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 0%, and the description does not explain store_id, version, or the nested catalog object. "Confirmed flags" hints at catalog contents, but there is no mapping to the required parameters or explanation of why version is required.

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: "Save reviewed draft changes" and ties it to the store editor's validation. It implicitly distinguishes saving an existing draft from creating or fetching one, but it does not explicitly name siblings like create_store_draft or get_store_draft.

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 usage context for reviewed draft changes, plus boundary conditions: "No publishing or payment activation; open the edit_url for explicit seller confirmation." It does not explicitly route the agent to create_store_draft when no draft exists, but the save-oriented guidance is clear.

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

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

With annotations already declaring non-read-only, idempotent, non-destructive and closed-world, the description still adds substantive behavior: the optimistic-concurrency contract (stale base_version_id saves nothing and returns the latest version id), that earlier versions are retained, and that no published website changes. Those are exactly the facts an agent needs before firing a mutation.

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

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

Four sentences, front-loaded with the outcome, with no filler. The second sentence is long and clause-stacked, but every clause carries distinct file-merge semantics rather than repetition.

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

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

For an 8-parameter nested-object mutation with no output schema, the description covers the return value (preview link, or latest version id on conflict), the merge rules, and site-safety. The unnoted 'name' parameter and lack of explicit create_website routing are the only shortfalls.

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 88%, so the baseline is 3; the description earns a bump by explaining the interaction between files, keep_unchanged_files and remove_paths, and by clarifying that business is the alternative payload for starter-layout drafts. The only gap is the 'name' parameter, which neither the schema nor the description explains.

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?

Opens with a specific verb and resource — 'Saves a new version of a private draft and returns a preview link' — which immediately separates it from read-only siblings like get_website or get_preview_link. It does not name create_website as the alternative for producing a new draft, so the 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 concrete conditional guidance inside the call: files replace/add while unsent files are kept, remove_paths deletes, and a starter-layout draft takes business details 'instead of files'. It also tells the agent not to use a stale base_version_id. What's missing is routing to create_website when no draft exists yet.

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