Clean Notes

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

Annotations already declare destructive=true, idempotent=true, readOnly=false, so the safety profile is covered. The description adds genuinely new behavior: the server-time stamp and the MCP_CONFLICT failure mode when the task changed after expectedUpdatedAt — an optimistic-concurrency contract not visible in structured fields.

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

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

Three short sentences, each earning its place: what it does, when to call it, and the failure mode. The core action is front-loaded 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?

An output schema exists so return values needn't be described, and the conflict/error path is disclosed. The only gap is the idempotencyKey contract, which matters for retry behavior on a non-readOnly tool, though idempotentHint=true partially covers 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 effectively explains expectedUpdatedAt via the conflict rule, and projectId/taskId are self-evident, but idempotencyKey is never mentioned (only indirectly covered by idempotentHint). Partial compensation warrants the baseline 3.

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: 'Move one task to the project's completed status, stamped with server time.' The scope (one task, project-level completion, server-timestamped) clearly separates it from the generic siblings clean_notes_update_task and clean_notes_create_task.

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?

'Use when the user says a task is done' gives a concrete trigger condition, which is more than most siblings offer. It does not state when NOT to use it (e.g. for partial edits use update_task), so it stops short of the full routing guidance a 5 requires.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, but the description adds the concrete semantics of that idempotency: replaying a key returns the original note rather than duplicating. It also implies a permission prerequisite via 'granted project', though it doesn't spell out 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?

Three short sentences, front-loaded with the action and scope, followed by the usage trigger and the idempotency caveat. No filler or restatement of the title.

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

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

An output schema exists, so return values need not be explained, and the mutation/idempotency profile is covered. The gap is the two identifier parameters and any error or permission-failure conditions, which are left implicit.

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 carries the burden. It names title, body, and pin, covering three of five parameters, but says nothing about the roles of projectId or idempotencyKey beyond the behavioral note about key replay. 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?

States a specific verb and resource ('Create one note') plus scope ('in a granted project'), and names the creatable fields. An agent can distinguish this from clean_notes_create_task or clean_notes_update_note without opening any 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?

Gives an explicit trigger: 'Use when the user asks to record something as a project note.' It does not name alternatives (e.g., use update_note to modify an existing note) or state exclusions, so it stops short of a full routing rule.

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

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

Annotations already declare destructiveHint=false, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered; the description goes further by spelling out the idempotency semantics ('repeating an idempotency key returns the original task instead of a duplicate') and the permission prerequisite ('granted project'). It does not describe failure/auth-error behavior, but the added context is real value beyond the booleans.

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, all earning their place: purpose and fields first, trigger second, non-obvious idempotency behavior last. No repetition of the title or wasted preamble.

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 9-parameter mutation tool, the description covers what is created, the fields, the trigger, and the idempotent-return behavior, and an output schema exists so return shape need not be explained. It leaves the permission model ('granted project') and error cases at a hint level rather than explaining them.

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 carries the burden and largely meets it: title, details, status, priority, dates, and assignee are all named, projectId is implied by 'granted project', and idempotencyKey is discussed behaviorally. It does not convey formats or constraints (240-char title, date format, uuid ids) that an agent must infer from 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?

It names a specific verb and resource ('Create one task') plus the scope ('in a granted project') and enumerates the creatable fields. That clearly separates it from clean_notes_create_note and the update/get siblings by resource, but it never explicitly names or routes against an alternative, so it stops short of 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?

'Use when the user asks to add a task' gives a concrete trigger condition for invocation. There are no exclusions or alternatives offered (e.g., when to prefer clean_notes_update_task for an existing task), which is the only gap.

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

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

Annotations already declare readOnlyHint=true (safe read) and idempotentHint=true. The description adds that the note's full body is returned, which is useful return context. However, it doesn't disclose error behavior for missing notes or UUID format expectations. With annotations covering the safety profile, this is acceptable.

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

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

Two short sentences, front-loaded with the core action and scope, then usage context. Zero waste.

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

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

Has an output schema, so return value details aren't needed in the description. Annotations cover safety traits. The main gap is parameter semantics with 0% schema coverage, leaving an agent without UUID format guidance.

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 not explain that noteId must be a UUID, that projectId scopes the note, or any parameter relationships. The description adds no meaning beyond what the 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?

States a specific verb (Get) and resource (one note with its full body). The sibling tool list_notes indicates a distinction between retrieving a single note and listing notes, though the description does not explicitly name the alternative.

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

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

Explicitly states when to use: 'when the user asks to read a specific note.' This distinguishes it from the list_notes sibling, though it doesn't name the alternative explicitly or mention 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful context beyond the annotations by noting that the project is 'granted' and that the response includes ordered statuses and assignable members.

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, front-loaded with the core purpose and immediately followed by the use case. Every sentence earns its place 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?

For a simple single-resource getter with an output schema and rich annotations, the description is largely complete. It covers purpose, usage, and response content, though it omits where the projectId should come from.

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 explains the required projectId parameter or how to obtain it. The schema provides only type and uuid format, so the description does not compensate for the missing semantic guidance.

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 ('Get one granted project') and adds the response composition ('ordered task statuses and the members tasks can be assigned to'). It clearly distinguishes itself from list_projects by specifying a single granted 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?

Explicitly says to use it 'for a project overview or to find status and assignee IDs,' which gives clear usage contexts. It does not, however, state when not to use it or name an alternative sibling for broader project listing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful detail that all fields and dates are returned, but nothing about pagination, missing-task behavior, or errors, which a lookup tool could reasonably mention.

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, front-loaded sentences with no filler — purpose first, usage second. Efficient, though the second sentence is boilerplate that could carry slightly more routing value.

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 no elaboration, and the annotations cover the safety semantics. The only real gap is that the two required identifiers are never explained in prose, which is a minor omission for a straightforward lookup.

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 mentions no parameter at all; the two required UUIDs (projectId, taskId) are documented only by their type/format in the schema. With low coverage the description is expected to compensate by clarifying the project/task scoping relationship, and it does not.

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 ('Get one task') and describes the scope of the return ('all of its fields, including full details and dates'). It is clearly a single-item fetch, distinguishable from clean_notes_list_tasks, though it never names the sibling explicitly.

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

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

'Use when the user asks about a specific task' gives implied usage context, which is better than nothing. However, it does not state when-not to use it or name the obvious alternative (clean_notes_list_tasks) for multi-task queries, leaving routing to inference.

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

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

Annotations already cover readOnly, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description still adds two useful traits not in the annotations: results are truncated previews, and the project must be 'granted' (an authorization precondition). It omits pagination behavior despite the cursor parameter.

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

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

Two short sentences, no filler, and the core purpose is front-loaded before the filter and usage notes. Every clause adds information an agent cannot get from the structured fields alone.

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

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

An output schema exists, so return-value detail is unnecessary, and the read-only safety profile is fully covered by annotations. The description is nearly complete for a filtered list tool, with pagination via limit/cursor as the one meaningful omission.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, but it only loosely covers two of four: project scoping ('in a granted project') and the update filter ('filtered by last update'). The limit and cursor parameters, and the existence of pagination, are never explained anywhere.

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 and resource ('List note previews in a granted project') and adds scope plus an optional filter. It differentiates itself from clean_notes_get_note by signaling that results are shortened previews rather than full note bodies, so an agent can choose correctly without opening either 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?

'Use to find a note or see what changed recently' gives clear when-to-use context for two concrete scenarios. It does not name an explicit alternative (e.g. get_note for full content) or state exclusions, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds useful scope context ("granted to this connection") but says nothing about pagination behavior or result ordering beyond what annotations 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?

Two tight sentences with zero filler, and the core purpose is front-loaded before the usage cue. Slightly more value could be packed into the same space, but nothing is wasted.

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

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

An output schema exists, so return values need not be explained, and the annotations cover the safety profile. However, the two undocumented pagination parameters leave an agent without guidance on how to page through a project list, which is a real gap for a listing 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?

Schema description coverage is 0% for two parameters (limit, cursor), and the description never mentions paging, default page size, or how to continue a result set. With no schema text to lean on, the description should have compensated and does not.

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 ("List the projects granted to this connection") and notes that IDs are returned, which is more precise than the title alone. It does not explicitly contrast with the sibling clean_notes_get_project, so an agent must infer that this is the bulk-listing counterpart.

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

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

Gives a concrete trigger: "Use when the user refers to a project or asks which projects are available." It stops short of naming an exclusion or pointing to clean_notes_get_project for a single known project, so the alternative-selection rule is left implicit.

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

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

Annotations already establish read-only, idempotent, closed-world, non-destructive behavior, so the bar is low — yet the description adds a genuinely useful trait: results are shortened previews, not full records. "In a granted project" also implies a permissions precondition. It does not cover pagination behavior, so not a 5.

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

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

Three short sentences, front-loaded with the core action, then the preview caveat, then usage intent. Every clause earns its place 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?

An output schema exists, so return-value shapes need no explanation, and annotations fully cover the safety profile. The disclosed preview truncation is the key behavioral fact an agent needs. The missing piece is pagination semantics for limit/cursor, which matters for a list 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?

Schema description coverage is 0% across 6 parameters. The description compensates for three of them (status, assignee, last update) mapping to statusId, assigneeId and updatedAfter, and "granted project" hints at projectId. However, limit and cursor pagination parameters are documented nowhere, leaving a real 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?

States a specific verb and resource with scope ("List task previews in a granted project") and names the filterable dimensions, making it clearly distinct from single-item siblings like clean_notes_get_task. It does not explicitly contrast itself with clean_notes_list_notes or clean_notes_list_projects, so it falls short of 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?

"Use to answer what is open, overdue, or assigned to someone" gives concrete intent that maps to real user questions and selects this tool over get_task. There is no explicit when-not clause or named alternative, so it stops short of a 5.

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

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

Annotations already declare the tool is a mutation (readOnlyHint=false, destructiveHint=true, idempotentHint=true), so the safety profile is covered. The description adds genuine value beyond them: an explicit optimistic-concurrency contract (MCP_CONFLICT, no partial write when the note changed after expectedUpdatedAt). It omits permission/auth requirements and what the success response contains.

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

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

Three short sentences, zero filler, and the essential purpose plus the failure semantics are front-loaded. Every sentence carries distinct information (what changes, when to use, how it fails).

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

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

An output schema exists, so return-value explanation is not required, and annotations carry the mutation/idempotency profile. The concurrency preconditions are well covered, but the description leaves the semantics and provenance of idempotencyKey and expectedUpdatedAt unexplained for a 5-parameter, fully-required 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?

Schema description coverage is 0% across 5 required parameters, including a nested patch object, so the description must compensate. It does explain that patch targets title/body/pin and gestures at expectedUpdatedAt via the conflict rule, but says nothing about projectId scoping or what idempotencyKey is for. 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?

States a specific verb (change/update) applied to a specific resource (one note) and enumerates the mutatable fields (title, body, pin). The resource noun cleanly separates it from the sibling clean_notes_update_task without needing to open either 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?

"Use when the user asks to edit a note" gives a clear trigger condition, and the conflict rule implicitly tells the agent when this call will fail. It stops short of naming alternatives (e.g., create_note for new notes, get_note to fetch the current expectedUpdatedAt) or stating prerequisites, so no exclusions are 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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true), so the bar is lower. The description earns credit by disclosing the optimistic-concurrency contract: an MCP_CONFLICT failure that changes nothing when the task changed after expectedUpdatedAt. It does not clarify what 'destructive' means for a partial patch (whether unspecified fields are preserved).

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

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

Three short sentences, front-loaded with the action and field list, with no filler. The middle 'use when' sentence is the weakest, being largely redundant with the opening clause.

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?

Output schema exists, so return values need not be described, and the concurrency/conflict behavior is covered. Remaining gap is the idempotencyKey contract for a retryable mutation, which is not addressed anywhere in the description.

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

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

Schema description coverage is 0% across 5 parameters including a nested patch object, so the description must carry the burden. It does map the patch field names, which helps, but leaves idempotencyKey, projectId, and taskId semantics unexplained (expectedUpdatedAt is at least covered under behavior).

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?

Specifies a concrete verb and resource and enumerates the mutable fields ('Change the title, details, status, priority, dates, or assignee of one task'), so it is clearly distinguishable from clean_notes_update_note by resource. It stops short of explicitly naming the sibling alternative, so a 4 rather than a 5.

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?

'Use when the user asks to edit a task' states a trigger context, but it essentially restates the tool's own purpose and offers no exclusions or comparison against the other update/create tools in the sibling set. Implied usage only.

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