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

The description goes well beyond the annotations by disclosing side effects: completion time is recorded, progress is set to 100%, reopening clears both, and the previous state is preserved in the entry. It also explains the reversible nature and why no confirmation prompt is shown. This is rich behavioral context without any contradiction of annotations.

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 three purposeful sentences with no filler. It front-loads the core action, then explains side effects and reversibility, with every sentence earning its place. The format is easy to parse quickly.

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 tool with a full input schema and an output schema, the description covers the essential behavioral details: what changes, what is cleared, reversibility, and the lack of confirmation. No important calling context 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 score is at baseline. The description does not significantly elaborate on the parameters beyond what the schema already states, but it does reinforce the done/reopen semantics that map to the 'done' boolean. This is adequate given the schema's completeness.

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 title and description both state a specific verb and resource: marking a task done or reopening it. The description adds concrete behavioral detail—recording completion time, setting to 100%, clearing on reopen—so the tool's exact function is unmistakable.

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 indicates when to use this tool: to complete a task or to reopen a completed task. It does not explicitly discuss alternatives like update_task or when not to use it, but the specialized purpose is clear enough for an agent to select it appropriately.

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 description discloses non-obvious behaviors beyond the annotations: the UID and file name are generated server-side, making accidental overwrites impossible, and offset-less times fall back to the timezone argument or CALDAV_TIMEZONE. These details add useful context and do not contradict the annotations.

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

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

Two sentences, front-loaded with the core action and followed by the two most important behavioral caveats. There is no filler or redundant restating of the title.

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

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

This is a complex 12-parameter tool, but the schema covers parameter semantics in detail and an output schema exists. The description supplies the critical create-versus-update safety guarantee and timezone interpretation, which is sufficient for an agent to select and invoke the 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 92%, so the baseline is 3. The description's timezone sentence mostly restates what the timezone property already says; it does not add meaningful parameter-level semantics beyond the schema.

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

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

The description opens with a specific action, 'Adds an event to a calendar', and clearly states this is creating a new entry. The mention that the UID and file name are generated here, so an existing entry can never be overwritten by accident, distinguishes it from update_event and move_event.

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

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

Usage is only implied through the verb 'Adds'; there is no explicit guidance such as 'to modify an existing event, use update_event' or 'obtain calendar_id from list_calendars first'. The description hints at why to choose create over update, but it does not name alternatives 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?

Annotations already convey that this is not read-only, not idempotent, and not destructive. The description adds a meaningful behavioral constraint: only calendars that accept journal entries can be used, and list_calendars is the way to identify them. It does not contradict any annotation.

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 with no filler. The primary action is front-loaded, and the second sentence provides essential routing guidance without repeating schema or annotation 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?

Given a fully documented input schema, an output schema, and explicit guidance about which calendars support journal entries, the description is complete enough for an agent to call the tool correctly. Nothing needed for selection or invocation is missing.

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

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

Schema description coverage is 100%, and the schema richly documents all six parameters including calendar_id, date, summary, timezone, categories, and description. The tool description adds no parameter-level meaning beyond referring to a 'dated note', 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?

The description uses a specific verb ('adds') and names a distinct resource ('a dated note' / journal entry) rather than repeating the tool title. It also restricts the operation to calendars that accept journal entries, which clearly separates it from calendar/event tools like create_event.

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

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

It tells the agent how to find an appropriate target by pointing to list_calendars ('list_calendars reports which do'). It does not explicitly name alternatives like update_journal or create_event, but the journal-specific wording provides enough context for typical use.

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 description reveals a notable behavioral trait beyond the annotations: the server pre-checks task support and returns its own refusal instead of passing the backend's error back to the caller. This is non-obvious and helps the agent interpret failures correctly. It does not contradict the annotations, which already indicate a mutating, non-idempotent operation.

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 deliver the core action and the one important exception without repeating schema or annotation content. Every clause contributes useful information, and the key action is front-loaded.

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 a rich input schema, an output schema, and annotations covering idempotency and mutation, the description only needs to supply context not available elsewhere. It supplies the critical calendar-acceptance prerequisite and the pre-check behavior. Nothing necessary for selecting and invoking the tool 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 detailed parameter descriptions in the input schema carry the semantic load. The tool description adds no parameter-specific meaning beyond mentioning list_calendars, which the calendar_id parameter already references.

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

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

The description names the exact operation ('Adds a task to a calendar'), the target resource (a task), and the qualifying condition (the calendar must accept tasks, as reported by list_calendars). This clearly distinguishes it from sibling creation tools like create_event and create_journal by the object type being created.

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 concrete usage context: consult list_calendars to find a calendar that accepts tasks, and warns that event-only collections will refuse a task. It effectively provides a when-not condition for invalid targets, though it does not explicitly compare against alternative creation 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?

It discloses important non-obvious side effects: deleting an occurrence adds an exception date rather than physically removing it from the series, and CalDAV keeps no history, so deletion cannot be undone. This adds meaningful behavioral context beyond the destructiveHint and idempotentHint annotations.

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 tightly worded sentences: the core action, the occurrence-vs-series distinction, and the irreversibility warning. No filler or repetition; 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?

Given the annotations (destructive, idempotent, non-read-only), full parameter descriptions, and an output schema, the description covers the essential behavioral aspects and irreversibility. The confirmation flow for series deletion is not described here but is present in the schema, so the overall context is sufficient.

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?

With 100% schema description coverage, the schema already documents all parameters. The description adds value by clarifying that an occurrence id removes just that occurrence while a series id removes the entire entry, which is not fully evident from the schema alone.

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

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

The description opens with 'Removes an event,' a specific verb and resource, and then distinguishes occurrence vs. series deletion, making its purpose unmistakable. It clearly differentiates this from sibling tools like delete_task and delete_journal by targeting event semantics.

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 clear context for deleting a single occurrence versus an entire series, including the iCalendar exception-date behavior for occurrences. However, it does not explicitly name alternatives such as respond_to_event or update_event for cancellation scenarios, so it stops short of full exclusion guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the core write behavior is known. The description adds genuinely useful context beyond the annotations: a CalDAV server keeps no history, deletion is irreversible, and the note represents someone's writing. This aligns with the annotations and deepens the agent's understanding of consequences.

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 crisp sentences with no filler. The action is front-loaded, and the consequence is stated immediately. Every word contributes to either purpose or behavioral risk.

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 combination of a complete input schema, an output schema, and annotations covers the mechanical requirements for calling the tool. The description supplies the essential non-schema context: the irrevocable nature of the deletion. It is sufficient for an agent to invoke the tool correctly, though it could have briefly mentioned the two-step confirm_token workflow.

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 schema already provides clear semantics for both parameters: id must come from a listing tool, and confirm_token comes from the first call of this tool. The description itself adds no additional parameter-level meaning, so the baseline score of 3 applies.

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

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

The description clearly identifies the action ('Removes') and the resource ('a dated note'), which maps cleanly to a journal entry and distinguishes it from event or task deletion. It does not explicitly differentiate from sibling delete tools by name, but the resource wording is specific enough for practical selection.

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 such as delete_event or delete_task, nor does it state conditions or prerequisites. The irreversibility warning implies caution, but it does not actually help route an agent to the correct delete tool.

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 provide destructiveHint=true and idempotentHint=true, and the description adds the meaningful irreversible context: 'A CalDAV server keeps no history: this cannot be undone.' It does not contradict the annotations, though it does not explain the two-step confirm_token flow implied by 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 with zero waste. The action is front-loaded, and the second sentence packs both an important consequence and an alternative tool reference.

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?

Annotations and output schema cover destructive/idempotent behavior and return values. However, the confirm_token parameter strongly implies a confirmation workflow, and the description never tells the agent to call once for a token and then call again to confirm deletion, leaving a notable usage gap.

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

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

Schema description coverage is 100%, so the baseline is 3 and the description is not required to restate parameter meaning. The description adds no parameter-specific detail, but the schema already documents id and confirm_token clearly.

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 'Removes a task' – a specific verb and resource, leaving no doubt about the operation. It also distinguishes itself from complete_task, preventing confusion with the most similar sibling.

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

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

Explicitly states the intended purpose and gives a clear when-not alternative: 'To mark a task done instead, use complete_task.' This is direct routing guidance versus the main competing sibling.

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 behavior, so the description is free to add value. It explains the distinction between occurrence ids (return one instance) and series ids (return the series and its rule), which is critical behavioral context not available elsewhere.

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 provide high-value information without filler. The core purpose is stated first, followed by the important occurrence/series behavior, with no redundant elaboration.

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 single parameter, strong annotations, and presence of an output schema, the description is complete. It captures what the response contains, the id-sourcing expectation, and the distinction between occurrence and series ids, leaving no critical gap for an agent 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 description coverage is 100%, and the parameter description already says the id comes from a listing tool and should not be hand-built. The tool description reinforces this and adds the occurrence-vs-series behavior tied to the id type, going beyond the schema.

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

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

The description uses a specific verb ('read') with a clear resource ('one event') and explicitly states the full scope: untruncated description, reminders, attendees, and attachment metadata. This clearly distinguishes it from listing tools like list_events and search_events, which return truncated or filtered views.

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 indicates the tool should be used with an id obtained from a listing tool, implying the appropriate context of use after listing/searching. It does not explicitly name alternatives like get_journal or get_task, but the event-specific focus and id provenance instruction provide sufficient 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?

Beyond the annotations, the description adds meaningful behavioral context: the response contains only start/end times, no titles or attendees, and notably 'nothing anybody else wrote comes back, so there is no untrusted content in the answer at all.' This explains privacy and content-filtering behavior that annotations do not cover.

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 front-loaded sentences with no wasted words. The core behavior is stated first, followed by the differentiating use-case rationale. Every phrase 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?

Given the rich annotations, complete input schema, and the presence of an output schema, the description adds the needed selection-level context: what the tool returns, what it omits, and why it is safe to use for free/busy checks. Nothing essential for correct selection or invocation is missing.

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

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

Schema description coverage is 100%, so the parameters are fully documented in the schema. The tool description adds no additional parameter-level meaning, which aligns with the baseline of 3.

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

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

The description clearly states that the tool returns busy periods in a time range, with the specific behavioral scoping of 'start and end only'. It differentiates itself from sibling calendar tools by emphasizing that no titles or attendees are returned, making its purpose distinct from list_events, search_events, and get_event.

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 frames when to use the tool: 'when am I free' and when a data-sparing, untrusted-content-free answer is desired. It implies exclusion of use cases needing titles or attendees, but does not explicitly name an alternative sibling tool for those cases.

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

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

Beyond the readOnly/idempotent/destructive annotations, the description warns that the response is the longest prose the server returns and that it is carried inside an explicit untrusted fence. This adds meaningful security and size context that annotations do not provide.

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

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

Two sentences with no filler: the first front-loads the tool's purpose and source, and the second adds a relevant behavioral caveat. Every clause contributes 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 one-parameter read operation with an output schema available, the description covers where the id comes from, what is returned (untruncated full note), and an important trust boundary. No essential calling context is missing.

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

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

Schema coverage is 100% and already describes the id as from a listing tool and not hand-built. The description adds specificity by naming list_journals as the origin of the id, reinforcing the intended source beyond the schema.

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

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

The description states a specific operation (get the complete note for an id) and names the exact source tool (list_journals), distinguishing it from sibling tools like get_event and the journal mutation tools. 'Untruncated' clarifies that the result is the full entry, not a list row.

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 clearly indicates the id comes from list_journals, which tells an agent to obtain an id from the listing tool before calling this one. It does not explicitly name alternatives or say when not to use it, but for a simple single-parameter read, the context is sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by explaining exactly what the server reports and why it is useful for diagnosing differences in CalDAV implementations, which goes beyond what annotations convey.

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 with no filler. The first sentence lists the concrete outputs, and the second gives the diagnostic use case, making the purpose immediately apparent. Every phrase 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 zero-parameter, read-only capability probe with an output schema and safety annotations, the description is fully complete. It states what the tool reports, why it matters, and when to run it. 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?

The tool has zero parameters and schema description coverage is 100%, so there is no parameter burden for the description. Baseline 4 is appropriate here; the description correctly focuses on behavior and outputs rather than parameters.

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

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

The description names a specific verb ('Reports') and a concrete resource: the connected CalDAV server's capabilities, compliance tokens, accepted components, and optional feature availability. It clearly distinguishes itself from the sibling CRUD/search tools by focusing on server-level capability discovery rather than individual calendar objects.

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 explicit situational guidance: 'The first thing to run when something behaves differently than expected.' This tells the agent when to invoke this tool. It does not enumerate sibling alternatives or say when not to use it, but for a zero-parameter diagnostic tool, this is sufficiently clear context.

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 non-destructive behavior, so the description's main addition is the guarantee of an untruncated description and every reminder. This adds meaningful behavioral context beyond the schema and annotations, though it does not discuss error cases or auth requirements, which are not essential for a read-only single-fetch tool.

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, no filler, and the key differentiator ('complete task') is front-loaded. Every word contributes meaning, making it easy for an agent to parse quickly.

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 tool with a single parameter, a rich output schema, and annotations covering safety, the description is complete. It tells the agent what the tool returns and how to obtain the id, and the output schema handles return-value details. No critical information is missing.

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

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

The schema fully documents the id parameter with 'An id from a listing tool. Not meant to be built by hand.' The description reinforces this by saying 'behind an id from list_tasks,' narrowing the source to the specific sibling tool, which adds slight semantic value. Overall the schema covers the parameter well, and the description does not contradict it.

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

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

The description states precisely what the tool returns: the complete task for a given id from list_tasks, including the untruncated description and all reminders. This clearly distinguishes it from list_tasks (which presumably returns truncated summaries) and from sibling tools like get_event or get_journal that fetch other entity types.

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

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

The description implies when to use this tool: after obtaining an id from list_tasks and needing full detail beyond what the list provides. It does not explicitly state exclusions or compare to all alternatives, but the contrast with list_tasks is evident, and the tool name 'get_task' plus title 'Read one task in full' reinforces the usage context.

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 behavior, so the description does not need to restate safety. It adds meaningful behavioral context by explaining the tool intentionally bypasses caching to ensure current data, which is useful beyond the structured annotations.

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 two concise sentences with no filler. It leads with the core purpose and returned value, then adds the freshness behavior as a distinctive trait—every sentence contributes.

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, read-only list tool with an output schema, the description covers what the tool returns, why it matters, and its key behavioral guarantee. No essential guidance is missing.

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

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

The tool has zero parameters, so there are no parameter semantics to clarify. The mention that returned ids are passed to other tools adds helpful output-oriented context, and the empty schema leaves nothing ambiguous.

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

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

The description states a specific verb and resource: it lists every calendar the server may use and notes the returned ids are meant for other tools. This distinguishes list_calendars from sibling list tools like list_events and list_journals, which target different resources.

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 indicates this tool should be used to obtain calendar ids for other tools and emphasizes freshness by always querying the server rather than a cache. It gives clear context for when to use it, though it does not explicitly name excluded alternatives or when-not-to-use conditions.

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

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

Beyond the read-only and idempotent annotations, the description discloses important behavior: recurring events are expanded into individual occurrences with independent ids, the default window is the next 30 days, and the source can be all visible calendars or named ones. This adds meaningful operational context.

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

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

Three concise sentences, each earning its place: the core behavior, the notable recurring-event expansion, and the default time window. Information is front-loaded and there is 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?

Given the rich input schema, present output schema, and strong annotations, the description covers the key behavioral aspects an agent needs. Pagination and timezone details are left to the schema, which is acceptable, though a brief mention of cursor continuation could have been helpful.

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 input schema provides 100% parameter descriptions, so the baseline is 3. The description adds general context about time ranges and calendar scoping, but does not add per-parameter details beyond what the schema already explains.

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 the tool lists events in a time range, with an explicit scope ('every calendar this server may see or from the ones named'). It is easily distinguishable from single-event tools like get_event, though it does not explicitly differentiate itself from search_events.

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

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

The description implies when to use the tool: listing events over a window, especially with recurring occurrences expanded. However, it provides no explicit guidance about when to prefer search_events or get_event, and gives no exclusions or alternative conditions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safe read profile. The description adds time-range scoping and explains that journal entries live alongside events/tasks, but it does not describe pagination, calendar filtering, or other call 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?

The description is short and readable at roughly 36 words with no filler. The opening sentence is an awkward fragment and would be clearer with an explicit verb, which keeps it from 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?

With full schema coverage and an output schema present, the description need not document parameters or returns. It provides useful domain context and time-range scoping, but misses an explicit action statement and any usage boundary relative to list_events, making it adequate but not comprehensive.

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%, with all six parameters individually documented. The description contributes no parameter-level detail, so the baseline of 3 applies because 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 is a noun phrase defining what journal entries are, not a statement of what the tool does. The title supplies the verb 'List', and the mention of events/tasks gives some sibling context, but the purpose is not crisply stated as an action.

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 instead of siblings like list_events or get_journal. The CalDAV/diary context hints at the domain but does not state conditions, exclusions, or alternatives.

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 provide the read-only, idempotent, non-destructive safety profile. The description adds a genuinely non-obvious behavioral detail: tasks without dates do not match a time-range query because of CalDAV filter semantics. This prevents a realistic and costly misunderstanding.

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 with no wasted words. The core purpose is front-loaded, and the second sentence earns its place by explaining an important edge case with a brief rationale.

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 a complete input schema, an output schema, and rich annotations, the description covers exactly the additional semantic context an agent needs. The date-filtering behavior and no-date exclusion are explained, while pagination, defaults, and formatting are already documented in the schema. 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 the baseline is 3. The description adds meaning beyond the schema by explaining that the time range applies to start or due dates, which the individual parameter descriptions do not state. It appropriately does not repeat the schema's per-parameter details.

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 defines a list operation over tasks, scoped to tasks with a start or due date inside a time range. This distinguishes it from list_events, list_journals, and the single-item get_task. It also states a clear exclusion: tasks with no date are never returned.

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

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

The description implies this is the tool for time-range queries over tasks, but it does not explicitly state when to use it versus sibling tools such as get_task or list_events. No alternatives or when-not-to-use guidance is provided. The intended usage is inferable but not spelled out.

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 already mark the tool as destructive, and the description adds valuable detail beyond that: all IDs referencing the event stop working, a listing is needed to get the new ID, and the destination calendar may be visible to others. It does not explain the confirm_token confirmation flow, so it is not a perfect 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?

The description is three sentences with no filler. The core behavior is front-loaded, and the identity-invalidation consequence is stated economically and clearly.

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 destructive mutation, the description covers the most important consequences: the original event ID stops working, a new ID must be found via listing, and the destination may expose the event to other viewers. The confirm_token workflow is only hinted at through the schema, which is the main 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?

The input schema already describes all three parameters with 100% coverage, including that id must come from a listing tool and that destination_calendar_id accepts a path, URL, or final path segment. The description adds only the visibility caveat about the destination calendar, which does not meaningfully raise it above the high-coverage baseline.

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

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

The description opens with a specific action on a specific resource: 'Copies an event into another calendar and removes it from the first.' This precisely defines move as copy-plus-delete and clearly separates it from siblings like create_event, update_event, and delete_event.

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 clear context for when to use the tool: moving an event to another calendar, including to a calendar other people can see. It does not explicitly name alternatives or say when not to use it, but the copy-and-remove semantics make the intended use 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?

Discloses important behavior that annotations do not capture: an unsendable reply to the organizer, a confirmation step before sending, scope limited to the caller's own attendee line, and a server-level constraint on attendee manipulation. This goes well beyond readOnlyHint/destructiveHint/idempotentHint and helps the agent predict side effects.

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 concise sentences, each serving a purpose: the primary action, the irreversible side effect and confirmation behavior, the scope boundary, and a relevant server limitation. The most important information is front-loaded and there is no redundant or promotional language.

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 output schema exists, return values need not be explained. The description covers purpose, side effects, scope, confirmation behavior, and a server constraint. The only subtlety, the confirm_token flow, is already described sufficiently in the schema as 'Token from the first call of this tool.'

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

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

The input schema has 100% parameter description coverage, so the baseline is 3. The description adds little direct parameter-level meaning beyond the schema, though 'so it asks first' helps contextualize confirm_token. This is acceptable because the schema already documents id and confirm_token clearly.

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 action ('Sets your own participation status on an event'), names the resource type, and clearly distinguishes itself from attendee management tools by saying it never modifies anyone else's attendee line and that this server cannot add or remove attendees at all. The title 'Accept or decline an invitation' reinforces the 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?

Clearly establishes when to use the tool: for the caller's own response to an invitation. It also gives an explicit when-not by stating it does not affect other attendees and cannot add or remove attendees. It does not name a specific sibling alternative tool, but it gives enough context to avoid misuse.

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

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

Annotations already declare the operation read-only and idempotent. The description adds meaningful behavior beyond that: it discloses one request per field and per calendar, and explains the AND combination semantics for multiple fields — a non-obvious correctness and cost trait. No contradiction with annotations.

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

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

Two tight sentences: the first establishes purpose and scope, the second delivers the critical caveat about server-side execution and AND semantics. No filler; every clause adds decision-relevant information.

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

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

With annotations covering safety, full parameter documentation in the schema, and an output schema present, the description only needs to clarify the non-obvious matching semantics, which it does. Nothing an agent needs for correct invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds essential meaning for the fields parameter by explaining that multiple fields are ANDed, preventing the natural assumption of OR matching across summary, description, and location. It also highlights how fields and calendars multiply server requests.

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: 'Finds events whose summary, description or location contains a term.' This clearly conveys text-search behavior and the searchable fields, which distinguishes it from list_events and other retrieval siblings without needing to inspect the 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?

The description implies the tool is for text-based event search, but it does not explicitly state when to prefer it over list_events or name alternatives/exclusions. The AND-semantics caveat is useful parameter guidance but does not address tool-selection context.

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

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

Beyond the annotations, it discloses preservation of unmodeled properties, null-to-clear semantics, ETag-based optimistic concurrency with a failure response, and a confirmation flow for series changes. These are material behaviors an agent cannot infer from readOnly/destructive/idempotent hints alone.

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

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

Four dense sentences, each carrying a separate essential behavior: partial update scope, null semantics, ETag guard, and series confirmation. The primary behavior is front-loaded, and there is 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 13-parameter mutation with output schema and annotations, the description plus schema covers all operational essentials: update semantics, concurrency, clearing, and recurring-series confirmation. The output schema and property descriptions fill the remaining 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 coverage is already high (85%), but the description adds the critical distinction between omitting a field (leave unchanged) and passing null (clear it), which is not uniformly stated in the schema. The schema handles per-parameter details; the description supplies the cross-cutting rule.

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

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

The description names a specific verb and resource ('Changes the fields' of an event) and immediately clarifies the partial-update scope ('leaves everything else exactly as it was'). This distinguishes it from creation/deletion tools and from other sibling event 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?

The description implies its use for modifying an existing event (fields named, recurrence scope, ETag guard), but it never names an alternative or an exclusion such as 'for full deletion use delete_event'. Usage is inferred rather than explicitly routed.

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 mark destructiveHint=true and idempotentHint=true, and the description adds substantial detail: the CalDAV server keeps no version history, previous text is permanently lost once the update succeeds, and an ETag guard prevents silently overwriting concurrent changes. This explains exactly what gets destroyed and how consistency is protected.

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 focused sentences: the core behavior first, then the destructive consequence, then the concurrency guard. No filler and each sentence covers a distinct, essential point.

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 destructive partial-update tool, the description covers the key operational facts: which fields are replaced, how to clear a field, the permanence of the change, and the ETag-based concurrency protection. An output schema exists and the parameter schema fully documents each field, so no critical information is missing.

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

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

The schema provides 100% description coverage for all six parameters, so the baseline is 3. The description adds a useful general rule—partial updates, null clears—that applies across parameters and complements the schema without repeating it. It does not add syntax details beyond the schema.

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

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

The opening phrase 'Replaces the fields named' states a specific action and resource, clearly conveying this updates an existing journal entry rather than creating or deleting one. The title 'Change a journal entry' reinforces this and distinguishes it from sibling tools like create_journal, update_event, and update_task.

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

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

The description gives practical parameter guidance ('pass only the fields to change, and pass null to clear one') but does not explicitly state when to choose this tool over alternatives such as create_journal, delete_journal, or get_journal. The intended usage is implied by context rather than clearly spelled out.

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

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

Beyond the annotations, the description discloses that null is used to clear fields, that the operation is guarded by the entry's ETag, and that it preserves unspecified fields. These are meaningful behavioral traits not present in the annotations or schema. The description does not contradict the annotations; readOnlyHint=false, destructiveHint=true, and idempotentHint=true are all consistent with a patch-style update.

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, each carrying distinct information: partial-update semantics, null clearing, ETag guard, and the routing to complete_task. There is no filler or repetition. The structure is front-loaded with the core behavior and follows with edge-case semantics and the sibling alternative.

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 output schema exists and annotations cover safety, the description conveys everything essential for correct invocation: what changes, what stays, how to clear fields, concurrency protection, and when to choose a sibling. It does leave the ETag supply mechanism unspecified, but this is likely a header-level concern not required in the tool description. Overall the description is complete for a 10-parameter tool with a partial-update model.

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 80%, so the baseline is 3. The description adds a general 'Pass null to clear a field' rule, but this is already documented for the nullable fields (categories, description) in the schema. It does not illuminate the two undocumented parameters, priority and percent_complete, and could be slightly misleading since several fields do not accept null. No meaningful additional parameter semantics beyond the schema are provided.

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 and resource: 'Changes the fields named', which clearly identifies a partial-update operation on a task. It also distinguishes itself from the sibling complete_task by explicitly saying that marking a task done should use that tool instead. This makes the tool's purpose unambiguous and separable from siblings at a glance.

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 an explicit alternative and the condition that selects it: 'To mark a task done use complete_task, which records the completion time as well.' This directly answers the most likely ambiguity with sibling tools. The phrase 'leaves everything else as it was' also tells the agent this is a targeted patch, not a full replace or creation operation.

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