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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), but the description adds real value beyond them: it guarantees the token itself is never returned and that the response identifies the token owner. It does not say whether validity is checked locally or against the server, which matters given openWorldHint=true.

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, both earning their place: the first defines the output meaning, the second defines the call trigger. The most actionable instruction (call this on a login error) is placed prominently and no filler is present.

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 describing the return, and it does so (availability + owner identity, never the token). The one gap is whether the check is purely local or performs a remote validation, which openWorldHint=true makes relevant and which the description leaves ambiguous.

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 no parameter semantics to document and the baseline of 4 applies. Nothing in the description misleads 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 opens with a specific verb+resource: it reports whether a local B2match token exists and, if valid, which user it belongs to. That is clearly distinguishable from every sibling tool (list_my_events, get_participant, etc.), none of which is a diagnostic tool.

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 states the trigger condition — call this first when an authenticated tool (my_*, list_my_events, conversations, notifications) reports a login error — and explicitly states the negative case: public tools work without a token. Both when-to-use and when-not-to-use are covered.

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, destructiveHint=false and idempotentHint=true, so the safety profile is known. The description restates this in domain terms ('does not book or request a meeting'), which is mildly useful emphasis but adds little new information. It says nothing about the 1-10 participant cap, permissions, or 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?

Three short sentences with no waste; the core capability is front-loaded and the exclusion follows immediately. Every clause carries routing or scope 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 search tool with full schema coverage and annotations, this is nearly sufficient. The only gap is that no output schema exists and the description does not hint at the shape of the returned slots.

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

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

Schema description coverage is 100%, so the baseline is 3 — the schema already explains day, event, duration, participant_ids and the long-term flag in detail. The description only reinforces the 'one day' scoping already present in 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 verb and resource ('Find free meeting slots') plus the exact scope: shared by the viewer and selected participants, on one day. It explicitly distinguishes itself from my_availability, so an agent can route without opening either schema.

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

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

Gives a clear usage context (mutual free time with chosen participants) and names one alternative with its condition ('Use my_availability for your own free time only'). It does not mention meeting_recommendations as a related-but-different option, so the routing picture is clear but not exhaustive.

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, open-world behavior, so safety is covered. The description adds real behavioral context the annotations cannot: the menu path is auto-resolved and 'path' merely overrides that default. It stops short of describing result shape or volume, but for a read-only listing that is a minor 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?

Three short sentences, front-loaded with what is returned, then disambiguation, then the override behavior. No filler.

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

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

For a simple two-parameter read-only tool with full schema coverage and an annotation-declared safety profile, the description supplies everything needed to call it correctly. Only the shape of returned agenda blocks is left implicit.

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

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

Schema coverage is 100%, so both parameters are already documented, including the 'omit to resolve automatically' semantics of path. The description's 'pass path to override' restates the schema rather than adding new meaning, 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 specific verb and resource ('Fetch the event agenda') and scopes the content ('sessions and networking blocks with times'). It also names the sibling tools it is not (get_session, my_schedule), so an agent can distinguish it without opening another schema.

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

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

Explicitly routes the agent: use get_session for one session's details and my_schedule for a personal schedule. The condition selecting this tool versus those alternatives is stated rather than 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?

The annotations only say readOnlyHint=false without explaining why; the description supplies the reason — fetching messages causes B2match to mark the conversation read even though this client never sends MarkConversationAsSeen. It also discloses the gating and the error outcome, which is exactly the context annotations cannot carry.

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?

Front-loaded with the action, and each of the four sentences carries distinct information (side effect, gating, alternative, error). The aside about never sending MarkConversationAsSeen is implementation detail, but it is what justifies the non-read-only annotation, so it mostly 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?

Covers side effects, gating, alternatives and error behavior, which is the hard part for a two-parameter tool. With no output schema, the message payload shape and any pagination or result-limit behavior are left implicit, a minor remaining 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 coverage is 100%, so the baseline is 3; the description goes beyond it by clarifying that both the environment flag and acknowledge_marks_read must hold, and by noting that unknown ids (the conversation_id parameter) produce a not-found error. It does not add format or sourcing detail beyond the schema's 'Conversation UUID from list_conversations'.

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?

Opens with a concrete verb+resource ('Fetch conversation messages') and immediately separates it from list_conversations, which is called out as the preview-oriented sibling. An agent can route between the two without reading either schema.

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

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

Explicitly names the alternative and the condition that selects it ('Use list_conversations for last-message previews'), states the enablement precondition (B2MATCH_ALLOW_SIDE_EFFECT_READS=1 plus acknowledge_marks_read), and reports the not-found behavior for unknown ids.

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, openWorld, and non-destructive, so the safety profile is covered. The description still adds two useful signals beyond them: the data is 'public' (scope of what is exposed) and it 'works without login' (no auth prerequisite). It does not discuss rate limits, error behavior, or payload size, keeping it 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 sentences, front-loaded with what is returned, then the routing rule and the auth note. No filler and no repetition of the tool name or 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 one-parameter read tool with no output schema, the description covers purpose, enumeration of returned content, entry-point sequencing, the alternative tool, and auth requirement. Nothing an agent needs before calling it 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 single 'event' parameter is documented at 100% coverage in the schema, including that it accepts a URL, slug/euid, or numeric id. The description's 'resolve an event' phrasing only loosely gestures at that flexibility and adds no format or precedence detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (fetch) plus the exact resource and its returned fields: event metadata, dates, registration window, login methods, navigation menu paths. It also names the sibling it is not (list_my_events), so the agent can route without opening either schema.

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

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

Explicit sequencing guidance: 'Start here to resolve an event before calling the other event tools,' plus a named alternative for the joined-events case. That is when-to-use, when-to-use-something-else, and ordering all in one place.

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

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

Annotations already cover read-only, idempotent, non-destructive behaviour, yet the description adds a non-obvious runtime trait: the marketplace menu path is resolved automatically, with path as an escape hatch. It does not disclose failure modes (e.g. what happens if the id is from the wrong id space) or pagination/return shape, so it stops 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?

Three short sentences, all front-loaded with the action first, then the id-sourcing rule, then the override. Every clause carries operational information; nothing is boilerplate.

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 could say more about what a fetched opportunity contains, but for a simple single-object read with fully documented parameters and a clear id contract, 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 the baseline is 3, but the description adds genuine meaning the schema cannot: the opportunity_id must be a published marketplace id rather than a participation id. The path parameter's auto-resolution behaviour is restated rather than extended, keeping it below 5.

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 ("Fetch a marketplace opportunity") and immediately distinguishes itself from the sibling list_opportunities, which supplies the id. An agent can tell this is the single-object lookup that follows the listing call.

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

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

Explicitly names the prerequisite tool ("Use the id or url from list_opportunities"), warns that ids from my_participation are a different id space and will not work, and states the path override condition. That is a real when/when-not plus an alternative source, not just implied usage.

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, openWorld and non-destructive, so safety is covered. The description adds genuine behavioral context beyond them: the menu path is auto-resolved and 'path' overrides that resolution, and it defines the payload shape (organisation plus representatives). It stops short of noting failure behavior for bad ids or event resolution.

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

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

Three short sentences, each doing distinct work: identity, sibling routing, and the path pre-condition. The core description of what is returned is front-loaded before the alternatives.

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 3-parameter read tool with no output schema, the description covers purpose, siblings, and the path fallback well enough to call correctly. It could say a word about what happens when path is omitted and auto-resolution fails, but nothing essential 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%, so all three parameters are already documented including the path auto-resolution note and the origin of participation_id. The description restates the same facts (path as override, participation_id source) without adding new syntax or format detail, so it sits at the 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?

Specific verb+resource ('Fetch one organisation page') with a parenthetical defining exactly what a page contains (organisation details plus its representatives). It explicitly distinguishes itself from list_organisations and get_participant, so the agent can pick correctly 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?

Names two concrete alternatives and the condition for each: list_organisations to obtain participation ids, get_participant for a single person. This is explicit when-to-use routing rather than implied guidance.

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

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

Adds a genuinely non-obvious trait not present in the annotations: this fetch does not send B2match's profile-view tracking mutation, which materially affects side effects a caller might assume. Annotations already cover read-only/idempotent/non-destructive, and "public profile" signals field scoping, but error behavior (unknown participant_id) and rate limits are unstated.

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, no filler, with the core purpose and its unique behavioral trait front-loaded before the sibling routing guidance.

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 only two well-documented required params, no nested objects, and full annotation coverage, the definition is nearly complete; "full public profile" conveys the return shape adequately in the absence of an output schema. Minor gap: no note on what happens when the participant is not found or not visible to the caller.

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% — both `event` (URL/slug/euid/numeric id) and `participant_id` (source tools) are fully documented in the schema. The description only reinforces where ids come from, adding little beyond the existing parameter docs, 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?

Specific verb+resource: "Fetch one participant's full public profile", with an explicit scope qualifier (public profile only) and a distinguishing behavioral note about the tracking mutation. An agent can tell this apart from list_participants and my_participation without opening a schema.

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

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

Names two alternatives and the exact condition that selects each: list_participants for search/id discovery, my_participation for the caller's own status. That covers the realistic ambiguity for this tool set.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond annotations: the call returns not just details but an embedded first page of attendees, which explains why the attendees_* params exist on a 'get' tool. It stops short of describing cursor semantics for attendees_after, which is left to the schema.

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

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

Three short sentences: the output shape is front-loaded, the input rule follows, and the sibling routing comes last. Every sentence carries distinct information with no redundancy.

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

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

There is no output schema, so the description carries the burden of describing the return value, which it does ('details and a first page of attendees'). Combined with 100% schema coverage of the 5 params and full annotation coverage, an agent has what it needs. Minor gap: it doesn't say how large that first page is by default or how the cursor round-trips.

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 every parameter is already documented, including the session_id/path relationship. The description reinforces the either/or rule ('path alone is enough') but does not add format, limits, or cursor behavior beyond what the schema already states. 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 and resource ('Fetch one agenda session with its details and a first page of attendees') and makes clear this is a single-item retrieval, distinguishing it from get_agenda (which lists sessions) and list_session_attendees (which pages attendees). An agent can select this tool without opening any schema.

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

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

Explicitly names the alternatives and the conditions that select them: 'Use list_session_attendees to page through attendees only, get_agenda to find sessions.' It also states an input-selection rule ('Provide session_id, or path to a session URL; path alone is enough'), leaving nothing to inference.

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

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds real behavioral value on top: it discloses that listing does NOT mark conversations as read, and that results carry last-message previews rather than full history. It stops short of stating result ordering, preview truncation, or cursor expiry behavior.

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

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

Two sentences, no filler. The core capability and pagination come first, followed by the side-effect note and sibling routing, which is the right order.

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, three-parameter list tool with full schema coverage and rich annotations, this is nearly complete: scope, previews, pagination, side-effect and alternative are all covered. The only gap is result ordering / cursor lifetime, which an agent might want.

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 the meanings of 'event', 'first', and 'after' are already documented in the schema. The description only implies pagination ('paginated') without adding syntax or format detail beyond that 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?

States a specific verb and resource ('List ... conversations') plus scope ('logged-in viewer's') and content ('last-message previews, paginated'). It also implicitly contrasts with get_conversation, so an agent can distinguish it from the sibling that returns full message history.

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

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

Explicitly names the alternative and the condition selecting it: 'prefer it over get_conversation unless full message history is needed.' That is a direct when/when-not rule, not an inference.

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

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds genuine context beyond them: the login requirement and the fact that returned ids/slugs are reusable as the event argument elsewhere. It doesn't describe volume, ordering, or pagination of the result set.

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

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

Two short sentences, zero filler, with the core scope stated first and the alternative routing second.

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 return-value burden and does tell the agent what the ids/slugs are good for, but it omits the broader shape of each event entry and any pagination behavior. Complete enough to call correctly.

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

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

The tool takes zero parameters, so the baseline is 4; the description implicitly confirms there is no filtering input by framing it as 'events the viewer has joined'. Nothing further is needed.

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?

Specific verb (list) plus scoped resource (events the logged-in viewer has joined), and it explicitly contrasts with get_event for single public events. An agent can distinguish this from my_participation or get_event without opening any schema.

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

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

States the prerequisite (requires login) and names the alternative tool with the condition that selects it (get_event for any single public event). Routing 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?

This is exactly the behavior structured fields cannot convey: fetching the list resets the unseen counter to 0 even though the client never sends ReadNotification, while the unread counter is unchanged. The annotations (readOnlyHint=false, idempotentHint=false) are consistent with that disclosed side effect, and the description explains the gating env var. That is high-value, non-redundant disclosure.

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 short sentences, with the default behavior and the counter-reset side effect front-loaded ahead of the env-var gating. Every sentence carries functional information. The parenthetical aside about never sending ReadNotification is slightly dense on first read but justifies its place by explaining why the reset is surprising.

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 read-with-side-effect tool with no output schema, the description covers return semantics (counters vs full list), the hidden mutation, and the precondition for the full fetch. It doesn't describe pagination behavior or what fields the full notification list returns, minor gaps given the schema documents the cursor and page size.

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 the schema already documents event, first, after, and acknowledge_marks_seen, including the cap of 50 and the side-effect coupling. The description adds only a restatement of the acknowledge_marks_seen requirement, which the schema already states nearly verbatim. Baseline 3 applies since the schema does the heavy lifting.

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 behavior: it returns unread/unseen notification counters by default, and can return the full notification list under a condition. It is unambiguous about what the tool yields, though it never states the plain verb 'list notifications' and instead leads with the default mode. No sibling in the provided list overlaps with notifications, so no differentiation is needed.

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 clearly splits the two modes of use: default call gives counters only, and the full list requires B2MATCH_ALLOW_SIDE_EFFECT_READS=1 plus acknowledge_marks_seen=true. It warns of the consequence of choosing the full-list mode (unseen resets). It stops short of stating when an agent should prefer one mode over the other or what to do when the env var is unavailable.

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, openWorld and non-destructive, so the safety profile is covered. The description adds useful behavioral detail beyond that: results are paginated and the menu path is resolved automatically unless overridden. It stops short of describing response shape or rate limits, but the added context is genuine.

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 compact sentences with the core purpose front-loaded, followed by the sibling routing and path-override note. Every clause carries information an agent needs.

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 paginated read tool with full schema coverage and annotations, this is nearly complete. With no output schema, a brief note on what the paginated response contains would have closed the remaining 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 coverage is 100%, so every parameter (path, after, event, first) is already documented, including the cursor and the 50-item cap. The description only restates the path auto-resolution behavior already present in 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?

States a specific verb and resource (list published marketplace opportunities — offers/requests — of an event) plus the pagination scope. It explicitly contrasts itself with get_opportunity, so an agent can distinguish it from the detail sibling without opening either schema.

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

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

Names the alternative tool and the condition that selects it: 'Use get_opportunity for one entry's full details.' It also explains the path parameter's default behavior (auto-resolve) versus explicit override. No explicit when-not or prerequisite guidance beyond that.

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, and non-destructive; the description adds the paginated nature and the automatic menu-path resolution behavior, which is genuinely useful context beyond annotations. It does not describe the response shape, but no output schema exists so that is a minor 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?

Three short sentences, front-loaded with the primary purpose, followed by alternatives and then the notable path behavior. Zero filler.

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

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

For a read-only paginated list tool with full schema coverage and annotations covering the safety profile, the description covers purpose, alternatives, pagination, and path resolution. Nothing an agent needs 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 description coverage is 100%, so all four parameters are already documented, including the path override and pagination cursor. The description only restates the path override, adding 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?

States a specific verb (list) and resource (organisation pages/participations of an event) with scope and pagination. It explicitly distinguishes itself from get_organisation and list_participants, so an agent can pick the right tool without inspecting 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?

Explicitly names the two alternatives and the condition that selects them: get_organisation for a single page, list_participants for people. It also notes the default path-resolution behavior and when to override 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 readOnly/idempotent/non-destructive/open-world, so the burden is light; the description adds genuinely new context by announcing the compact-versus-full output tradeoff and the 'public' scope of the results. It stops short of covering pagination or truncation behavior beyond the cursor defined in the schema.

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

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

Two short sentences, zero filler, with the default behavior front-loaded before the two escalation paths. Every clause earns its place by changing how the agent would call the 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?

With no output schema, the description adequately signals the return shape (compact summaries vs full records) and the public-only scope. It could say more about page-size limits and cursor termination, but the required event parameter and filtering are fully covered by the schema.

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 all five parameters including detail and the cursor are already documented. The description restates the detail flag's effect but adds no format, default, or interaction detail beyond the schema and the -50 cap, so the baseline 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 specific verb and resource (list public participants) plus the shape of the return (compact summary), and explicitly contrasts itself with get_participant so an agent can distinguish it from the single-profile sibling without opening either schema.

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

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

Gives explicit routing: normal use for a compact list, detail=true for the fuller record, and get_participant when only one profile is needed. The alternatives and the condition that selects them are named rather than 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, idempotentHint and destructiveHint=false, so safety is covered; the description adds genuinely new behavior: results are paginated by an opaque cursor and the payload is attendee records only. It does not mention auth/permission requirements or rate limits, which keeps it from a 5.

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

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

Three short sentences, front-loaded with the core action and scope, then the sibling routing, then the addressing requirement. Every sentence carries distinct information with no filler.

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

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

For a read-only paginated list tool with full schema coverage and annotations covering the safety profile, the description covers what an agent needs to invoke it correctly. With no output schema, a hint about what an attendee record contains (fields available) would have closed the last 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%, including the 'path is an alternative to session_id' relationship, so the schema already carries the parameter meaning. The description's restatement of that either/or adds 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?

States a specific verb and resource ('Page through the attendees of one agenda session') and immediately bounds scope by saying it does not return session details, routing to get_session instead. An agent can distinguish this from get_session, get_agenda and list_participants without opening any schema.

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

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

Gives explicit routing ('use get_session for those') and prerequisite sourcing for the two addressing parameters ('session_id or path (from get_agenda)'). It stops short of naming the event-wide alternative (list_participants) or any exclusion conditions such as access prerequisites, so it is clear but not exhaustive.

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, open-world, so the safety profile is covered. The description adds real behavior beyond that: results are paginated, the set is a narrower subset of the speakers page, and path resolution happens automatically. It doesn't describe return fields, but no output schema exists and the tool is a simple list, so this is a minor 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?

Three short sentences, each earning its place: what it lists, the alternative for a broader set, and how path behaves. The core purpose is front-loaded and nothing is redundant.

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

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

For a simple paginated list tool with full schema coverage and no output schema, the description covers purpose, sibling differentiation, pagination, and path override. The only omission is any hint at what fields a speaker record contains, which is minor at this complexity.

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 all four parameters (event, path, after, first) are already documented with examples and limits. The description's note that path is auto-resolved overlaps with the schema's own wording, adding little new semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource ("List the speakers shown on the event's speakers page") plus the pagination scope. It explicitly names the sibling list_participants as the wrong tool for the general case, so an agent can tell them apart without opening either schema.

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

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

"Use list_participants for all registered participants" is an explicit when-to-use-this-instead routing rule. It also explains that the menu path is auto-resolved and that path is only for overriding, giving the agent clear guidance on the one ambiguous parameter.

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 read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: results are personalized to the logged-in viewer and ranked as 'recommended and newest', which tells the agent the output is opinionated rather than a plain listing. It stops short of describing result volume or pagination.

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, no waste, with the core purpose front-loaded before the sibling routing. 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?

No output schema exists, but the description conveys the essence of the return ('recommended and newest participants'), which is enough to know what comes back. It doesn't say whether the list is bounded or paginated, a minor gap for a single-parameter read tool whose annotations already cover safety.

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?

Only one parameter ('event') and schema description coverage is 100%, with accepted formats (URL, slug/euid, numeric id) already documented in the schema. The description adds no parameter detail, 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?

States a specific verb (fetch) and a precisely scoped resource: recommended and newest participants for the logged-in viewer. The viewer-scoping and the recommendation ordering distinguish it clearly from list_participants without needing to open either schema.

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

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

Explicitly routes the agent: use list_participants to search all participants, find_meeting_slots to check shared free time. This names the alternatives and the tasks they cover, so an agent knows which tool to reach for.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the important behavioral detail about what is returned by default (merged free ranges per day) versus the full grid with detail=true. It could say more about authentication/event-scoping requirements, but the 'logged-in viewer' framing covers the essentials.

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 purpose and immediately followed by mode behavior and the alternative tool. Every sentence 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?

No output schema exists, but the description adequately explains what the tool returns in each mode (merged free ranges per day vs. full timeslot grid). For a read-only tool with two fully documented parameters and complete annotations, nothing an agent needs 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 description coverage is 100%, so the schema already documents both 'event' and 'detail'. The description restates the effect of detail=true but adds no syntax or format guidance beyond the schema, which is the expected 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?

States a specific verb and resource ('Fetch the logged-in viewer's own meeting availability') with the scope of self clearly stated. It is distinguishable from siblings like find_meeting_slots without opening either schema.

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

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

Explicitly names the alternative tool ('Use find_meeting_slots for slots shared with specific participants') and gives the condition that selects it. It also explains the default mode vs. the detail=true mode, leaving no routing ambiguity.

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 read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds real behavioral value the annotations don't: unfiltered responses include a compact availability summary (merged free ranges per day) unless detail=true. It stops short of describing result volume, pagination, or what a single meeting record contains.

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

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

Three front-loaded sentences: capability and scoping first, output-mode caveat second, sibling routing last. No redundant restatement of annotations or the enum values.

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 three simple params and no output schema, the description covers the essentials: required event context is implied by the domain, the status bucket behavior and the summary-vs-grid switch are explained. Missing is any sense of return volume/pagination or the fields of a meeting or request entry, which matters more given no output schema.

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 the baseline is 3, but the description goes further by tying parameters to output shape — unfiltered (status omitted) yields an availability summary, and detail=true swaps to the full grid. That cross-parameter behavior is not obvious from the per-field schema text alone.

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

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

States a specific verb and resource (fetch the viewer's meetings and meeting requests) plus a scoping note (optionally one status bucket). It is clearly distinguishable from my_schedule and find_meeting_slots, which are named as different tools for different jobs.

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

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

Explicitly routes the agent to alternatives with conditions: my_schedule for the overall timetable, find_meeting_slots for finding free times with others. That leaves meetings/meeting-requests retrieval as this tool's clear niche.

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 openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: the scope is bound to the authenticated viewer and a single event, and it enumerates the categories of data returned, which is valuable given there is no output schema. It stops short of describing error states or what an empty/non-participant response looks like.

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 identity/scope of the call is front-loaded and the disambiguation against the sibling follows immediately. 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?

For a single-parameter read tool with full annotation coverage, the description is nearly complete: it defines who the data belongs to, which event, and what fields come back, compensating for the absent output schema. The only gap is the failure/edge path (non-participant, invalid event reference), which an agent would likely need.

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 `event` parameter already documents accepted forms (URL, slug/euid, numeric id), so the description need not repeat it. The phrase "for one event" confirms cardinality (single, not list) but adds no format or validation detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 (fetch) and a precisely enumerated resource set (participant status, activation, permissions, organisation pages, opportunities) scoped to the logged-in viewer and one event. It also names the sibling it is not, get_participant, calling out that the sibling returns someone else's public profile, so an agent can route without opening either schema.

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

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

"Fetch the logged-in viewer's own..." establishes the selecting condition (self vs. others) and the second sentence names the alternative explicitly with its distinguishing trait. What is missing is any note on prerequisites (e.g. must be authenticated/registered for the event) or what happens when the viewer is not a participant.

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, openWorld, non-destructive, so the safety profile is covered. The description adds a real behavioral detail beyond them: the PDF agenda URL is conditionally omitted unless include_pdf_link is true, which tells the agent why a field may be absent. It does not describe pagination or the full return shape, keeping it 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?

Three tight sentences with zero filler; the core purpose and scope come first, then sibling routing, then the one conditional output nuance. Every sentence 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?

For a 2-parameter read tool with full annotation coverage and no output schema, the description covers purpose, alternatives, and the one surprising output condition. Only minor gaps remain (e.g., what happens if the viewer has no schedule, or whether registration is required), which are unlikely to block correct invocation.

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 both the event identifier format and the include_pdf_link flag are already documented. The description only restates the include_pdf_link behavior rather than adding constraints such as accepted slug/euid forms or defaults. Baseline 3 is appropriate when the schema carries the parameter detail.

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 ('Fetch the logged-in viewer's personal event schedule') plus the concrete contents (booked sessions and meetings). It names the siblings it is not — get_agenda and my_meetings — so an agent can distinguish it without opening any schema.

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

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

Explicitly routes the agent: use get_agenda for the full public agenda, use my_meetings for meeting requests by status, use this for the personal schedule. Each alternative comes with the condition that selects it.

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