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

With no annotations, the description carries full burden and exceeds expectations. It explicitly states 'Read-only, deterministic. No network calls, no secrets exposed' and clarifies that credentials are server-side. This discloses safety and side-effect behavior thoroughly.

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 well-structured with a lead definition, a 'When to use' section, and a 'Returns' section. It is front-loaded with the primary function, and every sentence adds value without unnecessary padding.

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 tool with no output schema and no annotations, the description covers purpose, usage triggers, return format (plain text with three sections), and behavioral traits (read-only, deterministic, no network). This is fully sufficient for an agent to select 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?

The input schema already provides 100% coverage with rich descriptions for each enum value (including recommendations like 'r2' = Cloudflare R2, zero egress fees). The description adds no additional parameter semantics beyond referencing 'a specific storage provider', so the baseline 3 applies.

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

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

The description states a specific verb ('Generate') and resource ('Bring-Your-Own-Storage (BYOS) configuration for an UploadKit Next.js handler'), and enumerates the output types (env vars, handler code, setup notes). This clearly distinguishes it from sibling tools like get_doc or list_components.

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?

A dedicated 'When to use' section explicitly explains the intended scenario (user wants own bucket instead of managed R2) and lists typical triggers (compliance, existing infra, vendor lock-in). It implies when not to use (managed storage) but does not name alternative tools, so it falls short of a full 5.

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

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

With no annotations provided, the description carries the full burden. It discloses read-only, idempotent behavior, the exact JSON return shape, and the fallback suggestion message for unmatched names. This goes beyond minimal expectations, though it could mention explicit side-effect absence.

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

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

The description is tightly written with a logical flow: purpose, when-to-use, return format, and error behavior. Every sentence earns its place with no 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 is a simple single-parameter read-only tool with no output schema, and the description covers all necessary context: what it returns, how to use it, error handling, and safety. No significant information gaps remain.

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 already provides thorough parameter details (case-sensitive, PascalCase, examples), and the description adds contextual guidance on sourcing the name from list_components or search_components. This enhances the parameter's meaning beyond the schema alone.

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 fetches full metadata and a copy-pasteable React usage example for one specific UploadKit component. It distinguishes from sibling listing/searching tools by specifying 'one specific' and referencing how to obtain the exact 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 includes an explicit 'When to use' section: once the exact component name is known from list_components or search_components and a ready-to-paste example is needed. This clearly differentiates when to use this tool over alternatives.

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

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

With no annotations, the description carries the full burden. It explicitly discloses read-only and idempotent behavior, the exact return format, and the not-found message. It doesn't cover potential errors or network behaviors, but provides strong transparency for the expected use case.

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 well-structured with clear sections: what it does, when to use, and what it returns. It is concise, front-loaded, and contains 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?

Despite having no output schema, the description fully explains the return format and the not-found behavior. It also covers usage context and alternatives, making it complete for a simple docs-fetching tool.

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 description for 'path' is already very detailed (100% coverage) with examples and formatting rules. The tool description itself does not add new parameter semantics beyond restating 'by its path' and the context in which to obtain the path, so the baseline of 3 applies.

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

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

The description clearly states it fetches the full markdown content of a single UploadKit docs page by path, including formatting details. This distinguishes it from sibling tools like search_docs and list_docs, 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?

The description explicitly says to use it after search_docs identifies a relevant page, and advises preferring search_docs first. It also mentions the not-found fallback to list_docs, providing clear when-to-use 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 fully discloses the tool's safety profile: 'Read-only, idempotent, never modifies anything.' It also specifies the return format (a plain-text shell command as a single string), which is essential behavioral context 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 concise and well-structured: each paragraph serves a distinct purpose (what it does, when to use, what it returns). It is front-loaded with the main verb and resource, and every sentence adds value 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?

The tool is simple (2 optional params, no output schema), and the description covers both the return value and the operational context. It explains when and how to use the parameters (e.g., detecting package manager from lockfile) and explicitly states the read-only behavior, making it complete for an agent to invoke 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% for both parameters, with detailed explanations, examples, and enums. The description itself adds little beyond the schema, only repeating the package manager concept and providing an example command. Baseline 3 is appropriate when the schema carries the 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 states a specific verb ('Return') and resource ('exact shell command to install UploadKit packages'), clearly distinguishing it from siblings that fetch components or docs. It also includes a concrete example command, leaving no ambiguity about the tool's function.

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

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

The description explicitly says when to use the tool ('before asking the user to add dependencies') and even provides detection guidance for package managers. It does not explicitly mention when-not-to-use or alternatives, but given that sibling tools are unrelated, the context is clear enough.

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 explicitly states 'Read-only, static content, idempotent' and specifies the return type ('plain-text markdown document'), which covers the key behavioral aspects. However, it doesn't mention any authentication/network requirements, though for static content retrieval this may not be critical.

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?

Each sentence earns its place: purpose in first sentence, usage guidance in second, return type and safety in third. The description is well-structured with 'When to use' and 'Returns' labels, making it easy to scan and parse.

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

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

For a simple static content tool with no parameters and no output schema, the description is fully complete. It covers what it does, when to use it, alternatives, return format, and behavioral traits. No gaps remain.

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 per the rubric. The description adds clear confirmation with 'Takes no parameters,' which is sufficient for parameter semantics since there is nothing to explain.

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 returns a complete UploadKit quickstart walkthrough for Next.js, specifying content components (install, API key env, route handler, provider, first component, optional BYOS). It also distinguishes itself from siblings by explicitly referencing alternative tools for more targeted use cases.

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 when-to-use cues: 'user is brand new to UploadKit and asks how do I get started?' and explicitly names alternative tools (scaffold_route_handler, scaffold_provider, get_install_command) for when a specific step is known. This is the gold standard for 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?

With no annotations provided, the description carries the full transparency burden. It explicitly states 'Read-only, no side effects, idempotent' and also describes the return JSON structure, covering behavior and impact thoroughly.

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: purpose, when-to-use, and return/behavior. It is front-loaded with the main action, every sentence has a distinct role, and there is 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?

Despite lacking an output schema, the description explicitly states the return format. For a simple one-parameter list operation, it covers purpose, use context, side-effect profile, and return structure—fully sufficient for an agent to select and invoke 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 100% coverage with a detailed enum description for the optional category parameter. The description adds little beyond the schema (only a passing example of 'dropzone' variants), so it neither enhances nor detracts from the schema-provided 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 opens with a specific verb and resource: 'List every React upload component shipped by @uploadkitdev/react with its name, category, one-line description, and design inspiration.' This clearly distinguishes it from siblings like get_component (single component) and search_components (search vs. full list).

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 an explicit 'When to use' clause: 'before recommending or scaffolding any UploadKit component, to confirm the exact name exists and to pick the right variant.' This provides clear usage context but does not explicitly name alternatives or exclusions (e.g., when to prefer search_components).

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 full transparency burden. It explicitly states the tool is read-only, static at bundle time, and idempotent. It also discloses the return format ('JSON { count, generatedAt, pages: [...] }') and sorting behavior ('sorted alphabetically by path').

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

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

The description is compact and well-organized with labeled sections ('When to use', 'Returns'). Every sentence adds value, and there is no redundant information. It is appropriately sized for the tool's simplicity.

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

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

For a no-parameter, read-only listing tool, the description is complete. It explains the return structure, sorting, and the tool's role in the broader docs workflow. No output schema exists, but the description compensates by detailing the JSON response. The sibling context shows it is one of several docs tools, and this description positions it appropriately.

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

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

The tool has zero parameters, so schema coverage is 100% and there is nothing to document. The baseline for 0 params is 4, and the description adds no parameter details because none exist. It still provides context about the output fields (title, description, URL, path) which ties to what the function returns.

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 enumerates all docs pages with specific fields (title, description, URL, path). It uses a precise verb 'enumerate' and resource, and explicitly differentiates from search_docs by stating when to prefer it.

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 this tool ('to discover what documentation exists before targeted searching, or to orient yourself around the shape of the docs site') and names an alternative ('Prefer search_docs when you already have a concrete question'). This is model 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 fully discloses behavior: read-only, deterministic, idempotent, and the exact return format (plain-text string with a fenced tsx code block). It also clarifies that no parameters are needed and the endpoint path is fixed, providing transparency about internal assumptions.

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 yet complete, structured into clear sections (purpose, when to use, return format). Every sentence adds useful information with no redundancy or filler.

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

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

For a tool with no parameters and no output schema, the description provides all necessary context: what it does, when to use it, what it returns, and its safety profile. It is fully self-contained and leaves no significant gaps.

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

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

The tool has zero parameters, so the baseline is 4, but the description adds meaningful context by explaining why no parameters are needed: 'the endpoint path is always /api/uploadkit since that is what scaffold_route_handler produces.' This goes beyond the empty 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 it returns a snippet wrapping the Next.js root layout with <UploadKitProvider> for React components to talk to the upload route handler. This is specific and distinguishes it from scaffold_route_handler, which generates the route handler itself.

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 says 'When to use: right after scaffold_route_handler' and explains the consequence of not using it ('UploadKit React components throw at runtime'). This gives clear context and implicitly excludes use before the route handler exists.

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 bears the burden of behavioral disclosure. It clearly states the tool is 'Read-only — generates text, never touches the filesystem itself', describes the return format (markdown string with code fence), and sets the expectation that the agent must write the file to disk. This is comprehensive transparency.

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: purpose in the first sentence, usage trigger in the second, return format and expected action in the third, and a clear read-only caveat in the fourth. Every sentence earns its place with no 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?

Despite the absence of an output schema and annotations, the description covers all necessary context: what the tool produces, how it should be used, what the agent must do with the result, and the tool's non-destructive nature. For a file-generation tool, this is 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 100%, so the baseline is 3. The tool description itself does not add parameter-specific meaning; the rich examples and defaults (e.g., routeName key, maxFileSize units) are already in the input schema. No additional value is contributed by the description beyond what the schema already 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 opens with a precise verb and resource: 'Generate the complete file content for a Next.js App Router upload route handler', and lists concrete features (typed file router, handler export, correct path comment). It clearly distinguishes from sibling tools like scaffold_provider by naming the exact target file and framework 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 an explicit 'When to use' clause: when setting up UploadKit server-side in a Next.js App Router project and needing the route.ts file. It also tells the agent the exact path to write to and clarifies that the tool itself is read-only, leaving the file creation to the agent.

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 takes on the responsibility. It discloses 'Read-only, idempotent, case-insensitive' and specifies the exact JSON return format, providing solid transparency. Minor omissions like pagination or result limits are acceptable for a search 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 moderately long but well-structured with clear sections (core function, when to use, return format). It front-loads the purpose and uses whitespace effectively. A few redundant phrases could be trimmed, but overall efficient.

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?

Considering the lack of annotations and output schema, the description provides comprehensive context: purpose, usage guidance, return structure, and safety profile. It fully equips an agent to decide when and how to invoke the tool, including distinguishing from siblings.

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 baseline is 3. The description adds value by introducing the fuzzy-search concept, the 'design inspiration' interpretation, and examples like 'apple' and 'vercel' that go beyond the schema examples. This elevates it above baseline.

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 'Fuzzy-search the UploadKit component catalog by any free-text keyword' and enumerates the fields searched (name, category, description, inspiration). It distinguishes from sibling list_components by explicitly positioning it as discovery-focused.

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?

Contains an explicit 'When to use' section with concrete example user queries and an explicit instruction to prefer this over list_components when the goal is discovery rather than enumeration. This directly addresses 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?

With no annotations provided, the description carries full burden and discloses key behaviors: 'Read-only. Bundled index (no network call) — results reflect docs at build time.' It also explains ranking logic ('Ranks matches by keyword frequency') and the return format with sorted order, going beyond a basic read/write hint.

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 organized into clear sections: scope, when to use, and return format. Every sentence adds value—no fluff. Despite moderate length, it remains focused and front-loaded with the core purpose, making it easy for an agent to quickly assess relevance.

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 output schema, the description thoroughly explains the return JSON structure with field names and sorting, plus metadata fields like query, count, and indexGeneratedAt. It covers use cases, behavior, limitations (build-time index), and parameter semantics, making it self-sufficient for an agent to invoke 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 100%, but the description adds valuable usage guidance: for limit it gives default, range, and context-specific advice ('Use smaller values (3-5) when you already have a narrow query; use larger values (15-20) for exploratory scans'); for query it explains ANDed multi-word behavior and per-field weighting with concrete examples. This significantly enriches schema definitions.

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 'Full-text search across every UploadKit docs page (88+ pages)' with a specific verb and resource, covering all docs. It distinguishes itself from siblings like search_components and get_doc by clearly scoping to docs pages and listing covered categories (getting-started, SDK reference, etc.).

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 provides a 'When to use' section: 'any question about UploadKit behaviour, configuration, or integration that the component tools do not answer — middleware, onUploadComplete callbacks, REST API endpoints...' This gives clear usage context and implies alternatives (component tools) without naming them directly, covering exclusions effectively.

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