Orivox AI Website Builder

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

With no annotations, the description carries the disclosure burden and does it well: it states that unknown ops or extra fields are rejected with 'no partial write', that 'changed' being False means a no-op or safety-guard refusal, and that a skip_warning may appear in the result. This gives real behavioral clarity beyond the schema.

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

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

Purpose, operation format, validation behavior, and result semantics are each covered in just a few tightly packed sentences. Nothing is filler and the most important information is front-loaded.

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

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

Given the complexity of 14 operation types, the description is robust: it lists op variants, rejection behavior, no-partial-write guarantee, changed-field interpretation, and skip_warning. Minor gaps are the exact payload shape per operation, but this is close to sufficient by itself with no annotations.

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 the operations array in depth: op enum values, selector syntax (CSS / #id / [data-ai-id='...']), and payload fields. It does not add much detail about project_guid/page beyond their obvious project/page context, but the critical inner-object semantics are well covered.

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

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

States a specific verb and resource: 'Apply approved DOM operations to a project page and save.' It enumerates the valid op values, so an agent clearly understands the tool's edit-on-existing-page role and can distinguish it from sibling page-creation or build tools.

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

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

The description makes the use case clear: apply DOM operations to an existing project page and save. However, it never explicitly says when to use this over create_page, build_site, or publish_website, nor does it exclude cases like creating a new page.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by explaining the multi-turn ownership model, the credit/metering cost against the user's account, the no-HTML constraint, and the response lifecycle with concrete guidance for 'collecting' and 'built' phases. It does not describe persistence or repeated-call effects, but for a chat-based build action, the stated behavior is sufficiently clear.

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

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

The description is longer than average, but its length is justified by the multi-turn protocol, cost warning, and response-phase instructions. The primary purpose is front-loaded in the first sentence, and the alternative routing appears early. Every paragraph carries actionable information, though a slightly tighter structure could reduce 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?

Given the tool's complexity, the description is complete where it matters: prerequisite ordering, when not to use it, how to handle both response phases, and what to show the user. The output schema exists, so the description does not need to enumerate return fields. There is no critical missing context that would prevent an agent from invoking 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?

The input schema provides zero property descriptions, so the prose must compensate. The description clarifies that 'message' is the verbatim user chat message and implies that 'project_guid' comes from the required create_project call. It does not explicitly name 'project_guid' as the return value from create_project, but the sequencing guidance makes the association sufficiently clear.

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 a specific verb and resource: have Orivox's own AI build the site from a chat message, with the caller supplying no HTML. It also explicitly differentiates from the sibling alternatives create_project + create_new_site, so an agent can tell which one to pick. This is more than a restatement of 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?

The description gives explicit when-to-use context: for clients with no model of their own (the Hugging Face Space front end), and tells the agent to prefer create_project + create_new_site if it can author HTML itself. It also specifies the prerequisite call order, 'Call create_project first, then relay each user message here verbatim,' and explains how to handle the 'collecting' and 'built' response phases.

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

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

With no annotations provided, the description carries full responsibility for side-effect disclosure. It clearly states 'This is a READ: it never reserves, registers, or charges anything,' and explains the meaning of premium and renewal_price cliff, offering rich behavioral context beyond what annotations could provide.

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

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

The description is front-loaded with the purpose and usage, then explains return field semantics, then states the read-only nature. Each sentence earns its place with no redundancy or wasted wording.

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

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

Given the simple one-parameter schema and the presence of an output schema, the description provides complete context for correct invocation. It names the key return fields, explains how to interpret premium and renewal_price, and clarifies the tool's non-mutating behavior.

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

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

Schema coverage is 0%, so the description must compensate. It specifies the parameter should be an 'exact domain' with the example 'orivox.ai', adding meaning beyond the bare string type. However, it leaves some ambiguity about acceptable formats (e.g., protocol, path, wildcards), so it is not fully exhaustive.

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

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

The description clearly states it performs an 'authoritative availability check for ONE exact domain' and gives a concrete example. It explicitly differentiates from search_domains by directing usage to this tool when a specific domain is named.

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

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

It explicitly says 'use this, not search_domains, when the user names a specific domain,' providing clear when-to-use guidance. It also instructs on how to handle output, such as quoting premium pricing and always telling the user both price and renewal_price.

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

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

With no annotations, the description carries the full burden, and it does well: it declares read-only behavior, no account requirement, how the build_seen stamp is compared, what the two statuses mean, and what action to take when outdated. This is far more than the bare function name would convey.

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 purpose, followed by a precise build_seen instruction, then the behavioral statuses and when-to-use guidance. Every sentence adds necessary information, and the structure helps an agent parse the most critical constraint 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?

For a single-parameter, read-only utility with an output schema, the description covers all needed invocation context: when to use it, exact parameter value, expected statuses, outcomes, and auth requirements. Nothing essential is missing for an agent 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?

The schema only defines build_seen as an empty-default string with zero documentation coverage, so the description must explain the parameter. It does exactly that by giving the exact required literal, '2026.07.30-03', and instructing the agent to copy it verbatim—critical 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 states a clear, specific action: checking whether the user must re-add the Orivox connector and showing the version changelog. This distinguishes the tool from all siblings, which operate on domains, sites, projects, or account data rather than connector/version state.

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

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

The description gives explicit triggers: use when a feature is missing, when behavior doesn't match docs, when asked about versions, or when the user mentions re-adding the connector. It doesn't enumerate exclusions or name sibling alternatives, but the context is clear enough that an agent can decide when to call 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?

With no annotations provided, the description carries the full burden and does so admirably. It declares 'Read-only; changes nothing,' and details the return shape (files[] with hosted url and source) and semantics of an empty list. This gives the agent confidence about side effects and expectations.

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 but information-dense. It leads with the core purpose, then usage, return format, edge case, and safety note—each sentence earns its place. No filler or redundancy.

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

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

For a simple read-only tool with one parameter and an output schema, this description covers purpose, when to use, parameter provenance, return behavior, empty-list meaning, and safety. There are no significant gaps for an agent to execute 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 schema has 0% description coverage, but the description fully compensates by explaining that token_id is the value 'request_image_upload_link returned.' This is precisely the meaning an agent needs and goes beyond the bare 'string' type. The single parameter is well-documented.

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

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

The description opens with a specific verb+resource: 'Return the EXACT images the user chose on their upload link.' It clearly distinguishes itself from siblings by referencing token_id from request_image_upload_link and contrasting with 'guessing from the whole gallery' (i.e., list_gallery_images). This makes the tool's 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?

Explicitly states when to call: 'Call this after the user says they uploaded or picked their images.' It also tells the agent to pass the token_id from request_image_upload_link. It further explains how to handle an empty files list ('ask them to open the link...'), providing clear decision guidance. This exceeds mere context by offering alternatives and edge-case behavior.

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

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

With no annotations provided, the description carries the full burden, and it discloses meaningful behavior: it scrapes 1-8 pages, can auto-discover pages, compresses images, and does not rebuild the site. It also explains the strict boolean requirement for confirm_rights, which is a subtle but important runtime behavior.

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

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

The description is somewhat long but each sentence serves a purpose: safety precondition, strict boolean explanation, workflow, and parameter hints. The strict-boolean rationale is a bit verbose, but it is directly relevant to avoiding a validation pitfall. Overall, it is structured and does not waste words.

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

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

For a 7-parameter tool with no annotations, the description provides strong workflow and behavior context, including the fact that this is step 1 of a two-step process. Still, it omits explanation of the only required parameter project_guid as well as design_mode and index_page_url, so an agent may not fully know how to call it correctly in all cases.

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

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

Schema description coverage is 0%, so the description is needed to explain parameters. It gives useful semantics for confirm_rights, page_urls, crawl_domain, and max_pages, and mentions the job_guid output. However, it does not explain the required project_guid parameter or the design_mode and index_page_url parameters, leaving notable gaps.

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

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

The description states exactly what the tool does: imports an existing website by URL, scrapes 1-8 pages, and downloads/compresses images. It also clearly differentiates the tool from its sibling by stating 'No AI rebuild happens yet' and positioning it as 'step 1 of 2' with copy_website_rebuild as the next step.

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

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

The description gives an explicit precondition: only call after the user has confirmed ownership/rights. It also clearly states when this tool fits in the workflow and directs the agent to pass the returned job_guid to copy_website_rebuild next, making the choice between siblings unambiguous.

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

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

The description reveals important behavioral traits beyond what any annotations provide: it does not build the site itself, it returns design_mode plus per-page extracted content in source page order, it echoes the same steps in rebuild_instructions, and it is not metered. Without annotations, the description carries the burden of behavioral disclosure and mostly meets it, but it does not explicitly address side effects, authentication, or failure behavior.

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

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

The description is long but densely useful and well-structured. The purpose gets front-loaded in the first sentence, followed by a numbered protocol that earns its length toward the workflow. Nothing is filler; every sentence supports selection or correct invocation.

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 output schema exists and annotations are absent, the description covers prerequisites, input parameter meanings, return shape and order, design_mode semantics, image handling, downstream integration with create_new_site, and the 'reported' field behavior. It is complete enough for an agent to invoke the tool correctly and continue the overall build process.

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 does: job_guid is defined as the value from copy_website_extract, and project_guid is identified as the same one that must be passed to create_new_site. It gives contextual meaning, though it lacks a clean standalone definition for each parameter.

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 the exact action: 'Rebuild a copied website from a completed copy_website_extract job (step 2 of 2)'. It further clarifies that the tool itself does NOT generate the site, but returns extracted content for the agent to rebuild via create_new_site. This clearly distinguishes it from copy_website_extract and create_new_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?

The description gives an explicit numbered protocol: call it only after copy_website_extract, with job_guid from that job, then submit the rebuilt HTML via create_new_site with the same project_guid, then handle create_new_site's needs_attention worklist. It also provides a practical cost/behavior distinction: 'This call is NOT metered; create_new_site is.'

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so thoroughly. It discloses idempotence ('Safe to call more than once'), the meaning of the 'created' flag, the meaning of 'tables', and the system-managed naming behavior. This goes far beyond what structured fields would indicate.

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 substantial but every sentence earns its place. It front-loads the core purpose in the first line, then adds usage criteria, idempotency, return semantics, and scope boundaries in a logical order without redundancy.

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

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

For a one-parameter tool with no annotations and no schema descriptions, this is remarkably complete. It covers the purpose, when to use it, exception behavior, idempotency, return values, and the sibling tool for reading data. The only slight omission is explicit detail on the project_guid parameter, which is minor given its self-explanatory name.

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

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

The schema has 0% description coverage, so the description must compensate, and it only implies that the single 'project_guid' parameter refers to 'this project.' The parameter name is fairly self-explanatory and the one-parameter shape makes mistakes unlikely, but the description never explicitly explains what value to pass or how to obtain it.

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

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

The description states a specific verb and resource: it creates the project's database so the published site can store visitor submissions. It also explicitly distinguishes itself from the query_database sibling by declaring 'SCOPE: this CREATES the database' and 'To read what visitors submitted, use the query_database 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 description gives clear when-to-use conditions: call when the site needs to KEEP visitor submissions or when the user asks where form submissions go. It also states what this tool is NOT for, naming query_database as the alternative for reading submissions, which is strong 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?

With no annotations, the description carries the full behavioral burden, and it does useful work: it discloses that inline on*= handlers are stripped by the save sanitizer, that client-side logic should use addEventListener, that the document must be submitted in one shot, and that the response includes preview_url, auto_fixed, and needs_attention. It does not discuss side effects like overwriting behavior, but the behavioral details provided are substantial.

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 tightly packed and well ordered: purpose first, then workflow, then expected behavior and sanitization caveat. No sentence is wasted; important constraints are stated directly, and the warning about inline handlers is placed exactly where it is most actionable.

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 two simple parameters and no annotations, this description is effectively complete. It tells the agent the required preparatory step, the exact payload format, the sanitization hazard, the functional requirement (all controls must work), and the follow-up path through apply_dom_ops. The presence of an output schema further covers return-value expectations.

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 gives a clear meaning for the html parameter: the full document from <!DOCTYPE html> through </html>, with script logic allowed. However, it never explicitly explains where project_guid comes from or that it should be the one returned by create_project, leaving that parameter partially inferred rather than documented.

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

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

The description opens with a specific verb and resource: "Submit the complete one-shot HTML document for a newly created project." It is further refined by workflow context (call create_project first, pass it in one call) and by the sibling follow-up apply_dom_ops, so an agent can distinguish this tool from nearby creation/editing tools.

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

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

The description explicitly sequences the tool: "Call create_project first..." and directs the agent to use apply_dom_ops for the returned needs_attention items. It gives clear practical context, though it does not explicitly say when to choose it over alternatives like build_site or exactly 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?

With no annotations, the description carries the full burden and compensates well by revealing validation behavior and refusal conditions: filenames are validated, and traversal/non-html/overwrite cases are rejected. It does not mention permissions or error-return style, but the output schema covers result structure, and the safety-critical constraints are explicitly disclosed.

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

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

Two short, information-dense sentences. The central purpose and file-name format are front-loaded, followed immediately by important validation rules. No wasted words.

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

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

For a simple 3-string-parameter creation tool, the description covers intent, file naming, HTML content, and core safety constraints such as refusal to overwrite or accept unsafe filenames. It is only slightly incomplete because project_guid semantics are left to inference and no guidance is given about integrating the page into a larger build.

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 usefully clarifies file_name by example ('about.html') and says html is 'full html', but it does not explain project_guid at all beyond its obvious name. The description partially compensates, but not completely.

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 clear action and resource: 'Create a new flat HTML page.' It goes beyond the tool name by specifying the page is flat HTML and clarifying file naming with 'file_name like about.html', which distinguishes it from site-level or project-level creation tools such as create_new_site or create_project.

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 clarifies the intended use case: creating a standalone, new HTML page with full HTML content. It does not explicitly list when not to use it or name alternatives like build_site, but the 'new' and 'flat HTML' phrasing provides enough context for appropriate use.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden, and it does so richly. It explains that the tool requires a user-mode preference question, returns the exact artifact fields, mandates following build_instructions, applies the same website-count limit as the parent flow, and explicitly supports client-side apps—so the agent knows not to decline them for 'needs a backend'. Given no annotations, this is strong, specific behavioral detail.

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 longer than average, but most sentences add needed operational context: the user prompt requirement, mode consequences, return contract, plan eligibility, and app support. Some phrasing is slightly redundant, such as repeating that both modes share validation contracts, 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 two-parameter optional tool, the description is quite complete: it names the return values, the required follow-up action, plan eligibility, and the app-deliverable scope. The one notable gap is the unexplained title parameter, and an output schema is present but not described, so the description does not fully cover return formatting details.

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

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

Schema description coverage is 0%, so the description must compensate. It provides deep semantics for design_mode by explaining creative vs structured, but it never explains the optional title parameter, its default of null, or observable effects of omitting it. That gap makes the coverage good for one parameter but incomplete overall.

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 a new hosted website project'. It also declares itself the 'DEFAULT way' to handle website-build requests and distinguishes itself from pure artifact/channel HTML by emphasizing a real, deployable site the user can preview, edit, and publish.

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

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

The description clearly tells the agent when to use it: as the default for build/make/design website requests while the connector is present. It also gives a concrete before-calling step: ask the user for 'creative' vs 'structured' unless already stated. It does not explicitly enumerate alternatives to avoid, but it names create_new_site for the follow-up rather than competing selection 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?

With no annotations, the description carries the behavioral burden. It goes beyond 'delete' by warning that referencing pages may remain and require remediation, which is valuable. It does not disclose reversibility, permissions, failure behavior, or what happens if validation is skipped.

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 carry all the needed context with no filler. The core action is front-loaded, and the consequence plus remediation are provided immediately in the second sentence.

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

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

For a simple two-parameter delete operation with an output schema present, the description covers the main risk and the needed follow-up action. It could be more complete by stating what happens for missing files or how project_guid is resolved, but the essential behavior is sufficiently documented.

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

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

Schema description coverage is 0%, so the description must compensate for the two parameters. It names the asset file concept but never explains file_name or project_guid formats, scoping, or how they relate. The description adds little beyond the parameter names already present 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 states a clear action ('Delete') with a specific resource ('one flat shared asset file'). It distinguishes itself from sibling delete tools (delete_page, delete_project) and write_asset by naming the exact target type.

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

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

The description gives useful surrounding context: leftover page references are surfaced by validate_project and should be repaired with apply_dom_ops. However, it never explicitly says when to choose this tool over alternatives such as delete_page, delete_project, or write_asset.

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

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

With no annotations, the description carries the full burden. It discloses a key side effect: links to the deleted page become dead links detected by validate_project and fixed via apply_dom_ops. It also notes an important restriction on index.html.

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

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

The description is concise and front-loaded with the core action. The second sentence adds valuable edge-case context without any filler or redundancy.

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

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

This tool has few parameters and an output schema, so the description needn't explain return values. It covers the main action, a caveat, and the downstream consequences. It falls slightly short on clarifying parameter value formats, which is more of a parameter semantics gap than a contextual completeness issue.

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

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

Schema description coverage is 0%, and the description does not explain the expected format of the 'page' parameter or the semantics of 'project_guid'. It only implies that 'page' is a page from the site, leaving agents to guess whether it is a path, filename, or identifier.

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?

Provides a clear verb and resource: 'Delete one page from the site.' This distinguishes it from sibling tools like delete_asset and delete_project, though it does not explicitly contrast it with replace_page or read_page as 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?

Gives clear context for when deletion has downstream effects and specifies an explicit limitation: index.html cannot be deleted. It routes the agent to validate_project and apply_dom_ops to handle resulting dead links, though it doesn't cover when to choose this tool over replace_page or read_page.

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

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

No annotations are provided, so the description carries the full burden and does so excellently: it labels the operation as PERMANENT, IRREVERSIBLE, and specifies the scope (files + database row). This gives an agent exactly the risk awareness needed.

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

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

Two sentences with no filler: the first fronts the destructive scope immediately, and the second delivers the user-confirmation requirement. Everything 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 single-parameter destructive tool with no annotations and no output schema, the description covers the resource, scope, permanence, and user-confirmation requirement. Nothing crucial is missing for calling this tool correctly.

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

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

Schema description coverage is 0% and the description does not explicitly explain project_guid. However, this is a single, self-explanatory required parameter in a delete_project tool, so the meaning is reasonably inferable despite the lack of explicit semantic enrichment.

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 ('deletes'), the exact resource (Orivox website), and what is affected (files + database row). It clearly distinguishes this destructive action from siblings like update, build, or publish.

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?

Description is explicit about when to call: only after user confirmation, and never from an ambiguous request. It clearly communicates safety guardrails for a destructive tool.

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

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

With no annotations provided, the description fully carries behavioral disclosure. It reveals that nothing is purchased or registered, that the registrar is re-checked for availability, that taken domains return byoa_domain_not_available, and that availability_unverified in warnings signals an unreachable registrar. It also flags cost volatility including premium one-time prices and renewal cliffs, which is essential nontrivial behavior.

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

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

The description is long but each sentence earns its place: the first sentence defines the deliverable_link, the next clearly disclaims purchase behavior, then project_guid, then availability and warning handling, then pricing/cliff and cost. It is front-loaded with the core distinction and structured logically by operational steps.

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

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

The description is complete for agent execution: it tells the agent what the link is for, how to handle the optional project_guid, what to do when domain is unavailable, what to do when availability is unverified, and what success fields to relay to the user. The presence of output_schema covers the response shape, so the description need not enumerate further return details.

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

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

Schema description coverage is 0%, and no structured descriptions exist for the two parameters. The description adds meaningful semantics for project_guid: it is optional, omit for stand-alone purchase, and pass only to pre-link to a specic site. It does not explicitly describe the required parameter by schema name, but the domain itself and its behavior are assumed through the domain purchase link. This substantially compensates for schema coverage gaps.

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

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

The description states a clear verb+resource: "Get the link where the USER buys a domain." It also explicitly distinguishes itself from purchase/registration tools: "This tool does NOT purchase or register anything, and it never will -- no tool here can." This makes it stand apart from domain-related siblings like check_domain and apply_dom_ops.

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 direct guidance on when to use the tool and when project_guid should be omitted or included. It also clarifies the relationship to publish_website for later connecting the domain. However, it does not explicitly name alternate tools for ordinary availability checks, so the usage guidance is strong but not maximally prescriptive.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses that the tool returns a preview URL and page list and implies a read-only getter, but it does not mention prerequisites, side effects, or the meaning of the optional page parameter. This is a moderate level of transparency for a simple read method.

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 no wasted words. It communicates the core return values immediately and is appropriately sized for a 2-parameter read-only tool.

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

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

With an output schema present, the description need not repeat return details. However, the minimal description leaves meaningful gaps: the exact meaning of the page parameter, any prerequisites or side considerations, and how this differs from related context tools are not addressed. This is acceptable but not fully complete.

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

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

The input schema has 0% description coverage, and the description does not explain the semantics of project_guid or page beyond the implied 'for a project'. The optional page parameter's role in filtering or selecting pages from the list is left completely to inference, so the description fails to compensate for the schema 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 uses a specific verb ('Return') and a concrete resource ('absolute preview URL and page list for a project'), making the tool's function clear. It is distinct from siblings like get_project_context, publish_website, or build_site, which reference different resources.

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

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

The description implies usage when the agent needs a preview URL or page list for a project, but it does not explicitly state when to use this tool versus alternatives. It also provides no exclusions or references to sibling tools, leaving the usage context to be inferred rather than 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?

There are no annotations, so the description carries the full burden of explaining behavior. It indicates a read-only 'Return' operation, but it does not disclose what happens for a null page, whether project_guid must reference an existing project, or if there are any side effects. Basic getter behavior is conveyed, but important behavioral nuances are left unspecified.

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

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

The description is a single front-loaded sentence that states the operation, the resource, and the payload contents. Every word earns its place with no fluff or redundancy.

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

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

An output schema exists, so return values need not be described, but the tool still lacks crucial operational context: what project_guid format is expected, what page values are valid, and whether get_project_context is a prerequisite for apply_dom_ops. At 0% schema description coverage, this gap is significant.

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

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

Schema description coverage is 0%, so the description must compensate for the two parameters, but it does not explicitly describe project_guid or page. It only implies a page relationship through 'project page.' The agent has to infer rather than be told what project_guid is and how page selects a context.

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

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

The description states a specific operation: 'Return the DOM context summary' for a project page, including what the summary contains (sections, elements, allowed operations). It is clearly distinguishable from siblings like apply_dom_ops (which mutates) and list_projects (which lists projects/pages).

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

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

The description implies when to use the tool—when you need the DOM context for a project page—but it does not explicitly explain when not to use it or whether it should precede apply_dom_ops. The intended use is reasonably inferable, but no alternative routing is provided.

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

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

With no annotations provided, the description carries the full burden. It discloses the strict boolean behavior (StrictBool rejects 1/'yes'/"true") and explains the active/attached state concept. It does not explicitly state that this is a read-only operation or mention pagination/ordering, but the 'List' verb implies a read operation. The added context goes beyond the schema.

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

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

The description is three sentences, each earning its place: first defines the tool, second provides usage context, third explains the parameter constraint. It is front-loaded with the primary purpose and contains no fluff.

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

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

This is a simple tool with one optional parameter and an output schema that covers return values. The description covers the filter behavior, the output fields, and the integration with publish_website. It is complete for the complexity involved.

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%, but the description fully compensates. It explains the meaning of available_only (true vs false) and the strict JSON boolean requirement, including rationale. This adds significant meaning beyond the bare schema property of type boolean with default false.

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

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

The description clearly states the tool lists the business's custom domains with specific fields (guid, domain_name, active/attached state). It is a specific verb+resource. However, it does not explicitly distinguish itself from the sibling tool 'search_domains', which might also list domains based on search criteria, so it lacks clear sibling differentiation.

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

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

The description gives explicit when-to-use context: passing available_only=true filters to domains not yet attached to any project, and these are the ones publish_website can connect. It also instructs to use a returned guid as publish_website's domain_guid. This is clear usage guidance with a direct alternative relationship.

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

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

With no annotations provided, the description carries the full transparency burden and does so thoroughly. It explicitly states the tool is read-only, returns newest-first, may include null dimensions, and indicates truncation behavior with `truncated=true`. It also warns against rewriting URLs, which is a critical behavioral constraint.

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 packed with necessary information but not bloated. Every sentence adds value: purpose, when to use, parameter explanations, and behavioral details. It is front-loaded with the core purpose and uses clear structure.

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

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

For a 2-parameter read-only list tool, the description covers all essential aspects: use case, parameter semantics, output fields, pagination, and safety. The output schema exists and the description complements it by explaining edge cases like null dimensions and truncation, making the tool fully understandable without external docs.

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?

Although the schema has no parameter descriptions (0% coverage), the description fully explains both parameters: `role` enum values and `limit` default/max, plus the meaning of `truncated=true` in the response. This is high-value semantics beyond raw schema.

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

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

The description clearly states the tool lists images the user already has in their Orivox media gallery and provides hosted URLs for direct use. It distinguishes itself from siblings by preemptively contrasting with upload requests ('Check here FIRST... before asking them to upload'), making 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?

Explicit usage guidance is given: check this tool first when the user mentions 'my images', their gallery, or already-uploaded pictures. It also advises against re-calling with a bigger limit unless truly needed, which is actionable alternative 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?

With no annotations, the description carries the full burden. It explains the potentially confusing owner_email behavior, preemptively noting that empty is not a data bug on own projects. This is exactly the kind of behavioral disclosure that helps an agent interpret results correctly.

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

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

Three sentences, each earning its place: function, usage guidance, and a critical data quirk. Well-front-loaded and free of 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 zero-parameter, read-only listing tool with an output schema, the description covers what is returned, when to use it, and a likely misinterpretation. Nothing significant 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?

The tool has no parameters, and the schema coverage is 100% (vacuously). The baseline for 0 params is 4. The description adds no parameter info because none is needed, and it instead clarifies output semantics.

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

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

Description uses specific verb 'List' and resource 'Orivox websites' with concrete output fields (guid, title, published state, preview URL). It is clearly distinct from siblings like list_domains or whoami.

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

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

Explicitly states when to call: 'Call this before create_project when you are not sure whether the requested site already exists, or when the user asks what sites they have.' This provides clear context and differentiates from create_project.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does so thoroughly. It discloses that repeated calls replace the widget rather than duplicate it, that changed is byte-honest, that some outcomes require verification via get_preview_url, and that live sites need publish_website to reflect the change.

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 long enough to be trustworthy but tightly structured: summary, trigger conditions, param meanings, action semantics, output states, and publication caveat are each in clearly separated, purposeful sections. Every sentence adds decision-relevant information rather than repeating schema entries or fluff.

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

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

For a 4-parameter mutation tool with no annotations and minimal parameter schema coverage, this description is complete. It covers when to use it, what each parameter means, idempotent replacement behavior, removal, every outcome state, how to verify contradictory results, and the publish/deprecation implication. Nothing an agent needs to call it correctly is left to guesswork.

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

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

The schema has zero property descriptions, but the description adds concrete semantics for icon, position, and action, including defaults and replacement behavior. It even explains the meaning of byte-honest output states beyond the input schema. The only parameter left implicit is project_guid, but its purpose is evident from its name and the required context of 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?

The description specifies a concrete verb and resource: add or remove Orivox's accessibility widget, and even describes the widget as a floating button with reader aids on every page. It also names apply_dom_ops as an alternative to avoid, which clearly separates this tool from a sibling. An agent can tell what this 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 gives explicit triggers: use this when the user asks for an accessibility button, menu, toolbar, screen-reader support, or accessibility compliance. It also gives an explicit exclusion: do not build the widget by hand with apply_dom_ops, and it explains when to call again for replacement or removal.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does so well. It discloses that publishing can take up to a minute due to the production CSS build, that empty projects are refused with a specific error (byoa_publish_no_files), and that plan/subdomain nuances may affect success. This is far beyond the minimum for a publish 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 compact and well-structured: a clear sentence for purpose, a detailed but focused passage (two sentences) for domain options and requirements. Every sentence earns its object, and no unnecessary filler is present.

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 command has 2 parameters, an output schema, and no annotations, the text sufficiently covers all relevant dimensions: purpose, parameter semantics, usage conditions, unexpected impacts (time delay, errors), and the preconditions. There is also an explicit error indication, which helps an agent anticipate a controlled failure.

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?

Although schema description coverage and 0% and there are only 2 parameters, the description compensates fully: it explains project_guid is the required project and that the project must already be built, and domain_guid is optional, its default behavior (free subdomain), and how to obtain/use it for a custom domain (referred to list_domains). The overview adds semantics beyond what the bare input schema provides.

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

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

The description begins with 'Publish a built Orivox website live', which clearly states the action (publishing), the target resource (website), and the state (live). It clearly differentiates from sibling tools like build_site and create_new_site by describing the act of taking an already-built site to production.

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

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

The description explicitly explains both usage paths: omit domain_guid for a free subdomain, or pass a domain_guid for a custom domain. It also provides necessary prerequisites (the site must be built via create_project + create_new_site) and references list_domains as the source for domain_guid, which helps an agent select and use the tool correctly.

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?

Since no annotations are provided, the description carries the full behavioral burden. It clearly says the operation is read-only, never spends the user's quota, and returns rows newest first with id, created_at, and submitted data. This is solid coverage for a read-only 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 three concise sentences, each earning its place: what the tool returns, when to use it, and how collection names map to the site. Key details are front-loaded and nothing is redundant.

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

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

For a 4-parameter tool with no annotations and an output schema, the description gives enough context to safely invoke it: return shape, ordering, total count, collection naming, and quota behavior. The only real gap is how an agent would discover the exact project_guid and collection values, but the description provides enough for correct usage in most 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?

The description adds real meaning beyond the schema by explaining that 'collection' refers to the data-collection values used in the site's forms. However, it does not directly clarify project_guid or how offset/limit interact beyond the newest-first ordering, so parameter guidance is incomplete.

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

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

The description opens with a specific verb and resource: 'Read what visitors submitted to one of this site's collections.' The concrete examples — bookings, leads, RSVPs, orders — remove ambiguity and clearly distinguish this from the sibling tools like create_database or build_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?

It explicitly states when to use the tool: when the user asks what came in, who signed up, or wants a summary of submissions. It doesn't mention alternatives or exclusions, but the guidance is precise enough for an agent to route on.

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

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

With no annotations provided, the description carries the full behavioral disclosure. It makes clear this is a no-cost read operation, returns real saved markup rather than working memory state, resolves partial templates, and produces exactly the representation the preview would serve.

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 focused and front-loaded: the opening sentence names the tool's real behavior, and each subsequent part adds concrete value. There is no repetition of schema information and 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 a simple two-parameter read operation with an output schema and no annotations, this description is complete. It covers what the agent gets, how it differs from the most similar sibling, and an important cost consideration. An agent can choose and invoke the tool correctly.

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

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

There is no schema-level parameter documentation and the description does not explicitly define project_guid, page, or how to obtain the project identifier. The term 'one page' and the page string schema give some guidance, but the required project_guid is left to inference.

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+resource: it reads one page's actually saved markup, with partials resolved, matching the preview output. This clearly distinguishes it from get_project_context and other sibling tools that return summaries or mutate pages.

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

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

It explicitly says when to use it: verify what actually survived a save. It also contrasts get_project_context, which returns a summary that intentionally omits most attributes, and notes that reading is free and does not spend the user's quota.

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 important behavioral traits beyond the schema: it replaces entire page documents, respects a strict full-document contract, never creates a new page, and never modifies index.html. With no annotations present, this gives agents a meaningful safety and scope profile, though it doesn't cover result/error/response behavior.

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

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

The description is short, front-loaded with the core behavior, and earns every sentence. It gives scope, the replacement contract, and an explicit alternative in fewer than 80 words.

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

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

For a 3-parameter replacement tool without annotations or an output schema, the description is largely sufficient: main behavior, usage boundaries, and sibling contrast are all present. Missing are explicit output/return behavior and the meanings of project_guid/file_name, but those are strongly inferable from the tool name and contract.

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 offers only names/types for project_guid, file_name, and html. The description richly explains html ('complete replacement document from <!DOCTYPE html> through </html>'), and implicitly clarifies file_name as the target existing page, but it does not explicitly define project_guid or enumerates exact values/formats for file_name. Partial compensation, not full.

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

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

Description states a specific action — 'Rewrite an EXISTING page wholesale' — with a clear resource. It distinguishes itself from create_page, create_new_site, and apply_dom_ops by stating what it does not do and where the boundary lies.

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?

Explicit usage guidance: 'Use this for redesigns; use apply_dom_ops for small edits.' It also names create_pege and create_new_site as ownership boundaries, so an agent can choose between the sibling tools with confidence.

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

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

With no annotations to fall back on, the description carries the full burden of explaining behavior. It discloses the actual return value (upload_url), the limitation that tool calls cannot carry image bytes, the one-hour validity of the link, and the fact that token_id must be kept for later use. It also explains what the user can do on the upload page, which makes the tool's behavior much more predictable.

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 action and then gives a complete workflow, but it is somewhat wordy and repeats the same directive multiple times. It could be tightened without losing important context, but the structure moves logically from purpose to behavior to next steps, so the length still 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?

The description fully covers the minimal but critical context for this tool: how to call it, what the response contains, what to do with the response, how to finish the workflow, and what prerequisites must exist. The existence of an output schema reduces the need to enumerate return fields further, and nothing important 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%, so the description must resolve any ambiguity about parameters. It explicitly describes both: project_guid must reference an existing project, and role='logo' is for logo uploads while the default 'content' is for any other image. This adds real meaning beyond the raw schema.

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

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

The description clearly states what the tool does: it returns a browser link the user opens to upload real image files, rather than trying to ingest image bytes. It distinguishes itself from the broader site-building flow and explicitly frames itself as the reliable upload path for photos, drawings, logos, or multiple images.

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

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

The description gives explicit when-to-use guidance: call it anytime a user has an image, never try to handle attached images directly, and surface the link because the user has no other way to see the upload option. It also explains prerequisites and next steps: need an existing project_guid, then check_upload_link, then apply_dom_ops.

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

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

With no annotations, the description fully discloses behavioral traits: read-only nature (never reserves or charges), exact-match detection logic, response markers, sorting order, pricing pitfalls, sandbox environment behavior, and the need to relay caveats. This goes far beyond a basic summary.

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 long and dense, but nearly every sentence carries essential operational information. It is front-loaded with the core purpose and then systematically covers response markers, result fields, pricing warnings, and sandbox behavior. Some restructuring into clearer sections would improve scannability, 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?

Given the tool's complexity, the single-parameter schema, and presence of an output schema, the description fully equips the agent: it explains how to interpret results, what markers indicate, how to present pricing traps, and when to delegate to other tools. The output schema details the suggestion fields, and other behaviors are comprehensively covered.

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

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

The input schema provides only a generic 'query' string with 0% description coverage. The description compensates thoroughly by explaining what may be in the query (keyword vs. one full domain vs. phrase), constraints (only one domain), and how the query affects the response (exact check vs. suggestions).

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

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

The description clearly states the tool searches real-time domain availability and prices, distinguishing it from siblings like check_domain (per-domain exact checks) and list_domains (likely listing owned domains). It specifies the verb, resource, and unique scope of handling keyword suggestions plus exact-match recognition.

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

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

Provides explicit usage context: pass a keyword for suggestions or one full domain for exact checking. It also names the alternative for multiple domains (check_domain) and the follow-up tool for purchasing (get_domain_purchase_link), making when-to-use and when-not-to-use unambiguous.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses two valuable behavioral facts: only provable problems are reported, and the tool fails open, meaning absence of reported problems should not be treated as absolute proof of correctness. The word 'Report' also sufficiently suggests a non-mutating 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 one efficient sentence that front-loads the action and resource, uses a parenthetical for concrete examples, and adds a meaningful fail-open behavior. Every word earns its place.

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

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

Because an output schema exists, the description doesn't need to explain return values. It covers the general purpose, the class of problems, and a key failure behavior. The main contextual gap is the ambiguous optional `page` parameter, but that is already captured under parameter_semantics.

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 description does not explain the parameters beyond mentioning a generic 'project page.' It doesn't say how to pass or set `page`, what `null` means for `page`, or why `project_guid` is needed. The schema names are only marginally self-explanatory, so this is a clear missing piece.

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: it reports provable problems for a project page, and it lists concrete problem categories such as broken images/links, missing files, and save/preview status. It is clear about the core intent, though it does not explicitly distinguish itself from sibling tools like check_domain or check_upload_link, which also involve detecting link-related issues.

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?

When to use the tool is implied rather than explicit: an agent can infer it should call this when checking a project page for health or correctness issues. The description does not provide clear exclusions or alternatives such as 'use check_domain for DNS issues' or 'use this before publish_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?

With no annotations provided, the description carries the full burden. It transparently explains that the data is 'resolved from the verified WorkOS-token email via identity_resolve', giving insight into the authentication and resolution process. It does not mention failure modes, but for a read-only identity lookup this is sufficient.

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, information-dense sentence that front-loads the action and result. Every clause adds value: the return data, the resolution method, and the phase context.

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

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

For a simple, parameterless tool with an output schema, the description is complete. It specifies what is returned (business_guid and plan), how it is resolved (verified WorkOS-token email via identity_resolve), and its role ('Phase 0 end-to-end gate'), covering both function and context.

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

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

The tool has zero parameters, so the schema fully covers this dimension. The description correctly omits parameter details, and the baseline for zero-parameter tools is 4.

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

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

The description explicitly states 'Return the caller's business_guid and plan', using a specific verb and resource. It clearly distinguishes this identity tool from the domain/project focused sibling tools.

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

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

The description implies usage through its core function ('Return the caller's...') and adds 'Phase 0 end-to-end gate' to provide context for when it is used. However, it does not explicitly exclude alternatives or name them, as there are no identity-related 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?

Given no annotations, the description carries the full behavioral transparency burden, and it does so well. It explicitly says the tool overwrites, stores content verbatim, restricts file names to flat lowercase names, and enforces no folders. That is substantial transparency 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 front-loaded with the core operation and resource, then immediately covers constraints and usage context. Every sentence adds necessary information, and the embedded relative-reference example is useful without blurring 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?

For a three-parameter tool with no annotations, the description covers format, constraints, verbatim storage, and relative-reference usage. The main gap is the missing guidance around project_guid, and slight ambiguity about whether overwriting requires any preconditions.

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 needed to compensate. It meaningfully explains file_name constraints and content behavior, but it does not explain project_guid. The agent must infer that project_guid identifies the project or site containing the pages.

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 a specific verb-resource pair: create or overwrite a flat shared asset file. It narrows the scope to css/js/json, gives relative-reference examples, and does not include any sibling differentiation that would confuse an agent.

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

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

The description provides clear usage intent: use assets for shared styling/logic across pages instead of duplicating inline. It doesn't explicitly name a when-not-to-use sibling, but the asset-vs-page distinction and file-type restrictions make tool selection fairly clear.

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