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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the action but does not disclose whether this is read-only, requires permissions, has rate limits, or what happens with insufficient data. It adds no traits beyond the stated calculation.

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 concise sentence with no filler. It front-loads the verb and resource, making the purpose immediately clear.

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 four-parameter tool with no output schema and no annotations, this description is too sparse. It does not describe the return shape, interval options, or time format requirements, so an agent may call it with incorrect or incomplete inputs.

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 maps 'symbol' and 'timeframe' to symbolId and startTime/endTime, but it does not explain the 'interval' parameter or time string formats. Several parameters remain undocumented by both schema and description.

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 uses a specific verb ('Calculate') and names the resource ('technical indicators') with explicit indicator list (RSI, SMAs, VWAP, Bollinger Bands). It clearly distinguishes this from sibling tools like qt_get_candles, which fetch raw price data, and qt_compare_symbols, which compare symbols.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention qt_get_candles for raw data or any exclusions, so an agent must infer the use case from the name and description alone.

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

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

With no annotations, the description carries the full disclosure burden, but it only names the operation and the 'normalized chart' output concept. It does not explain how normalization works, what the output format is, symbol limits, or whether this is a read-only analysis, leaving significant behavioral uncertainty.

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 front-loaded sentence with no filler; every word earns its place. It is not penalized more here because the missing detail is accounted for in other dimensions.

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

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

The tool has four parameters, no output schema, and no annotations, and sits among ten related siblings, yet the description gives no return type, no comparison methodology, and no constraints on symbols or time ranges. An agent cannot reliably decide versus siblings or predict the output.

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 adds meaning only for symbolIds ('multiple symbols') and vaguely implies time via 'performance', but startTime/endTime formats and the interval enum are left entirely to the schema, which itself has no descriptions.

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 uses a specific verb ('Compare') and resource ('performance of multiple symbols'), and adds a distinctive detail ('normalized chart') that separates it from sibling tools that fetch quotes/candles or analyze technicals. It does not explicitly name a sibling alternative, so it falls just 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?

There is no guidance on when to choose qt_compare_symbols over qt_get_candles, qt_analyze_technicals, or qt_screen_watchlist. The sentence only states the action; it does not give conditions, prerequisites, or 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?

With no annotations, the description carries the burden. 'Get' signals a read-only operation and 'all' implies no filtering, but it does not disclose authentication/session requirements, rate limits, or whether the response is a flat list. This is acceptable but shallow.

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 sentence with no filler, and the key verb/resource appears first. It is appropriately sized for a simple zero-parameter tool.

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-parameter list, the description is a minimum viable summary, but there is no output schema or annotation to clarify what an account object looks like or whether prerequisites exist. More context would improve call confidence.

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 are zero parameters, so the schema is trivially covered. The description's 'all' clarifies no filtering is available or needed, matching the empty schema. 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 verb ('Get') and resource ('all Questrade accounts'), and the scope ('all') distinguishes it from sibling tools that retrieve positions, balances, quotes, orders, etc. This is a clear, non-tautological statement of function.

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

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

There is no explicit statement of when to use this tool or exclusions, but the resource name and sibling list imply it is for retrieving the account list, not positions, balances, or quotes. This is implied usage rather than explicit guidance, so a 3.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says "Get account balances." While "Get" implies a read-only operation, it does not disclose whether an omitted accountId returns all balances, what authorization is expected, or what the 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?

The description is extremely concise and front-loaded, with no filler or redundant phrasing. However, it is so minimal that it may be under-specified rather than deliberately efficient, though purely as a concise statement it works.

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

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

Given no annotations, no output schema, and a single undocumented parameter, the description is not complete enough for an agent to understand behavior, response shape, or accountId handling. The statement only provides enough surface-level information to know what resource the tool acts on.

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 exposes a single optional accountId parameter, and the description adds no meaning beyond the property name. With 0% schema description coverage, the description should clarify how accountId is used or what happens when it is omitted, but 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?

The description "Get account balances" clearly identifies the action (get) and resource (account balances), making it distinguishable from sibling tools like qt_get_positions or qt_get_quotes. It is not a tautology, though it does not elaborate on the exact scope of 'balances' or whether it covers all accounts or a single specified account.

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

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

The description provides no guidance on when to choose this tool over its siblings, such as qt_get_accounts or qt_get_positions. There is no mention of intended scenarios, exclusions, or how the optional accountId affects the call.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only adds 'with ASCII chart' as an output behavior; it does not disclose read-only status, authentication needs, default interval behavior, timezone handling, pagination, limits, or error behavior. This is insufficient for a tool with no annotation support.

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, front-loaded sentence with no wasted words. It efficiently communicates the core action and a notable output feature. However, it is so minimal that it leaves out important operational detail, so it does not earn a 5.

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 four parameters, no output schema, no annotations, and 0% schema description coverage, the description is far too sparse to enable confident invocation. It fails to explain timestamp formats, what happens when interval is omitted, possible output variants, or how the ASCII chart is rendered. An agent would have to guess at several important invocation details.

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 none of the four parameters by name. The agent gets no additional meaning about symbolId, startTime, endTime, or interval beyond their raw names. The description does nothing to compensate for the schema's complete lack of parameter documentation.

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

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

The description clearly states a specific verb ('Get'), a specific resource ('historical candle data'), and even indicates the output style ('with ASCII chart'). It is easy to understand what the tool does. However, it does not explicitly differentiate itself from siblings such as qt_get_quotes or qt_analyze_technicals, leaning on the term 'candles' to imply the distinction.

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 guidance about when to use this tool versus related siblings. The description does not mention that qt_get_quotes is better for current prices, or that qt_analyze_technicals might be a better choice for analysis. An agent receives no contextual decision-making support.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It does state that the operation is read-only and that filters are optional, which are useful traits. However, it does not mention authentication needs, date format expectations, default behavior, or what happens when optional parameters are omitted.

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 sentence that front-loads the core purpose and remains free of filler. It is appropriately concise, though it sacrifices some useful detail for brevity.

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 four unannotated parameters and no output schema, the description is too sparse to fully support correct invocation. It does not explain parameter formats, required vs optional behavior, output shape, or error cases, leaving significant gaps for an agent relying solely on this definition.

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 adds meaning by saying filters are by 'state and date range', which maps to stateFilter, startTime, and endTime; 'for an account' implies accountId. However, it does not clarify date formats, enum semantics, or default values.

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

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

The description clearly identifies the resource as 'orders' and the action as 'Get', with the scope being 'for an account'. It distinguishes its subject matter from sibling tools like qt_get_positions and qt_get_balances by naming the specific resource type, though it does not explicitly contrast itself with them.

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

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

The description gives no explicit guidance on when to use this tool instead of siblings. It implies the tool is for retrieving orders and optionally filtering, but there are no exclusions, prerequisites, or alternative tool references.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation (likely implied by 'Get') or what the response looks like. It also does not mention if it provides real-time data, historical positions, or if it requires authentication. The description is too minimal to be transparent.

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

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

The description is a single short sentence that is concise and front-loaded. It is not verbose, but its brevity sacrifices necessary detail. It earns a 4 for efficiency, but loses a point for lack of completeness.

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 it's a simple tool with one parameter and no output schema, the description is extremely sparse. It does not explain what positions are, how the accountId is used, or the nature of the response. An agent would have limited understanding of how to use this correctly, especially with no annotations to fall back on.

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%, meaning the schema provides no descriptions. The description only mentions 'accountId' implicitly by saying 'for an account', but does not explain its format, requiredness, or how to obtain it. Since the schema has one parameter with no description, the tool description should at least clarify the parameter's role, which it barely does.

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 'Get current positions for an account' clearly states the verb 'Get' and the resource 'positions', with the scope being 'for an account'. It is somewhat generic but does identify a distinct purpose from siblings like qt_get_balances or qt_get_orders. However, it doesn't specify what a 'position' is in this context (e.g., holdings, open trades), which could cause ambiguity.

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 guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., need an account ID) or differentiate from qt_get_balances (which may also relate to account holdings). The sibling list suggests multiple financial data tools, but the description provides no context for choosing this one.

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

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

With no annotations provided, the description carries the full behavioral burden. It explicitly labels the operation 'read-only', which is a key safety indicator, but it does not disclose output format, data freshness guarantees, error behavior, or any rate limits.

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 front-loads the core action and scope, with no filler or redundant information. Every word contributes meaning.

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

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

The tool is simple, with one parameter, and the description covers purpose and input. However, with no output schema and no annotations, the return value structure and underlying data source are left undefined, leaving some ambiguity for an agent expecting quote fields.

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 clarifies that 'symbolIds' refers to symbol identifiers and supports 'one or more', complementing the schema's array constraints. It does not explain how to obtain or resolve symbol IDs.

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?

Description states a specific verb ('Get'), a precise resource ('real-time quotes'), and the input scope ('one or more symbol IDs'). This clearly differentiates it from sibling tools such as qt_get_candles, qt_get_accounts, and qt_lookup_symbol.

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 'real-time' qualifier implies use for current market data as opposed to historical data from qt_get_candles, but there is no explicit statement of when to use or avoid this tool, and no alternatives are named. Usage must be inferred.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get' and 'historical' imply a read-only operation, but the description does not state authentication requirements, date-range semantics, pagination, or what response shape to expect.

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 sentence with no filler and the key verb is front-loaded. It is concise, though slightly vague with 'transactions/activities'.

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 large sibling set, no output schema, and no parameter documentation, the description is too thin for an agent to confidently select and invoke the tool. It needs more context about parameter behavior, result shape, and how this differs from related data tools.

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 loosely maps to the parameters via 'historical' (startTime/endTime) and 'account' (accountId), but it does not explain time format, whether the range is inclusive, or how accountId behaves when omitted.

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 uses a specific verb ('Get') and identifies the resource ('historical transactions/activities') and scope ('for an account'). It is not a tautology and clearly conveys the tool's core function, but it does not explicitly distinguish it from sibling tools like qt_get_orders or qt_get_candles.

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

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

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about prerequisites. An agent cannot tell from the description why it should choose this over qt_get_orders or other sibling tools.

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

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

With no annotations, the description carries the full burden of explaining behavior. It only says 'search', without covering prefix matching semantics, case sensitivity, number of matches, or data source. It is not misleading, but it is seriously under-informative.

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 short sentence with no filler, but it is under-specified rather than appropriately concise. It leaves out essential semantic content that the tool name does not supply.

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

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

For a one-parameter tool with no output schema, the description should at least state what the prefix means and what a successful lookup returns. It does neither, so an agent lacks enough information to invoke it correctly and interpret the result.

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 provides only a string type and no description, and schema coverage is 0%. The description never explicitly explains that 'prefix' is the text used to search, though the parameter name makes that inference easy. This is minimal added meaning.

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

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

The description names a concrete action and object ('search for a stock symbol ID'), so the basic purpose is identifiable. However, it is close to a restatement of the tool name and does not clarify what kind of result is returned or how it differs from sibling symbol-related tools.

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 guidance is given on when to call this tool versus alternatives like qt_compare_symbols or qt_get_quotes. There are no conditions, prerequisites, or exclusions, so the agent must guess from the name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions screening against criteria but doesn't state whether this is a read-only operation, whether it fetches live data, how results are returned, or any side effects. For a screening tool that likely performs computation over time series, the lack of behavioral context is a notable gap.

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 sentence that is reasonably concise and front-loads the core purpose. It includes useful examples of criteria. However, it could be slightly more structured by separating the purpose from parameter details, but it is not overly verbose.

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

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

Given the tool has 5 parameters, a nested criteria object, no output schema, and no annotations, the description is incomplete. It doesn't explain the time range parameters, the interval enum, or how the criteria interact (e.g., AND vs OR). An agent would need to infer too much to call this tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions two example criteria (maxRsi, mustBeAbove200Sma) and doesn't explain the meaning of startTime, endTime, interval, symbolIds, or the other criteria fields. The nested criteria object is left mostly unexplained, and the time range semantics are not described.

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 ('Screen') and resource ('a list of symbols') against technical criteria, with concrete examples (maxRsi, mustBeAbove200Sma). It is clear what the tool does, though it doesn't explicitly differentiate from siblings like qt_analyze_technicals or qt_compare_symbols, which could overlap in purpose.

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 guidance is given on when to use this tool versus alternatives. Sibling tools like qt_analyze_technicals and qt_compare_symbols likely perform similar technical analysis, but the description doesn't explain the distinction or when to prefer one over the other. The context is implied by the name and description but not explicit.

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