The Wiley Rule (public data)

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 and determinism profile is fully covered without the description. The description adds useful scope context — that the response is static reference material spanning mission, legal status, contact and history — rather than live or query-dependent data.

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 with a front-loaded subject and a compact enumeration of covered topics; nothing is redundant. The list is slightly laundry-list-like but each item genuinely maps to a distinct section of the returned content.

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 parameters, no output schema and full annotation coverage, the description's enumeration of content sections effectively doubles as a return-value summary, which is the main thing an agent needs here. Only the routing guidance relative to sibling tools is missing.

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

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

The schema takes zero parameters, so there is no parameter semantics to document; baseline 4 applies. The description correctly adds no param claims, and the empty schema matches the 'no input needed' framing.

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 clearly that this tool returns background information about The Wiley Rule, enumerating the specific content it covers (mission, the one-line rule, legal status, contact, reporting process, name history). That scope is specific enough to tell it apart from data-oriented siblings like search_products or latest_news, though the verb is implied rather than explicit.

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, when-not, or named alternative is given. The enumerated content topics imply this is the background/context tool to call before using siblings like search_products or who_supports, but the agent has to infer that routing 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the substantive scope of tracked items (NC bills, DEA notices, FDA actions), but says nothing about what is returned, whether results are limited or sorted, or whether an omitted query returns everything.

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; the scope statement is front-loaded and the optional-filter note follows. 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, single-optional-param tool with no output schema and annotations covering safety, the description is nearly sufficient. Minor gap: it does not say how results are ordered, truncated, or how matching works across the mixed domains.

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 parameter is fully documented there, including the same examples ('HB 328', 'DEA', 'North Carolina') repeated in the description. Baseline 3 applies since the description adds no meaning 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?

States a specific resource (status of tracked legislation and rulemaking) and scopes it with concrete examples: NC bills, DEA scheduling notices, FDA actions. An agent can tell this tracks a curated set of items, though it does not explicitly distinguish itself from siblings like nc_legislation or state_actions.

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 when-to-use guidance at all: nothing says when to call this versus nc_legislation, state_actions, or key_dates, and nothing states whether an empty query is a meaningful call. Only 'Optional keyword filter' hints at behavior, which is usage implication at best.

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 the annotations (readOnly, idempotent, non-destructive, closed-world), the description adds real behavioral context: the geographic restriction, the derivation method ('Census ZIP-area center point'), an accuracy caveat, and the fact that a member's position record is only included if public. It stops short of describing the response shape, but that is not critical here.

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 dense sentence plus a short caveat sentence, with the limiting scope 'North Carolina only' front-loaded. Slightly run-on, but every clause carries information and 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?

For a single-parameter lookup with no output schema, the description covers who it applies to (NC), how the match is made (ZIP center point), what comes back (House/Senate districts, office pages, public position records), and the main accuracy risk. An agent has everything needed to call it and interpret the answer 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?

Schema description coverage is 100% for the single 'zip' parameter (pattern ^\d{5}$, described as '5-digit ZIP code'). The description restates 'from a 5-digit ZIP' without adding format or edge-case detail, so the schema is doing the work; 3 is the appropriate 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 states a specific verb and resource ('from a 5-digit ZIP, find the NC House and Senate districts... and the public office pages of those members') and immediately scopes it ('North Carolina only'). None of the sibling tools (bill_status, nc_legislation, latest_news, etc.) do geographic legislator lookup, so the agent can route to it unambiguously.

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

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

It gives clear triggering context ('from a 5-digit ZIP') and a caution about when the result may be off ('ZIPs can cross districts, so confirm with the official lookup'). It does not name a sibling alternative or state explicit exclusions, but no sibling genuinely overlaps for this task.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description adds that the result is the 'full public record' (completeness, public availability), which is useful context, but says nothing about response shape, not-found behavior, or lookup failures.

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, front-loaded with the resource and scope ('one study from the research library'), followed by the identifier forms. No filler and nothing redundant with 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?

For a single-parameter read tool with complete annotations and no output schema, the description covers what the tool returns ('full public record') and how to identify the target. Only the alternative-route guidance 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 the schema already names the accepted identifier kinds, so the baseline is 3. The description earns an extra point by supplying a concrete example format ('pmid-40373645'), which clarifies the expected id style in a way the schema 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?

Names a specific verb+resource: retrieve the full public record for one study. The identifier formats (internal id, PMID, DOI) sharpen the scope considerably. It does not explicitly differentiate itself from the sibling search_research, so it falls short of 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?

The description implies the triggering condition (you already have an identifier and want the complete record), but never states when to use this over search_research or what to do if the identifier is unknown. Usage is left 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 declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered by structured data. The description adds domain scope (which kinds of dates count as key), which is useful context. It does not disclose coverage window, ordering, or freshness — moderate added value, hence a 3.

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 noun phrase 'Upcoming dates that matter' followed by the discriminating examples. No filler, no restatement of the title 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 zero-param, read-only tool with no output schema this is close to adequate, and the category examples give a good sense of scope. It is missing the temporal window (how far ahead), whether results are ordered chronologically, and how curation works — minor but real gaps for a 'dates' 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?

Zero parameters with a well-formed empty schema, so there is nothing for the description to disambiguate. Per the rubric, a 0-parameter tool has a baseline of 4; the absence of any argument syntax is consistent with that.

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 clear resource (upcoming dates) and enumerates the content categories that define it: DEA orders, NC votes, federal comment deadlines. That is concrete and non-tautological. It stops short of explicitly distinguishing itself from adjacent siblings like latest_news or bill_status, which could also surface time-sensitive items.

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 by the category list — an agent can infer 'call this when the user needs upcoming deadlines' — but there is no explicit when-to-use statement, no prerequisites, and no named alternative to prefer instead. The guidance is left 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful scoping (this tool only reports what the site tracks, and where that content comes from), but says nothing about recency window, ordering, or return format.

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

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

One front-loaded sentence with no filler; the parenthetical source list is information-dense rather than wasted. Efficient, though it could be slightly tightened.

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 should carry more of the return-value burden; it identifies the content domain but not ordering, recency window, or item shape. With annotations covering safety and no required parameters, the definition is minimally viable but not complete.

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

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

The single parameter is the cryptic name 'n' with 0% schema description coverage, and the description never mentions it. An agent cannot tell from either source that 'n' is the count of items (default 5, max 20), so the description fails to compensate for the coverage 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 resource (most recent public news and official notices) and enumerates the sources it aggregates (Federal Register, FDA, DEA, state actions, press), so an agent knows what it retrieves. It does not explicitly distinguish itself from the sibling state_actions, which it merely lists as one of its input sources.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as state_actions or bill_status that overlap in topic. The agent must infer the appropriate context entirely from the one-line purpose statement.

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 fully covered. The description adds only scope context ('the site tracks'), and says nothing about result size, pagination, or freshness; with annotations doing the heavy lifting, a 3 is fair.

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 compact sentence with no filler or redundancy. It is front-loaded with the primary content (bills and actions), though the trailing clause about the state table is slightly ambiguous.

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 is the only source of information about results, and it never indicates whether the return is a single status object, a list of bills, or how much data comes back. For a zero-parameter tool this leaves a meaningful gap, though the annotations cover the safety dimension.

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 there is nothing for the description to disambiguate. Baseline 4 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 names a specific resource set — NC bills and actions the site tracks, plus NC's status in the state table — so an agent knows roughly what it returns. It does not, however, distinguish this from closely related siblings like state_actions or bill_status, and it uses a noun phrase with no verb.

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 when-to-use guidance is given at all. With siblings such as state_actions, bill_status, and key_dates that plausibly overlap, the description never says when this tool is the right pick or when another should be used instead.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond them: results are restricted to sourced claims and each is paired with its source document, and retailer/store data is deliberately absent. It stops short of describing result ordering or how the limit parameter behaves.

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 core action and scope are front-loaded, and the return-content and exclusion details follow immediately 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?

With no output schema, the description usefully enumerates what comes back (sourced claims, each with its source document), which is the key missing structured information. Minor gaps remain around result ordering and limit/pagination semantics, but nothing essential to invoking the tool correctly is absent.

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 only 50%: the query parameter is well documented in the schema (with examples), but limit (min 1, max 24, default 8) is undocumented anywhere. The description adds no parameter-level meaning at all, so it does not compensate for the undocumented limit and falls below the baseline expected when the schema carries the load.

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 (search products on The Wiley Rule's public product pages) and pins down the content domain with concrete examples of what is returned (lab/forensic results, FDA warning letters, court filings) plus an explicit exclusion (no retailer/store info). It does not name or contrast with the closest sibling, search_research, so differentiation from the other search tool is left to inference.

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 by the scope statement ('Search products on ... public product pages'), but there is no explicit when-to-use, when-not-to-use, or alternative routing. The only exclusion ('No retailer or store information') is a content-scope boundary rather than guidance on choosing this tool over search_research or get_study.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the size and subject matter of the corpus and the exact shape of the results (titles, authors, year, type, summaries, links). It does not, however, mention result limits or ordering.

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 dense sentences with zero filler, front-loaded with what is searched before what is returned. Every clause earns its place.

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

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

With no output schema, the description usefully specifies the return fields, covering the biggest gap. What remains unstated — default/max result count and whether results are ranked — is minor and recoverable from the schema defaults.

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 75%, with examples already embedded for query and topic, so the schema carries most of the load. The description adds no parameter-level detail beyond confirming keyword semantics; limit and year get no elaboration at all. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('Keyword search over The Wiley Rule's public research library') and quantifies the corpus (288 studies on 7-OH, kratom alkaloids, MGPI). It also enumerates return fields, which cleanly separates it from sibling tools like search_products and get_study.

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

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

The description implies usage — keyword lookup in the research library — but never states when to prefer this over the sibling get_study (single-study retrieval) or when to omit. No explicit exclusions or alternatives are named.

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 this as a safe, idempotent, closed-world read. The description goes further by disclosing data provenance (public sources) and a coverage boundary ('all states the site tracks'), which helps the agent calibrate expectations for completeness.

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: the scope statement is front-loaded and the calling instruction follows immediately. No filler or redundancy.

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

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

For a one-optional-parameter read tool with full annotation coverage and no output schema, the description supplies scope, source type, and coverage limits. It stops short of hinting at the shape of returned results, but nothing essential to invocation 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% and the single optional parameter is fully documented there. The description only restates the accepted formats and optionality, adding no format or semantics 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 verb (state) and resource (bans, scheduling and rules on concentrated 7-OH and kratom alkaloids), giving an agent a clear picture of what it returns. It does not explicitly distinguish itself from policy-adjacent siblings like bill_status or nc_legislation, which also concern drug legislation.

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 tells the agent how to scope the call (pass a state, or omit for all tracked states), which is useful operational context. However, it offers no guidance on when to prefer this over bill_status or nc_legislation, so alternative selection is left 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 declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds useful behavioral context by disclosing the evidence basis (votes, sponsorship, statements, or self-reported to The Wiley Rule) and constraining the output to name, office, district, party and an evidence label.

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 definition and then the returned fields; no filler. Slightly dense with parenthetical sourcing detail but every clause earns its place.

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

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

With no output schema, the description correctly spells out the returned fields. It does not explain what the 'evidence label' values mean, but for a simple filtered lookup with full annotation coverage it is nearly complete.

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

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

There is a single optional 'office' filter and schema description coverage is 100%, so the baseline is 3. The description never mentions the filter or its accepted values, so it adds nothing 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 and inclusion criterion: officials with a public record of supporting action on 7-OH. It is a listing/lookup tool, but it does not differentiate itself from siblings such as state_actions or find_my_lawmakers, so the boundary is left to inference.

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 explicit when-to-use or when-not-to-use guidance, and no sibling alternative is named despite there being several overlapping tools (state_actions, find_my_lawmakers, nc_legislation). The inclusion criteria hint at scope but do not route the agent among alternatives.

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