SORNKan Worldsite

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

With no annotations present, the description carries the full burden of behavioral disclosure, and it does so well. It reveals payment consequences, failure states, retry policies, the need for a wallet or the alternative payment_url path, and even the exact live URL format. No annotation contradiction exists.

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 information-dense: almost every clause carries operational value. It is not structured or bulleted, and the opening 'Go live. $1 USDC first 30 days' is more sales-y than descriptive, but the overall density is high and the key "counter-intuitive" details are embedded in plain language. It earns a 4, not a 5, because a strongly structured description would front-load a purpose statement and then list preconditions, params, error handling, and exceptions clearly.

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

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

There is no output schema and no annotations, so the description must; it covers prerequisites (preview_status), payment behavior, retry flows, the slug to live URL mapping, and the no-wallet path. It stops short of stating what the claim call returns on success and does not mention the email parameter. Given the complexity and the number of caveats, the coverage is very good but not complete.

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

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

The schema has 0% description coverage, so the description must compensate. It explains uploadId thoroughly by requiring the UUID from inspect, warns against using previewUrl, and clarifies what to pass if only the preview URL is available. It also explains slug semantics via the live URL format, though the email parameter is never mentioned.

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 makes the goal clear through the imperative 'Go live' and the surrounding payment/retry workflow — this is the tool that claims a preview and turns it into a live site. It does not open with an explicit 'Claims an uploaded site' statement, and it relies on context rather than distinguishing itself from all siblings, but it is far from vague or tautological.

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, actionable usage rules: call preview_status first, do not pay if claimable is false, ask for the slug before paying, retry this tool after PRICE_COMPUTE_FAILED, and do not retry payment after a settlement failure. It clearly states when to proceed and when to avoid using 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 empty annotations, the description carries the full burden of behavioral disclosure. It discloses the one-time fee, the 402 payment fallback path, the requirement that the lease be live, and the proxy behavior for Cloudflare hostnames. It doesn't fully describe success-response semantics or reversibility, but it goes well beyond a minimal description.

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 dense but every sentence contributes critical info: DNS mechanics, billing model, Cloudflare edge case, and card/PromptPay fallback. Some phrasing feels slightly repetitive ('while lease is live' and 'Not a monthly fee' could be consolidated), but the overall structure is efficient enough.

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

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

The description covers prerequisites (lease live, existing hostname), the payment fallback with a 402 response, and the post-payment polling step ('poll preview_status/retry until live'). It doesn't return the details of a successful response, which is a modest gap given the absent output schema.

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

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

The input schema provides no description coverage for slug or hostname, so the description must compensate. 'hostname' is inferable from the prose, but 'slug' is never explained, its role in identifying the lease or wallet remains ambiguous ('same claiming wallet' helps only indirectly). This is a clear gap in per-parameter 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?

The description clearly states the tool's function: connecting an existing hostname via CNAME to sites.sornkan.com without registrar involvement. It also distinguishes this from recurring-fee tools by noting 'Not a monthly fee' and 'One-time $1 USDC', though it doesn't explicitly name competing siblings.

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

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

The description includes a conditional payment flow ('If you have no wallet, get payment_url from the 402 response') and practical guidance for Cloudflare-hosted CNAMEs ('keep the CNAME proxied'). It does not explicitly list alternative sibling tools to choose between, but the context is clear enough for when this tool is appropriate.

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 the flat fee, payment alternatives, the requirement to pass ownerWallet in wallet-less cases, and the polling of preview_status/retry. However, it doesn't specify what happens if unsafe files are found, leaving an outcome ambiguous.

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 dense but each sentence adds essential information: the core action, pricing, wallet scenarios, and non-extension of lease. It is front-loaded with the main purpose and remains readable despite its length.

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 4 parameters and no output schema, the description covers the payment flow, wallet condition, and polling process but omits parameter semantics for two fields and the error/response behavior (e.g., what an unsafe file triggers). This leaves gaps an agent must resolve.

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 explains ownerWallet thoroughly ('the address that claimed this slug') and implies uploadId as the zip, but leaves slug and tokens undefined, forcing an agent to guess their roles (e.g., whether tokens affect pricing).

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 'Check the zip for unsafe files, then redeploy the live Worker,' naming the resource (live Worker) and the process (redeploy). It distinguishes itself from siblings like renew ('Does not extend lease days') and publish_website, making its 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?

Provides clear contextual guidance: payment requirements, wallet-less flow, and explicit exclusion that it does not extend lease days. Although it doesn't name alternative tools like renew, the 'does not extend lease' note implicitly directs to that sibling when lease extension is needed.

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 fully discloses the deployment side effect, quota consumption (first 3/day free, then $0.10), payment options (x402 USDC or payment_url), and the fact that a successful claim resets the quota. This is transparent about costs, side effects, and state changes.

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

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

The description is long and dense, covering purpose, quota, payment options, alternatives, and follow-up steps. While every sentence carries useful information, it is not concise—a single-parameter tool could have been described more compactly. The structure is logical but feels 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?

For a complex tool with quota, payment, and multiple siblings, the description is thoroughly complete. It covers prerequisites (uploadId from an upload), when to use it, side effects (deployment, quota), cost details, and even the next steps (ask for slug, then claim). Nothing critical appears 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 schema has 0% description coverage, so the description must compensate. It implies that uploadId comes from a prior upload (references upload_url and claimable) and explains the usage flow. However, it never explicitly defines uploadId as 'the identifier returned by upload_url', leaving a slight inference gap. Still, it adds meaningful context beyond a bare string type.

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

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

The description states a specific verb ('deploys') and a specific resource (a throwaway preview Worker at preview-*.worldsite.workers.dev). It clearly differentiates itself from siblings like scan (free, nothing deployed) and preview_status (just reads remaining time), so an agent can tell them apart without opening schemas.

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 instructs when to use this tool ('call inspect only when the human wants to see a preview'), when not to ('Do NOT inspect again just to read remaining time — use preview_status'), and names alternatives (scan for iterating, upload_url again if claimable is false). This leaves no ambiguity about tool selection.

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 of behavioral disclosure. It clearly discloses the no-scan behavior, that the clock is not reset, that it never returns 402, and that claimable: false means the preview was deleted. This gives an agent an accurate model of side effects and failure modes.

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

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

The core purpose is front-loaded in the first sentence, and every following sentence adds decision-relevant guidance. The workflow and caution about the old id are dense but not bloated.

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, no-output-schema tool, this description is complete. It explains the single input, the core result, the deletion case, and the correct fallback path. An agent can select and invoke this tool correctly without needing additional context.

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

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

The schema only gives uploadId as a string, and schema description coverage is 0%. The description compensates by explaining that uploadId is the UUID and that a preview URL is also acceptable, which is essential for calling the tool correctly.

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

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

The description opens with a concrete action and resource: 'Read remaining preview time.' It further distinguishes itself by naming inspect and the condition to prefer this tool, so an agent can tell it apart from siblings without needing to open the schemas.

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 this tool instead of inspect: when you only need the clock. It also describes the exact recovery workflow when claimable is false, and tells the agent what not to do (do not inspect or claim the old id, do not pay).

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 full responsibility for behavioral disclosure, and it delivers. It reveals side effects: publish includes a $1 USDC charge, takes an action that makes content live, and can perform a CNAME binding. It explains error-prone behaviors: retry claim on PRICE_COMPUTE_FAILED without fear of double charge, but do not retry payment if settlement failed, and use the slug worldsite.workers.dev format.

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

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

Every sentence carries meaningful instruction or a constraint, so the text is not padded. However, it is a long run-on procedure in a single block rather than a crisp structured format; adding slight sectioning could help an agent parse the sequence faster. It is front-loaded with the most critical safety instruction, which earns partial credit for 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?

Given the high complexity of this workflow, zero annotations, and no output schema, the description is remarkably complete. It covers preconditions, step sequence, required user interactions, error cases, retry behavior, URL formatting, optional host labels, the denial cases. An agent could plausibly execute the publish flow and know how to handle the major failure modes without asking for more documentation.

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 zero parameters, so the baseline is 4: no parameter documentation is needed. The description does not incorrectly introduce parameters; it refers to upstream values like putUrl, dropUrl, UUID, slug, and previewUrl in the context of the workflow, which is appropriate for a tool that orchestrates other processes.

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

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

The description explicitly states the tool's purpose as 'Publish a website' and then immediately enumerates the exact multi-step workflow (upload, inspect, preview, claim, hostname). This clearly distinguishes publish_website as the orchestrating action from sibling tools like claim, inspect, preview_status, and upload_url, which are individual steps in the flow.

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 concrete, imperative guidance for when and how to act: always ask the human about cost and legal issues first, put content via upload_url and PUT putUrl, use inspect to get the UUID, use preview_status solely to read remaining time, and ask which slug before claiming. It also gives explicit do-nots, such as never inspecting just for the clock, never retrying after settlement failure, and never putting the zip in chat.

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 empty annotations, the description carries the full behavioral burden. It discloses the headless Chromium execution, the returned artifacts (markdown, screenshot URL, evidence page URL), pricing, authentication model, and fullPage pricing behavior. It does not cover failure modes or rate limits, but for a straightforward render operation it is appropriately transparent.

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

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

Three tight sentences front-load the action, then specify outputs, then cover cost/auth and the optional fullPage behavior. There is 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 two-parameter tool with no output schema, the description adequately explains call outcomes and requirements: what is rendered, what is returned, what it costs, and what auth is needed. Minor gaps like timeout or failure behavior do not 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?

Schema description coverage is 100%, so the schema already documents both parameters. The description's fullPage guidance and 'any public URL' phrasing mostly restate what the schema already says, adding little distinct semantic value.

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: 'Render any public URL in a real browser (Chromium)', and enumerates concrete outputs. It does not explicitly distinguish itself from sibling tools like inspect or scan, so it misses full sibling differentiation.

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

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

It provides clear operational prerequisites (public URL, x402 wallet, no signup) and parameter guidance for fullPage. However, it does not state when to choose this tool over alternatives or mention any exclusion conditions, leaving usage routing mostly implied.

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

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

Since the annotations are empty, the description carries the full behavioral disclosure. It reveals stacked cap of 90, that last day without renew deletes the site and frees the slug, that only the same claiming wallet is eligible, and explains the alternate card/PromptPay payment path. These are significant, non-obvious behaviors that an agent must know before calling the 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 purpose and constraint, then continues with nuanced operational rules. Some sentences are dense and combine multiple ideas into a single flowing sentence, but every clause contributes meaningful operational detail. No wń garbage, method but structure could be improved by splitting.

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

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

With no output schema, the description covers everything needed for an agent: when to renew, when not, expiration consequences, payment alternatives for the wallet, support contact, and polling steps after payment. It also covers the 'th likable' slug-free-to-use. The cardinal detail of last-day deletion is explicitly given, avoiding a dangerous edge case.

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 only parameter is 'slug', yet the description never mentions it or explains how to obtain the matching slug. The input schema gives only the type, not the meaning; with schema description coverage at 0%, the description was expected to compensate but does not. The user can infer 'slug' identifies the site to renew, but it is not explicit.

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

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

The first sentence specifies the exact action ('Renew hosting'), resource ('hosting'), duration ('+30 days'), and cost ('$1 USDC'), so the agent immediately knows what this tool does. It also distinguishes itself from 'claim' by stating that after expiry you must claim again as a 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 explicit conditions for using the tool: it is allowed only while the site is live, with remaining < 90 days and a 90-day stacked cap. It explicitly says after expiry renew is unavailable and points to 'claim again' as the alternative. It also describes the no-wallet payment flow through a 402 response and polling, leaving no ambiguity about when to use this 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?

There are no annotations, so the description carries full transparency responsibility. It explicitly discloses side-effect behavior (no deployment), cost behavior (free, never 402, burns no preview quota), and reliability semantics (verdict advisory; inspect re-checks before deploying). This is highly transparent for a tool with no annotations.

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

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

The description is information-dense and every sentence contributes: it states the safety behavior, cost/quota guarantees, iterative usage workflow, sibling alternative, and advisory nature of the result. It is front-loaded and stays focused.

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 scan tool, the description covers when, why, how, and what not to expect, and it even routes to inspect when appropriate. The only gap is that the return value is only called 'verdict' without describing the concrete output shape, which matters more because no output schema is provided. Still, the description is close to 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?

There is only one parameter, uploadId, and the schema provides no description. The tool description indirectly clarifies the parameter by talking about an uploaded zip and the upload_url workflow, but it never explicitly states that uploadId comes from upload_url or what format/scope the value has. It adds some semantic context but does not fully compensate for the 0% schema coverage.

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

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

The description names a concrete action and resource: 'Check an uploaded zip for unsafe files' while explicitly saying that nothing is deployed. It also distinguishes the tool from its sibling 'inspect' by contrasting no-deploy scan vs deploy-as-throwaway-preview, so an agent can tell them apart.

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

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

It gives an explicit workflow 'scan → fix → upload_url again → scan' and tells when to switch to inspect: when the content is clean and the human wants to SEE it. It also warns the verdict is advisory, so the agent knows not to rely on it as final.

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 transparency burden. It does disclose the 3MB limit and some chat-behavior rules, but it does not explain side effects, failure modes, permissions, or what the agent should observe after uploading. It also relies on unexplained putUrl/dropUrl terms.

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 two sentences and contains no filler; each instruction is directly operational. However, the brevity contributes to ambiguity because key concepts like putUrl and dropUrl are never defined.

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 structurally poor and lacks output schema or annotations. It does not explain what the tool returns, how dropUrl and putUrl relate, or what the human is expected to do with them. For a zero-schema tool with no annotation support, the description 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?

The schema has zero parameters and 100% coverage, so semantic parameter depth is trivially satisfied. The description mentions putUrl and dropUrl, but they are not actual schema parameters, so there is no additional parameter meaning needed.

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

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

The description never clearly states what the upload_url tool actually does. It instructs the agent to "PUT putUrl yourself" and mentions dropping the URL, but it does not define whether the tool creates a URL, uploads a file, or performs an HTTP request. The purpose is implied rather than explicitly explained.

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

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

It gives concrete conditional instructions: if the agent has the zip, it should PUT to putUrl, must not put the zip in chat, and should only send dropUrl to the human if no file is available. This is explicit usage guidance, though it does not compare against sibling tools.

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