Vigilia

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

Annotations already declare idempotentHint=true and destructiveHint=false, but the description elaborates usefully: re-adding an existing address returns that app instead of erroring, and it discloses a plan-based cap on watcheable apps. It omits auth/permission requirements, but adds real context beyond the structured hints.

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?

Four dense sentences, no filler, with purpose and the primary input front-loaded before the return value, idempotency behavior, and plan constraint. Slightly packed, but every sentence carries information an agent can act on.

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 correctly covers the return value (the app id) and the downstream flow. Plan limits are disclosed; only auth requirements and invalid-URL behavior are unaddressed, which are minor for a single-required-param 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 100%, so url, name, and builder are already fully documented in the schema, including the builder's effect on fix prompts. The description only restates 'give its address' and adds no format or interaction detail, so 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?

States a concrete verb and resource ('Start watching a live web app') plus the trigger ('give its address'), so the agent knows this registers a URL for uptime monitoring rather than reading anything. It also names the consumer of the returned id (get_install_instructions), which separates it from read-oriented siblings like list_apps and get_app_health.

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?

Clear context for when to use it (to begin monitoring an app) and an implied follow-up flow via get_install_instructions. It does not state exclusions or when a sibling is preferable, but the triggering condition is unambiguous.

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

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

Annotations already flag openWorldHint=true, readOnlyHint=false and idempotentHint=true; the description adds the crucial nuance that the write is internal only ("Records the result on the app in Vigilia") and that the target site is untouched. It does not cover auth requirements or how often the outbound fetch may be repeated, so it is strong but not exhaustive.

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, then the usage condition, then the side-effect boundary. No filler and nothing repeated from the schema or annotations.

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 should say what the caller gets back from a check. It only says the result is recorded on the app, leaving it ambiguous whether the pass/fail verdict is returned here or must be retrieved via get_app_health.

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 a single required parameter, appId, with 0% schema description coverage, and the description never mentions it. The meaning is largely self-evident from the tool's framing, but the description contributes nothing to disambiguate which app identifier is expected.

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 concrete verb and resource: fetch the live pages and verify both the Vigilia tag's presence and the CSP that permits it to run. That is far more specific than siblings like get_app_health or get_install_instructions, so an agent can tell the three 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?

"Use after deploying an install" gives a clear triggering condition for invocation. It stops short of naming alternatives (e.g. get_app_health) or stating when not to run the check, so it is clear context without explicit exclusions.

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?

Beyond annotations, it discloses the critical non-idempotent secret lifecycle behavior: the key is shown once and must be set immediately, and must never be stored in code or a committed file. It also confirms it never replaces a key and requires a paid plan, which is substantial operational context.

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

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

The description is a single dense sentence with a second sentence on usage safety, front-loading the core action. It is appropriately sized for a creation tool, though slightly dense in the first sentence.

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

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

Given the lack of an output schema and rich annotations covering safety hints, the description supplies all necessary behavioral context: one-time visibility, immediate secret setup, non-replacement, and plan requirement. An agent has enough to call it correctly.

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

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

Schema coverage is 100%, so parameter documentation is already strong. The description adds contextual constraints but doesn't elaborate on appId or platform beyond what the schema provides; however, the schema itself is sufficient, and the description references platform indirectly via instructions.

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 ('Make the secret key') and resource, and ties it to the product and its use: 'the secret key @getvigilia/server sends this app's backend errors with.' It also constrains the scope to 'an app that has none yet,' distinguishing it from key rotation handled elsewhere.

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 limits use to apps that have no key yet and states that it never replaces an existing key, directing that case to the owner in Vigilia. It also notes the paid-plan requirement, giving a clear when-to-use and when-not-to-use boundary.

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 and openWorldHint=false, so the safety profile is covered. The description adds value by disclosing the returned data categories, but says nothing about freshness, caching, or failure modes, so it is adequate rather than rich.

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?

A single tight sentence that front-loads the resource and lists the returned metrics with zero filler. Every clause carries information.

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 carries the burden of explaining return values and does so by enumerating the four metric groups. Nothing critical is missing for a single-parameter read tool, though scope (per-app, per-workspace) and time-boundary details are only loosely implied.

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% and the single appId parameter is documented as originating from list_apps. The description adds no parameter-level meaning beyond the schema, 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 states a specific resource and enumerates exactly what is returned (uptime, open incidents by severity, today's traffic, AI diagnosis budget). This clearly distinguishes it from siblings like get_incident or list_open_incidents, though it doesn't name an alternative 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?

Usage is only implied: it is a point-in-time health snapshot for one app. There is no explicit when-to-use guidance or routing to alternatives such as list_open_incidents or get_incident, which also surface incident data.

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 and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that by enumerating the three possible outcome states, which is especially valuable given there is no output schema to carry them.

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?

One sentence that leads with the subject of the query and lists the outcomes in a logical sequence. It is appropriately sized, though the sentence fragment structure is slightly less scannable than a verb-first 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?

With no output schema and an annotations block that only covers safety hints, the description does the important remaining work of describing the outcome values an agent will receive. It stops short of explaining timing or polling behavior for the 'still being watched' state.

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 single incidentId parameter is undocumented in structured data. The description never mentions incidentId or its format, but the name is self-explanatory and the tool only takes one argument, so the practical risk is low.

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 resource (a fix marked with mark_fixed) and the question it answers (confirmed by traffic, still being watched, or did not hold), and it names the sibling mark_fixed that produces the input. It is a fragment rather than a verb-first statement, but an agent can still tell it apart from get_incident or get_app_health.

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?

Usage is only implied: by referencing mark_fixed, it suggests this tool is called after a fix has been marked. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer the sequencing.

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 and openWorldHint=false, so the safety profile is covered; the description's real contribution is enumerating what the payload contains (diagnosis, affected users, evidence, fix prompt), which matters because there is no output schema. It stops short of saying anything about permissions, missing-incident errors, or freshness.

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?

A single sentence, front-loaded with the core idea ('One incident in full') and then a tight parenthetical enumeration of contents. No filler, though the long nested list about the technical evidence is dense enough to be slightly harder to scan than a shorter clause would be.

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 carries the return-value burden and does so well, and the single input parameter is fully documented in the schema. Gaps are minor: nothing about failure modes (invalid or unknown incidentId) or access requirements.

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 one parameter with 100% schema description coverage, and the schema already explains where incidentId comes from. The description adds no format, ID-shape, or validation detail beyond that, so the baseline 3 for schema-covered parameters 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 phrase 'One incident in full' clearly identifies the resource and scope, and the contrast with the sibling list_open_incidents is implied by 'one ... in full'. It does not name the sibling explicitly, so an agent must infer the single-vs-list relationship rather than being told.

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?

Usage is implied rather than stated: this is the detail view for an incident discovered elsewhere, and the schema's 'From list_open_incidents' hints at the source of the id. There is no explicit when-to-use, no when-not-to-use, and no named alternative in the description itself.

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 and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the returned snippet embeds the app's key, and CSP guidance is emitted 'if — and only if — the project already has one', which tells the agent output varies by project state.

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?

A single tight sentence with the three returned artifacts listed in priority order (script tag, placement, CSP). The em-dash aside on CSP is dense but earns its place by preventing spurious CSP advice.

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, so the description must convey the return shape, and it does: script tag, insertion point, conditional CSP entry. It leaves open what happens when framework is omitted, but for a read-only instruction generator that is a minor gap.

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 both parameters (appId, framework) are already fully documented with the framework enum enumerated. The description only loosely ties 'framework' to placement and 'key' to appId, adding little beyond the schema; 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 precisely what the tool returns: the exact script tag (with key), where it goes for the given framework, and the CSP addition. It is a noun-phrase rather than a verb+resource statement, but the output is unambiguous and 'for an app' distinguishes it from the sibling get_server_install_instructions without naming 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?

No explicit when-to-use, prerequisites, or named alternatives. The appId description ('From list_apps') and the conditional CSP clause imply the workflow (list apps first, then fetch instructions), but the agent must infer that this precedes check_install.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that: it discloses what the returned payload contains (wrapping code plus two secrets) and, importantly, what it deliberately omits ("Never includes the key itself"). Return-shape and pagination details are absent, keeping this short of 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?

Two tight sentences with no filler, and the core payload description is front-loaded. The parenthetical platform list is slightly redundant with the schema enum but otherwise every clause carries information.

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 read-only instruction-fetching tool with no output schema, the description supplies enough: it names the integration target, the supported platforms, the secrets involved, and the guarantee that no key is returned. Nothing critical for a correct call is missing.

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

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

Schema description coverage is 100%, so both parameters are fully documented in the schema, including the platform enum meanings. The description only echoes the platform list (Supabase, Next.js, Vercel, Cloudflare, Express) already present in the enum, so it does not materially extend parameter meaning beyond the structured fields.

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 concretely what the tool returns: the handler-wrapping code for @getvigilia/server and the two secrets it reads, across named platforms. It distinguishes itself from create_server_key ("Never includes the key itself"), but does not explicitly contrast with the sibling get_install_instructions, leaving some ambiguity about which install guide to pick.

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?

Usage is only implied: the reader infers this is for server/backend integration because the content is server-side and the alternative create_server_key is named for apps lacking a key. There is no explicit when-to-use-this vs get_install_instructions guidance, so the agent must infer from the platform enum and wording.

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 and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the returned payload (install status, uptime status, open incident counts per app), which matters because there is no output 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?

A single efficient sentence with no filler, and the resource identity is front-loaded. It reads as a noun phrase rather than an imperative, which is a minor structural weakness but costs nothing in comprehension.

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 usefully enumerates the key returned fields, which is the main thing an agent needs here. It does not address result size, pagination, or ordering, but for a zero-parameter read that is a minor 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify about inputs.

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 the specific resource (the web apps Vigilia watches for this person) and the payload contents, so an agent knows this is a discovery/list operation. It does not explicitly distinguish itself from siblings such as get_app_health or list_open_incidents, which overlap in returned information.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternatives. The agent must infer that this is the broad entry-point listing versus the per-app siblings like get_app_health or check_install.

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 and openWorldHint=false, so the safety profile is covered. The description usefully adds the default result ordering, but says nothing about pagination behavior, the limit default interacting with result count, or what fields an incident carries.

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; the behavioral summary and ordering arrive first, and the usage cue follows immediately. Nothing is repeated from the schema or annotations.

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 read-only, zero-required-param list tool with 100% schema coverage and annotations covering safety, the description is nearly complete. Minor gaps remain around pagination/result-count behavior and whether 'open' is itself a filter, but nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, and each of the three parameters is already well documented in the schema (appId source, limit default/max, severity enum examples). The description's 'worst first' ordering hints at severity semantics but adds no syntax or format detail beyond the schema.

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

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

The description states a specific resource (open incidents) and scope ('what's broken right now'), plus the sort order ('worst first, by severity, then most recent'). It is clearly distinguishable from get_incident and get_app_health in substance, though it never names a 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?

'Start here when asked to fix Vigilia incidents or to check what's wrong with an app' gives a concrete entry-point condition for when to reach for this tool. It stops short of naming alternatives (e.g. get_incident for a single incident, get_app_health for a general health snapshot) or stating 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 non-readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: Vigilia monitors real traffic afterward and reopens the incident as a regression if the error returns. This post-call lifecycle is the key non-obvious trait, though it says nothing about the immediate response or how long confirmation takes.

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 that front-load the action and then the pre-condition, with no filler. Every clause carries information: what to call it for, when, and what happens as a result.

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 mutation with no output schema, the description covers the essential agent-facing questions: the precondition (fix must be deployed) and the consequence (traffic-watch and possible regression reopen). It leaves the immediate return value and any latency of confirmation unstated, a minor gap.

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 one required parameter (incidentId) and schema coverage is 100%, so the schema fully documents it. The description adds no meaning about the identifier's format, provenance or how to obtain it, landing exactly at the baseline for schema-covered parameters.

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?

Names a specific verb and resource ('Tell Vigilia an incident is fixed'), stated in plain operational terms rather than restating the name. It is clearly distinguished from read-side siblings like get_incident and get_fix_status by being a state transition, though it never names an alternative tool 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?

Gives explicit timing guidance — 'call this after the fix is deployed — not just written' — which is a real when-to-use and implicit when-not-to-use condition. It does not point to a sibling tool for the case where the fix is merely written, 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.