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 provided, the description carries full responsibility for behavioral disclosure. It states the tool is read-only and requires no account, explains the build-stamp mechanism and the frozen stamp, and describes both possible statuses (outdated and up_to_date) and their consequences. This is thorough and non-contradictory.

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?

Every sentence in the description serves a purpose: purpose, exact parameter value, mechanism, status meanings, and usage triggers. It is front-loaded with the core function and then provides necessary operational details. No filler or redundant information. The structure is efficient given the complexity of the tool.

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

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

The description is complete for an agent to call this tool correctly. It covers the exact parameter value, the behavior in each outcome, and the situations that warrant invocation. The existence of an output schema (not shown) covers return values, so the description does not need to explain them. No missing critical information.

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

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

The input schema provides only a string type with a default and no description (0% coverage). The description compensates fully by specifying the exact value to pass (build_seen="2026.09.04-01") and explaining its role in the version-check logic. This is more than sufficient for an agent to correctly set the 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 clearly states the tool's purpose: check if the user must re-add the Orivox connector to get the latest tools/behavior and show the version changelog. It is specific and distinct from all sibling tools, none of which relate to updates or versioning. The purpose is unambiguous and immediately actionable.

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 lists when to use this tool: 'whenever the user says a feature is missing or not working as described, asks what changed / what version they are on, or right after they mention re-adding the connector.' It also provides a hard requirement for the parameter value (ALWAYS use the exact stamp) and explains the meaning of each status. This leaves no doubt about when and how to invoke the 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 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 present, the description carries the full burden and does so thoroughly: it discloses that Orivox cannot modify the user's registrar account, that re-calling the tool acts as the activation step, that a never-published site may be published automatically, that DNS propagation can take time, and that the site remains available on its subdomain throughout.

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?

Although longer than many descriptions, every sentence earns its place: purpose, prerequisites, first-call behavior, second-call activation, polling guidance, and edge-case diagnosis. The information is front-loaded and organized into logical workflow sections with 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?

The description fully covers a complex multi-step workflow: prerequisites, DNS instructions, user action, re-invocation as activation, automatic publishing, propagation delays, and troubleshooting via nameservers. Even though the output schema content is not visible, the description references the key output fields (dns_instructions, started, is_active, nameservers) and provides enough context for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning to 'domain' (an already-owned domain, not a purchase), but it never explicitly explains 'project_guid' or its role as the identifier of the target Orivox website. Only one of the two required parameters receives meaningful 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 opens with a specific verb and resource: connecting a domain the user already owns to their Orivox website. It clearly distinguishes itself from the buying flow and names the alternatives (search_domains / get_domain_purchase_link), so an agent can select it correctly among siblings.

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

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

It explicitly states when to use the tool ('Use this when...'), when not to use it ('This is NOT the buying flow'), and names the alternative tools for the excluded case. It also gives precise workflow guidance: call once to get DNS instructions, then call the same tool again after the user adds the record—and warns against repeated polling.

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 and delivers extensively: re-calling returns the SAME password and does not reset data, /app exists only on the published site and not the preview origin, the backend is Python/Flask ONLY and sandboxed with no internet, and it requires a plan that includes backends. These are precisely the behavioral traits that prevent an agent from giving users destructive or false advice.

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 nearly every sentence earns its place: purpose, trigger conditions, idempotency warning, deployment quirk, tech constraints, and plan gating are all decision-relevant. It loses a point for being a single dense wall of text rather than structured sections, which would improve scannability.

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 high-complexity tool with no annotations, the description covers all operational dimensions an agent needs before calling: outcome, prerequisites (plan requirement), failure handling ('say so plainly and offer the data-collection form'), environment behavior (published vs preview), and follow-up tool routing. An output schema exists so return-value documentation is already 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?

Schema coverage is 0%, so the description must compensate. It contextualizes both parameters implicitly — project_guid via 'same project' in the idempotency note, and collection via the 'from orivox import collections' helper and the mention of the admin page listing submissions — but never explicitly defines what the `collection` parameter controls or what values it accepts. The context helps an agent guess correctly, but the mapping is left implicit.

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 statement: 'Give this project a real Python backend, served at /app on its own site — so it can have a genuine LOGIN and admin area.' It clearly distinguishes the tool from siblings like create_database and build_site by anchoring on authentication and admin capabilities a static page cannot provide.

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 trigger conditions are given: 'Reach for this when the user wants something a static page cannot do: a password-protected page, an admin panel... anything needing a session.' It also names an exclusion ('A client-side password is not a login and must never be offered as one') and routes to related siblings for follow-up work (write_backend_file, read_backend_file, list_backend_files, read_backend_logs).

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the document replaces whatever index.html currently holds, that inline on* handlers are stripped by the save sanitizer, that client-side logic via addEventListener is allowed, and that the response includes preview_url, auto_fixed, and needs_attention. This is rich, non-obvious behavioral information.

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

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

The description is longer than average, but almost every sentence carries substantive guidance: payload format, tool ordering, rebuild semantics, alternative routing, and sanitizer constraints. It is front-loaded with the core action; minor awkward phrasing like 'ALSO how you REBUILD' and a slightly conversational tone keep it from a 5.

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

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

Given no annotations and two required parameters, the description covers the input format, the prerequisite call, return values, the destructive replacement behavior, sanitizer rules, and the distinction from apply_dom_ops and replace_page. The only minor gap is not spelling out project_guid by name, but the explicit create_project-first instruction provides a sufficient source for it.

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 richly explain the html parameter: the full document from <!DOCTYPE html> through </html> in one call. However, it never explicitly names project_guid or says to pass the project returned by create_project; it only implies this via 'Call create_project first' and 'the project's HOMEPAGE'.

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 ('Submit') and resource ('HOMEPAGE'), and adds the key scope constraint: it takes the complete one-shot HTML document. It is clearly differentiated from siblings because replace_page is said to refuse index.html while this tool is the designated replacement path for the homepage.

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 sequencing: call create_project first and follow its build_instructions, then pass the full HTML in one call. It also states when NOT to use it ('use apply_dom_ops for small edits'), when to call it again (wholesale redesign), and why replace_page is not a valid alternative for index.html.

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 provided, the description carries the full burden of disclosing behavior, and it does exceptionally well. It states what is destroyed (backend, data access), what is preserved (stored submissions, site pages), and explicitly corrects a dangerous misconception about the data being erased.

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

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

Three short sentences accomplish a high level of guidance with zero filler. The action is front-loaded in the first sentence, with the two most important caveats following in subsequent sentences. Every sentence earns its place.

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

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

For a single-parameter destructive tool, the description is highly complete: it states the action, the data that is kept, and the unaffected pages. An output schema is present, so return-value details are not required. It only lack nuance about whether the operation is reversible or how to re-establish a backend, which would be useful but not necessary.

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 provides no description for project_guid (0% coverage), so the description must compensate. It does by contextualizing the parameter through 'the project's backend' and 'its data access,' making clear the identifier refers to an existing project. It still leaves minor gaps, such as where to obtain the GUID or how to validate it, but the meaning is clear enough for a self-explanatory project 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?

The description opens with a specific verb and resource: 'Remove the project's backend and revoke its data access.' It immediately differentiates the tool from siblings such as delete_project, delete_page, and delete_asset by clarifying that the backend, not the project or pages, is being removed, and that stored data is preserved.

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

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

The description provides explicit when-not-to-use guidance: the app's stored data is kept, so this is not a way to erase submissions. It falls short of a 5 because it does not name alternative tools or conditions for when to choose this over siblings like create_backend or delete_project, instead relying on the agent to infer them.

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, the description carries the full burden and does a lot: it says the tool never purchases anything, notes non-production dashboard warnings, explains availability re-verification and the unavailable return value, mentions warnings for unreachable registrar checks, and discloses that purchases require real money and happen in the user's logged-in session. This is rich behavioral context beyond what annotations would 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?

Every sentence earns its place and the most important usage rule is front-loaded. The description is long, but each sentence covers a distinct behavioral or usage detail. It sacrifices brevity for critical safety and routing information; still structured.

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?

Comprehensively covers purpose, when to call, when not to call, response semantics, warnings, safety/real-money context, and what happens after purchase (list_domains, publish_website). For a 2-parameter payment-adjacent tool with no annotations, this is complete.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. It explains project_guid is OPTIONAL with a clear when-to-omit and when-to-pass rule, and implies domain_name is the one domain the user named. It also explains the output semantics (live price, renewal_price, premium flag, purchase_url, byoa_domain_not_available) even though an output schema exists.

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

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

States a specific verb+resource (get the link where the user buys a domain) and explicitly distinguishes itself from purchasing/registering, and from search_domains/check_domain. The agent can tell exactly what the tool does.

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

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

Gives explicit when-to-call guidance: ONLY at the payment step after the user has named ONE domain and said they want to buy it. Names alternatives (search_domains, check_domain) and explains why those already return prices so browsing needs no link. Also gives explicit when-not-to-call scenarios: not speculatively, not for several candidates.

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?

No annotations are provided, so the description should carry the burden. It only says 'List' and 'Free,' which implies a read-only operation but does not disclose auth requirements, side effects, ordering, or error behavior. 'Free' is ambiguous and adds little behavioral context.

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

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

The core sentence is short and clear. The stray 'Free.' is unnecessary and could be confusing, but it does not significantly detract from the overall concise 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 simple list operation with one parameter and an output schema, the description is minimally viable. However, it lacks usage guidance, any behavioral context, and does not fully leverage the schema to clarify parameters, so it is complete enough only for a straightforward agent.

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

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

Schema description coverage is 0%, so the description must compensate for parameter documentation. It does not mention project_guid at all, though the name is self-explanatory and the phrase 'in the project's backend' loosely implies the parameter's purpose. Still, formatting or validation details are missing.

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: list files in the project's backend. It distinguishes itself from read_backend_file (content of a file) and write_backend_file, though it does not explicitly name these sibling alternatives.

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

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

There is no guidance about when to use this tool versus alternatives like read_backend_file or list_projects. The description provides no context for selecting this over similar tools or exclusions for 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 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, the description bears full responsibility for behavioral disclosure. It clearly states this is a read operation and clarifies that it has no quota impact, which is useful for an agent's cost reasoning. Yet it does not mention what happens for non-existent paths, permissions, or encoding, leaving some behavioral uncertainty.

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 text is concise, uses front-loaded wording, and each sentence adds different value: the first explains the core function, the second adds a unique behavioral trait. No filler or irrelevant information 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?

For a purely descriptive read operation with two simple parameters and an output schema, the description is mostly adequate but not complete. The lack of parameter semantics and any pointer to when this file should be used vs the write-sibling leaves the agent with some inference to make. The output schema likely covers return values, but the input side is under-specified.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate to define path and project_guid semantics. The description's 'one backend file' gives only vague context; there is no explanation of what the path really is, how it relates to the project GUID, or what valid inputs look like. This is a noticeable 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 clearly states a specific action — 'Read one backend file' — and emphasizes exact fidelity with 'exactly as saved.' The singular 'one backend file' distinguishes it from related tools like list_backend_files and write_backend_file. This gives an agent an unambiguous understanding of what the tool does.

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

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

The description implies usage when the exact contents of a backend file are needed and adds a cost-related trait (does not spend quota). However, it does not explicitly state when to prefer this tool over alternatives like read_page or write_backend_file, nor gives a when-not-to-use condition. The usage guidance is present by inference but not prescribed.

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 present, the description carries the behavioral disclosure burden. It makes clear that the logs contain recent output and errors, that 500s surface as tracebacks, and that the operation is free. It does not mention authentication, how far back 'recent' goes, or behavior when logs are unavailable.

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

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

The description is compact and front-loaded: a short statement of what it returns, followed by clear priority guidance and a concise 'Free' note. Every sentence earns its place and there is no redundant 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, the description covers purpose, when to use it, and basic behavioral expectations. The main missing piece is parameter-level explanation, especially lines, which prevents it from being fully complete.

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

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

Schema description coverage is 0%, so the description needed to explain project_guid and lines. 'Project's backend' weakly implies project_guid, but lines is left entirely to the schema's bare type/default with no explanation that it controls the number of log entries returned.

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

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

The description states a specific action and resource: reading recent output and errors from the project's backend. It also gives a concrete example of what the tool exposes ('a 500 ... has a traceback here'), which clearly identifies it as the backend log reader among the 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 gives explicit guidance: read this first whenever the app misbehaves, and do not ask the user to describe the error instead. It does not explicitly distinguish when to use this tool versus siblings like read_backend_file or query_database, so it stops short of full alternative-based 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 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 provided, the description fully discloses behavioral traits. It states this is a READ operation ('searching never reserves, registers, or charges anything'), explains the response markers (exact_domain, exact_check_unavailable, no marker), describes the output format and sorting, warns about pricing traps, and instructs how to handle sandbox results. It even specifies when not to take actions like calling the purchase link.

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 highly structured and each sentence serves a purpose. It front-loads the core purpose and usage, then details markers, return format, warnings, and stopping behavior. Although somewhat lengthy, the density of actionable information justifies its size. Minor redundancy could be trimmed, but overall it remains well-organized and readable.

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 tool is complex, and the description covers all aspects: input usage, behavior, output markers, sorting, pricing traps, sandbox caveats, and when to stop. It even provides guidance on related tools and next steps. The output schema exists, but the description adds crucial context about markers and sorting that the schema likely doesn't convey, making the description complete for an agent to use correctly.

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

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

Schema coverage is 0% since the description does not directly describe the 'query' parameter. However, the description compensates extensively: it explains exactly what to put in the query (keyword, single full domain, even inside a phrase), how the tool interprets it, and the consequences of multiple domains. This is far more than the bare schema provides, guiding the agent on both valid inputs and expected interpretations.

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

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

The description states a specific verb+resource: 'Search real-time domain availability and prices (via Name.com).' It clearly distinguishes from sibling check_domain by explaining the difference: search_domains handles keyword suggestions or one domain for an exact check, while check_domain is used for per-domain checks. The purpose is unambiguous and correctly differentiates from related 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 provides explicit when-to-use guidance: pass a keyword for suggestions, or include one full domain for an exact check. It also gives when-not-to-use instructions: if the user asks about specific domains, use check_domain per domain. Additionally, it explicitly instructs NOT to call get_domain_purchase_link in the same turn and explains why, setting clear boundaries for the agent's 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 behavioral burden and exceeds it. It discloses reversibility ('NOTHING IS DELETED'), immediate impact on visitors, custom-domain versus free-subdomain behavior, address preservation, and idempotency when calling twice on an unpublished project.

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 every sentence earns its place: main action first, then usage guidance, then behavioral effects, then idempotency and the delete_project distinction. The use of bullet points and bolded terms makes the structure easy to scan.

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

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

Given a single parameter, no annotations, and an output schema that covers return shape, the description is complete enough for an agent to invoke the tool correctly. It covers prerequisites, side effects, reversibility, domain handling, idempotency, and the critical distinction from delete_project.

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 never explicitly explains that project_guid identifies the project whose website should be unpublished. However, the single parameter is strongly self-documenting and the description repeatedly references 'project,' so an agent can infer the mapping without real ambiguity.

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

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

The description opens with a specific verb and resource: 'Take a published website OFFLINE' and explicitly identifies itself as 'the undo of publish_website.' This clearly differentiates it from siblings such as publish_website and delete_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 explicitly states when to use the tool ('user wants their site taken down, made private again, or wants to free a domain'), asks for confirmation when ambiguous, and names alternatives: 'publish_website puts the site back' and 'delete_project instead — these are different actions and must not be confused.'

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 fully discloses behavior: how identity is resolved (business_guid claim first, email otherwise via identity_resolve), the guest-trial flag and associated fields, and the specific error case with the exact 401 code and required action. This goes well beyond a basic tool description and covers edge cases.

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 multi-paragraph but every sentence carries necessary information: the core purpose, resolution mechanism, guest-trial instructions, and error handling. It is front-loaded with the primary purpose and then provides detailed behavioral rules. While it is longer than average, the complexity of the guest-trial logic justifies the length. It could be slightly tighter, but it is not verbose.

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?

Even though an output schema exists, the description already explains the return fields (email, business_guid, plan, is_guest) and adds valuable context about guest trial and error handling. It covers all necessary scenarios an agent would need to handle when invoking this tool, including when to surface claim_url and how to react to the specific 401 error. Nothing essential 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 zero parameters and the schema is empty, so there is nothing to add. The baseline for 0 parameters is 4. The description focuses on output and behavior rather than inputs, which is appropriate here.

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

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

Clearly states the tool returns the caller's account with specific fields (email, business_guid, plan, guest status). The verb 'Return' and the resource are explicit, and it distinguishes itself from all sibling tools that deal with site/domain operations. The mention of 'Phase 0 end-to-end gate' adds context.

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

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

The description gives clear context about when the tool is used (as an identity gate) and what to do with the results (e.g., guest trial handling). It doesn't explicitly name alternatives, but there are no obvious sibling tools for identity resolution, so it's clear enough. The guest-trial instructions effectively say when to give claim_url vs not, which is a form of usage 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?

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.

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

Since no annotations are provided, the description correctly carries the burden of explaining the mutation and its consequences. It discloses that saving restarts the backend, that app.py must define a Flask `app`, that no internet/database credentials exist, and that state_path is the private writable path. Only minor behavioral details like failure handling are omitted, which is acceptable at this level.

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?

Every sentence is load-bearing: purpose, filename/extension constraints, required app structure, available imports, runtime limitations, and restart behavior. The content is front-loaded and contains no filler or repetitive 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?

For a backend-writing tool, the description gives the critical context needed to write compatible code: the Flask app requirement, imports, data source, writable state path, lack of internet, and restart side effect. An output schema exists, so return-value details are not required. Minor gaps remain around failure/error semantics and exactly how project_guid maps to a project, but overall the description is strong.

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 for the most important parameters. It clarifies path rules and allowed extensions, defines what app.py content must include, and provides the runtime API that helps an agent construct correct content. project_guid is only implied via 'project's backend', but all three parameters are self-descriptive enough in 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 opening sentence 'Create or replace one file in the project's backend' states a clear verb, resource, and scope. The constraints 'Flat names only, ending .py/.html/.css/.js/.json/.txt' further distinguish this from asset/site-wide operations and from sibling tools like write_asset or create_backend.

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

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

The description clearly implies it is the tool for editing a single backend file, and it gives strong context about what the backend environment allows. However, it never explicitly contrasts it with sibling tools such as write_asset, read_backend_file, or delete_backend, so the decision boundary between alternatives is left largely implicit.

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