Wellness Cycle Coach

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds the content inventory of the returned manifest, which is useful context, but it does not disclose additional behavioral traits such as filtering by client, output shape, or any side effects beyond the annotation coverage.

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

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

The description is a single, efficient sentence that front-loads the verb and resource before listing the manifest's contents. Every item in the list adds information, and there is no filler or repetition.

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, read-only, zero-required-parameter tool, the description covers the main facets of what is returned. The absence of an output schema makes the content list especially valuable, and the annotations cover safety. It could mention how the client parameter affects the manifest, but that is a minor gap given the tool's simplicity.

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

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

Schema description coverage is only 50%, and the description does not explain either parameter. The client parameter has no description beyond its enum values, and privacy_mode's schema description is not reinforced or expanded by the tool description. Since the description fails to compensate for the low schema coverage, parameter meaning is under-specified.

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 ('Returns') and names the exact resource (wellness-cycle-coach agent manifest), then enumerates its contents: tool list, supported clients, env vars, recommended first calls, capabilities, privacy posture, and community links. It is clear, though it does not explicitly distinguish itself from the overlapping sibling cycle_capabilities, which is also about capabilities.

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 purpose implies usage: call this tool when you need the agent manifest or recommended first calls. However, there is no explicit guidance about when to choose this over siblings like cycle_capabilities or cycle_quickstart, and no exclusions are stated. The usage context is implied rather than stated.

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 safety. The description adds context about the content (phases, connectors, metrics, privacy modes) but does not reveal additional behavioral traits such as pagination, response size, or latency. Since safety is covered by annotations and the description provides some semantic context, a 3 is appropriate.

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

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

A single, front-loaded sentence that lists all content categories without filler. Every word earns its place, and the primary action 'Lists' is immediately clear.

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

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

For a simple, read-only capabilities listing with one optional parameter, the description is adequately complete. It names the returned categories and implies no side effects. While no output schema exists, the tool's nature is straightforward; the description does not need to detail return formatting. Slight deduction for not mentioning potential variations based on privacy_mode, but the schema covers that.

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%: the only parameter 'privacy_mode' has a detailed description including enum values and effects. The description mentions 'privacy modes' but adds no syntax or formatting details beyond what the schema already states. Baseline 3 is correct when the schema fully documents 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 uses a specific verb 'Lists' and enumerates exact resource categories (supported phases, upstream connectors, available metrics, privacy modes). This clearly distinguishes it from sibling tools like cycle_agent_manifest or cycle_connection_status, which focus on different facets. An agent can immediately understand the tool's scope without ambiguity.

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

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

No guidance is provided on when to use this tool versus alternatives. With 16 sibling tools, the absence of explicit routing criteria (e.g., 'Use this to discover available options before calling specific tools') leaves the agent to infer usage. The description states what it lists but not when to invoke 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 read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond those flags by disclosing that the MCP is stateless and that cycle data must be passed in via tool arguments, which helps the agent interpret what this call can and cannot do.

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

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

The description is a single, front-loaded sentence: it states the core purpose first and then adds the statelessness note. Every clause earns its place, with no repetition of annotations or schema content.

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

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

For a zero-required-parameter liveness check with rich annotations and a fully documented optional parameter, the description is nearly complete: purpose, behavior, and statelessness are all present. It could be more explicit about exact return shape, but no output schema exists and 'reports' sufficiently signals the response nature.

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 privacy_mode fully documented via its enum and description, so the baseline of 3 applies. The tool description adds no parameter-specific detail, and its general statelessness remark does not clarify the privacy_mode parameter.

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 concrete verb and target: it 'reports the coach is alive,' clearly marking this as a liveness/connection check. This is unmistakably distinct from the sibling tools, which are data/guidance operations, and the title reinforces the same 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?

The description implies the tool should be used to verify that the coach is alive, and it adds a useful statelessness reminder about passing cycle data via args. However, it never explicitly states when to use this tool versus alternatives or when not to use it, so routing guidance is only implied.

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, so the safety profile is covered. The description adds that the result is a reference catalog/taxonomy rather than user-specific data, but it does not describe response shape, ordering, or how privacy_mode affects the payload beyond the schema text.

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

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

The description is a single front-loaded sentence with no filler or repetition. Every phrase ('metric catalog', 'phase taxonomy', 'used by the coach') contributes to the agent's understanding.

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 zero-required-parameter, read-only inventory tool, the description conveys the essential output. Without an output schema it could name more of the returned structure, but the generous annotations and fully documented single parameter make this adequate for 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?

The only parameter, privacy_mode, is fully described in the schema with an enum and explanation of summary vs. structured/raw behavior (100% coverage). The description adds no parameter-specific detail, so the baseline of 3 applies because the schema carries the semantic weight.

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 ('Returns') and identifies distinct resources ('metric catalog and phase taxonomy'), so an agent knows exactly what data the tool provides. It does not explicitly compare against sibling tools like cycle_capabilities or cycle_full_report, but the catalog/taxonomy wording is specific enough to orient the agent.

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

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

The description gives no guidance on when to call this tool versus the many sibling cycle_* tools. There are no exclusions, prerequisites, or alternative tool names; the agent must infer from the tool name and 'used by the coach' when this is the right choice.

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 safety. The description adds that it returns sample data, which sets expectations about the payload being fake. No contradiction, but no further behavioral detail like side effects or required auth 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 redundant wording. The first sentence states what it does; the second explains when to use it. Information is front-loaded and directly useful.

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 demo tool with one optional parameter and no output schema, the description sufficiently covers the purpose, the nature of the return value (example), and the intended usage. Nothing critical is missing.

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

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

Schema description coverage is 100% and the single parameter privacy_mode is fully documented with an enum and description. The tool description adds no additional semantic context, 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?

The description states a specific verb ('Returns') with a clear resource ('realistic example payload') and explicitly relates it to cycle_full_report, distinguishing it from that sibling. An agent immediately understands this is a demo/preview 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?

The description provides a clear instruction: 'Use to help agents understand the contract before a real call.' This establishes when to use it, though it does not explicitly mention alternatives or when not to use it.

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

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

The description goes well beyond the readOnly/idempotent annotations by explaining nuanced behaviors: late_luteal sub-phase triggers, days_past_due, delay_flag thresholds, cycle_irregular modes, confidence capping, and clinician-defer warnings. This gives an agent strong expectations of how the tool behaves in different situations.

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 core purpose is front-loaded in the first sentence, and the version-specific details are organized with code-formatted field names. The description is somewhat long due to changelog-style additions, but each part conveys meaningful behavioral context rather than 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?

With no output schema, the description enumerates the primary return fields and important edge cases (late luteal, irregular mode, delay flag). It is sufficient for invoking the tool correctly, though it leaves some details like the exact confidence scale or output formatting 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 description coverage is 100%, so the schema already documents all parameters. The description adds some context for history ('from any source') and repeats cycle_irregular behavior, but it does not substantially enrich the semantics of today or privacy_mode beyond what the schema states.

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 tool's function: given a list of recent period start dates, it returns current phase, cycle day, estimated cycle length, next-period date, and confidence. This is a specific verb-resource combination, though it does not explicitly differentiate itself from sibling tools like cycle_predict_next_period.

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 by specifying the required input ('Given a list of recent period start dates') and the outputs, so an agent can infer when to use it. It does not discuss exclusions or explicitly name alternatives, but the input condition is reasonably clear.

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 indicate the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral details: it produces a TL;DR string for quick agent rendering and mentions that version v0.3.3 supports 'cycle_irregular: true' for PCOS-aware mode. These details enrich understanding beyond the annotations without contradicting them.

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

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

The description is concise at two sentences and front-loads the core functionality. Every sentence contributes value: the first defines what the report contains, and the second clarifies the TL;DR and the version-specific cycle_irregular behavior. No unnecessary words.

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

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

The tool has no output schema, so the description needs to convey what the agent will receive and what inputs are essential. While it lists report components and mentions the TL;DR, it does not explain the required 'history' parameter format or the optionality/behavior of 'today' and 'privacy_mode'. This lack of operational detail means an agent may not invoke the tool correctly without extra research.

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 low at 25%, meaning most parameters lack in-schema documentation. The description adds only minimal parameter-semantic value by explaining cycle_irregular's purpose. It fails to describe history, today, or privacy_mode, leaving agents to infer their meaning from the schema alone. Given the low coverage, this is insufficient.

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 clear purpose: a single-call report that combines phase, nutrition, training, hydration, and next-period estimate. This makes it evident that the tool produces an aggregated report. It does not explicitly name sibling alternatives, but the wording 'full report' and the component list distinguish it from more granular sibling 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 provides no explicit guidance on when to use this tool versus alternatives like cycle_estimate_phase or cycle_predict_next_period. It only mentions it is a 'single-call report,' which loosely implies a use case for needing multiple data types at once, but this is not directly stated as a condition for selection.

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

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

With readOnlyHint, idempotentHint, and destructiveHint already covering safety, the description adds useful behavioral detail: the rule is a stdev/CV/max-length heuristic rather than medical judgment, and irregular results surface a clinician hint. The exact threshold is not disclosed, but the overall behavior is transparent.

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

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

Three sentences cover input, output, heuristic, usage order, and clinical caveat with no filler except a harmless version tag. The main input/output statement 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?

For a read-only analysis tool with two parameters and a simple outcome, the description is nearly complete. It reports the output type and a special-case recommendation for fewer than 3 cycles, though it does not describe the exact return shape or the nature of the 'clinician hint' beyond naming it.

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 description reinforces the 3+ day meaning of cycle_lengths_days but adds no new information about privacy_mode or value formats beyond what the schema already documents.

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 resource ('last 3+ cycle lengths'), and states the exact output type ('regular or irregular'). It also names the underlying heuristic, which sets it apart from cycle_estimate_phase, cycle_predict_next_period, and other sibling 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?

It gives an explicit invocation context: 'Use this BEFORE deciding whether to set cycle_irregular: true on the other tools.' It also clarifies a limitation ('NOT a clinical diagnosis') and the 3+ length prerequisite, though it does not name alternative tools to use when a different question is being asked.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the bar is lower. The description adds useful context beyond annotations: the data is 'non-secret data only' and is stored at ~/.delx-wellness/profile.json. This gives the agent a clearer picture of what touching this tool implies.

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, front-loaded with the return value, and each sentence adds context. The only slight redundancy is 'Read-only' repeating an annotation, but it is brief and does not hurt usability.

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 tool with two optional parameters and no output schema, the definition covers purpose, usage trigger, data sensitivity, and storage location. It is complete enough for an agent to decide when to call it and what to expect.

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 both parameters already have clear descriptions in the input schema. The tool description adds no param-level detail, so 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?

The description states a specific verb ('Returns'), a specific resource ('11-question onboarding flow'), and the data subject ('shared Delx Wellness profile'). This makes the tool clearly distinct from siblings like cycle_quickstart or cycle_profile_get, even though no sibling is named explicitly.

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

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

The description gives clear usage context: the agent should ask these questions next so wellness-cycle-coach can personalize responses. It does not explicitly list alternative tools or exclusion conditions, so it stops short of a 5.

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 declare read-only and idempotent behavior, so the description does not need to restate that. It adds useful behavioral context by noting the v0.3.3 version, the luteal_extended placeholder, and that the cycle_irregular flag 'surfaces the clinician-defer warning' in the response. This goes beyond the schema and gives the agent an understanding of conditional output 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 two sentences, front-loaded with the core purpose. It efficiently includes version information and a key flag behavioral note without fluff. Every clause contributes to understanding the tool's function and special cases.

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 description covers the essential purpose, special phases, and flag behavior, which is adequate for an agent to call it correctly. It does not describe output format or error cases, but the lack of an output schema and the read-only annotations make those less critical. It could be slightly richer in distinguishing use cases from similar tools, but overall it is sufficiently complete.

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

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

The schema already describes privacy_mode and cycle_irregular with explanatory text. The function description adds only a similar note about the cycle_irregular flag ('surfaces the clinician-defer warning') and mentions the phase placeholder, but does not elaborate on parameter formats or constraints beyond the enum and booleans. With 67% schema description coverage and little additional detail, the description does not significantly raise parameter understanding 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 clearly states the verb ('Returns') and the resource ('evidence-informed nutrition + training + hydration recommendations') for a given phase. It also names the specific phase extension (luteal_extended) and the cycle_irregular flag, making its focus distinct from specialized siblings like cycle_recommend_nutrition or cycle_recommend_training.

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 over alternatives. It does not mention when to pick combined guidance versus the specialized nutrition/training tools, nor does it state any exclusions or prerequisites. The usage context is only implied by its purpose, with no explicit 'use this instead of X' note.

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, and the description adds meaningful behavioral context: return values, acceptance of 21-90 day cycles in irregular mode, confidence capped at 'low', and a clinician-defer warning. This goes beyond the structured metadata.

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 zero waste: the first front-loads the core purpose, and the second adds a concise version-specific behavioral nuance. Every clause contributes meaning and the description is appropriately compact.

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 prediction tool with no output schema, the description covers the main return values and key behavioral constraints. However, it does not specify confidence value ranges, error/edge-case behavior (e.g., insufficient history), or what the clinician-defer warning entails, leaving some ambiguity for an agent.

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 67%, and the description adds extra semantics for cycle_irregular beyond the schema (accepts cycles 21-90 days, caps confidence at 'low', surfaces clinician-defer warning). history is less illuminated, but the schema already specifies the required structure and date pattern.

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 verb ('returns'), the resource (period history), and the specific outputs (average cycle length, next-expected period start date, confidence). It also distinguishes itself from likely siblings like cycle_estimate_phase and cycle_irregular_check by focusing on next-period prediction rather than phase estimation or irregularity screening.

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: use this tool when you have period history and need a predicted start date and cycle length. It also provides situational guidance for cycle_irregular mode tied to PCOS/unpredictable patterns. However, it does not explicitly mention alternatives or when not to use the 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?

The description adds valuable behavioral context beyond the readOnlyHint and idempotentHint annotations by stating that nothing is stored locally and nothing is sent out. This clarifies the tool's privacy guarantees and does 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?

The description is a single, tightly worded sentence that front-loads the core action and lists the three return categories without repetition or filler. Every phrase adds meaning.

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

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

For a simple read-only tool with one optional parameter and rich annotations, the description covers purpose, return categories, and safety profile. It lacks an explicit output structure, but no output schema exists and the described categories are likely sufficient for an agent to invoke 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 privacy_mode parameter includes a clear description of summary vs. structured/raw behavior, so the schema carries the parameter semantics. The tool description itself does not discuss the parameter, matching the baseline for high schema coverage.

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 returns privacy-audit information: what is stored locally (none), what is sent out (none), and agent rules for cycle data. It is specific about the resource and purpose, though it does not explicitly differentiate itself from sibling tools like cycle_data_inventory.

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 intended use is implied by the name and description — privacy and data-handling questions about wellness-cycle-coach. However, the description does not explicitly say when to use this tool instead of the many sibling cycle_* tools, and it offers no exclusions or alternative routing.

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, so the safety profile is covered. The description adds useful behavioral context: the file location, that it is shared, and that it exposes sex_or_gender_context. No contradiction with annotations exists.

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 front-loaded with the return behavior, followed by the key output field and purpose. 'Read-only' is slightly redundant with the annotations, but it is harmless and the overall structure is efficient.

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 simple optional-parameter getter, and the description is sufficient: it names the exact profile file, the key surfaced field, and the consumer decision it supports. The only parameter is fully documented in the schema, so nothing critical 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%: privacy_mode is fully described with its enum values. The tool description adds no parameter-specific meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Returns') and names the exact resource ('shared Delx Wellness profile (~/.delx-wellness/profile.json)'). It also states the key output field (sex_or_gender_context) and its purpose, making it clearly distinct from siblings like cycle_profile_update or cycle_onboarding.

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 the tool matters: wellness-cycle-coach uses it to decide whether to activate phase-aware coaching. It does not explicitly list alternatives or when-not-to-use conditions, but the use case is concrete enough to guide selection.

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

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

With no annotations provided, the description bears the full burden. It does disclose behavior: it rejects fields containing secrets (oauth/token/etc.) and requires explicit user intent, and it implies persistence (a write operation). However, it does not specify whether the operation overwrites entire existing data, side effects, or the return format, leaving gaps for a mutation 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?

Two sentences, zero filler, and the core action is front-loaded. Every word earns its place, making it an exemplar of conciseness.

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?

Without annotations or an output schema, the description should cover expectations. It includes critical prerequisites and validation, but it lacks details on the return value, error handling, or idempotency. For a mutation tool with nested objects, this is a moderate gap but not severe.

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

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

Schema description coverage is 100%, so both parameters are adequately documented. The description adds a global constraint (secret rejection) which applies to patch, providing some semantic value beyond the schema but not per-parameter detail that isn't already present.

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 ('persist'), a specific resource ('shared Delx Wellness profile'), and the scope ('partial patch'), making the purpose clear. However, it does not explicitly differentiate from siblings like cycle_profile_get, though the naming implies a write versus read distinction.

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

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

The description mandates explicit_user_intent: true and implies it should be used when the user explicitly asks to save/update, but it provides no guidance on when not to use this tool or any alternatives. With many sibling tools, direct usage routing is absent.

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, so the safety profile is covered. The description adds the behavioral fact that it returns a walkthrough and should be called first, but no additional context about side effects, privacy, or rate limits. This is adequate given 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 short sentences with no fluff. The main functionality is front-loaded, and the trigger condition is stated directly. Every word 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 read-only, idempotent tool with only two optional enumerated parameters, the description covers the core purpose and usage moment. It does not explain the role of the 'client' parameter, which is a minor gap, but overall the definition is complete enough for an agent to call it correctly in the intended scenario.

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 50% because only privacy_mode has a description; client is undocumented. The tool description adds no meaning for either parameter. The enumeration values for client are self-explanatory to some degree, but the description does not compensate for the missing schema documentation of client's purpose or effect.

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 ('Returns'), a clear resource ('personalized 3-step walkthrough'), and the target system ('wellness-cycle-coach'). It also gives the exact user phrasing that should trigger this tool, which clearly distinguishes it from sibling tools like cycle_demo or cycle_onboarding.

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 explicitly says 'Call this first when the user asks how do I use this?', providing a clear usage trigger. However, it does not mention when not to use this tool or name alternatives, so it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool's non-destructive nature is covered. The description adds useful behavioral context by noting v0.3.3 supports 'cycle_irregular: true' for PCOS-aware mode, which informs behavior beyond the schema. No contradictions 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 sentences with no wasted words. The core functionality is stated first, followed by a useful integration tip and a version-specific feature note. 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 read-only recommendation tool with no output schema, the description covers the essential input (period history), the output concept (nutrition recommendations), and a relevant option (PCOS-aware mode). It does not describe the return format or any privacy implications, but given the annotations and simplicity, it is sufficiently complete.

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

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

Schema description coverage is only 25%, so the description carries some burden. It implicitly clarifies 'history' (period history) and explicitly explains 'cycle_irregular' (PCOS-aware mode), but it does not add meaningful semantics for 'today' or 'privacy_mode' beyond what the schema already provides. The description partially compensates for the low coverage but not fully.

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 ('returns') and a clear resource ('nutrition recommendations for the user's current phase'), immediately distinguishing it from the sibling 'cycle_recommend_training'. It is concise and unambiguous about what the tool does.

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 when to use the tool ('Given period history') and suggests combining with 'wellness-nourish' for full meal planning, which guides complementary usage. However, it does not explicitly state when not to use this tool or name direct alternatives, so it lacks exclusion criteria.

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, covering the safety profile. The description adds version-specific behavior (v0.3.3 supports cycle_irregular for PCOS-aware mode) but does not describe return format, failure cases, or data requirements beyond 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?

The description is concise and front-loaded with the core purpose. The version note adds relevant context without excessive verbosity. Minor deduction for the version string being somewhat tangential to invocation, but overall efficient.

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

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

The tool has moderate complexity with 4 parameters and no output schema. The description states what it returns ('training recommendations') and hints at inputs ('period history'), but does not explain expected history shape, today parameter usage, or privacy_mode implications, leaving some gaps for an agent to infer.

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

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

Schema description coverage is only 25% (only privacy_mode has a description). The description compensates partially by explaining cycle_irregular's purpose, but it does not clarify the semantics of history or today, which remain undocumented in both the schema and description.

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

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

The description clearly states the verb ('returns training recommendations') and the resource ('user's current phase' based on 'period history'). It distinguishes itself from sibling tools like cycle_recommend_nutrition and cycle_phase_guidance by specifically targeting training.

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 contextual guidance ('Pair with WHOOP/Oura/Garmin recovery for late-luteal load adjustments'), indicating a usage scenario. However, it does not explicitly state when to avoid this tool or mention alternatives, leaving usage boundaries implicit rather than explicit.

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