STAS Running Coach for Claude

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

With no annotations, the description discloses key behavioral traits: the update is conditional on hash matching, and confirmation copy is handled separately. This provides necessary transparency for safe use.

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, each serving a distinct purpose: stating the action, usage condition, and technical detail. No redundant or extraneous 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?

The description covers purpose, preconditions, and a key behavioral detail. However, it lacks information about return values or error handling, which would be helpful given the lack of an output schema.

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

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

The changeId parameter is described effectively, linking it to the preview step and emphasizing the user confirmation requirement. This adds value beyond the schema's type 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 tool commits a previously previewed change to goals, rules, or profile memory sections. It explicitly distinguishes from sibling tools like preview_profile_section_change by referencing the preview prerequisite.

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 provides a clear condition: 'Call this only after the user explicitly confirms the exact full text shown for that preview.' This gives good usage context but does not explicitly state when not to use or list 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?

With no annotations, the description compensates well: it explains dry_run's effect on writing vs. preview, format constraints (all-day dates, external_id pattern), and fields to omit. It lacks details on error handling or permissions but provides substantial behavioral 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?

The description is a single dense paragraph that front-loads the main action. Each sentence is informative, but breaking into sections would improve readability. It earns its length but could be more structured.

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 an array parameter and no output schema, the description covers creation rules, date formatting, for_week usage, and required fields. It lacks details on response format or error conditions, but is adequately complete for the intended use case.

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 description adds significant meaning beyond the schema: explains external_id pattern, date usage (all-day local times), conditional for_week, and instructions to omit certain fields. Despite 50% schema coverage, it enriches understanding of all sub-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 clearly states 'Create or update NOTE events in Intervals,' specifying the verb and resource. It distinguishes from sibling tools like create_plan_event by emphasizing the NOTE category and providing unique constraints like for_week.

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 explicit when-to-use scenarios (normal notes vs. weekly review notes with for_week=true) and when-not-to (avoid seven-day ranges, omit certain fields). It implicitly guides towards delete_note_events for deletion.

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 fully covers behavioral traits: dry_run mode (required, false=write, true=preview), mapping rules (server maps activity_type to Intervals type and category), use of workout_builder, and the constraint that the server adds wrappers. It also warns to read back with get_planned_events to verify structure.

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 front-loaded with the core purpose. However, it is verbose due to repetition of the example JSON and instructions in both the description and the events parameter schema. It could be more concise without losing clarity.

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 complexity of the tool (nested events, dry_run, workout_builder), the description covers all necessary aspects: input parameters, mapping logic, formatting rules, and behavior. No output schema exists, but the description adequately explains the outcome (write vs preview).

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%, yet the description adds significant meaning: a concrete example JSON, instructions on field formats (e.g., external_id pattern, activity_type enum), what not to send, and detailed rules for workout_builder syntax (e.g., repeat headers, step lines). This far exceeds the minimal schema descriptions.

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

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

The description clearly states 'Create or update planned WORKOUT events in Intervals.' It specifies the verb (create/update) and the resource (planned WORKOUT events). It also distinguishes from siblings like delete_plan_events and get_planned_events by noting that updates use the same external_id.

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 explicit guidance: when to use the tool (for planned events in Intervals), when not to delete/recreate (for edits, keep same external_id), and what to avoid (e.g., do not send low-level Intervals fields). It also clarifies that the tool is self-contained and not to look elsewhere for SKILL.md or examples.

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 the dry_run behavior (false deletes, true previews) and explains the two deletion modes. No annotations were provided, so the description carries the full burden. Missing details on side effects or authorization requirements.

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, front-loaded with the main action, and each sentence provides essential guidance without redundancy. Highly 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?

Given no output schema, the description adequately covers what the tool does, the two modes, and the required dry_run parameter. Missing some details on response or confirmation, but sufficient for a deletion 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?

All parameters have schema descriptions (100% coverage), but the description adds value by explaining the specific id format (note:YYYY-MM-DD:slug) and clarifying when to use each parameter. Baseline 3 increased for additional context.

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 'Delete STAS note events' and specifies two modes: deleting individual notes via external_ids or window deletion for whole note sets. It distinguishes from sibling tools like delete_plan_events by focusing on note 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?

Provides explicit guidance on when to use external_ids vs oldest/newest window deletion, and warns against deleting user-created notes without a note: external_id. Could be improved by explicitly mentioning alternatives from siblings.

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

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

With no annotations, the description fully discloses behavioral traits: dry_run controls write vs preview, window deletion is for full replacement, specific deletion for individual events, and warns against misuse. No contradictions.

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, front-loaded with purpose, every sentence adds value. No repetitive or extraneous content. Highly 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?

Given 4 parameters, no output schema, and no annotations, the description is remarkably complete. It covers both use cases, required parameter, and caveat about window deletion. Agents can correctly invoke the 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?

Although schema coverage is 100%, the description adds critical context beyond schema: explains external_ids format (plan:YYYY-MM-DD:<slug>), clarifies the relationship between oldest/newest, and the purpose of dry_run. Adds significant meaning.

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

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

The description clearly states the tool deletes STAS plan events and specifies two distinct modes: specific deletion via external_ids and window deletion for full replacement. This directly addresses the purpose and differentiates from siblings.

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 states when to use window deletion (replacing whole plan) and when not to (simple edits – use create_plan_event). Also mandates dry_run usage. Provides precise 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?

With no annotations, the description carries the full burden. It states 'read-only' (no mutation) and lists omitted data types, giving clear behavioral expectations. Could be more explicit about performance or error handling.

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: first states purpose and prerequisite, second details use cases and omissions. No wasted words, efficient and well-structured.

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 simple parameter and no output schema, the description sufficiently covers what the tool does, what it returns, and what it omits, enabling an agent to use it correctly.

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

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

Schema coverage is 100% and the schema already describes training_id as returned by get_trainings. The description reiterates this prerequisite but does not add new semantic meaning about the parameter itself.

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 loads a compact read-only passport for one completed workout, specifying the resource and action. It differentiates from sibling get_trainings by requiring its training_id and focusing on detailed questions (intervals, laps, splits, etc.).

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 to use after get_trainings and lists detailed use cases (intervals, laps, splits, etc.). It also discloses what is omitted (source payloads, coordinates), implying when not to use, though no alternative tool is named.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation and implies it's for preparatory use, but doesn't disclose important behavioral traits like authentication requirements, rate limits, pagination, error conditions, or what format the events are returned in. The description adds minimal behavioral context beyond the basic 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?

The description is brief (two sentences) and front-loaded with the core purpose. The second sentence provides contextual guidance without unnecessary elaboration. However, the first sentence could be slightly more precise (e.g., specifying 'list' instead of 'read' for clarity).

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 operation with 2 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what data is returned, how events are structured, whether there are limitations on the date range, or authentication requirements. The preparatory context hint is helpful but insufficient for full understanding.

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 0% schema description coverage for the 2 parameters, the description doesn't add any parameter-specific information beyond what's implied by 'date window'. It doesn't explain what 'oldest' and 'newest' represent, their format requirements (YYYY-MM-DD), or whether the window is inclusive/exclusive. The baseline is 3 since schema coverage is low but the description doesn't adequately compensate.

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 action ('Read planned events') and resource ('from the Intervals calendar'), specifying the scope ('in a date window'). It distinguishes from some siblings like create/delete operations but doesn't explicitly differentiate from other read tools like get_trainings or get_user_summary.

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 some guidance ('Use this before rewriting or replacing an existing STAS plan'), which implies a preparatory context. However, it doesn't explicitly state when to use this tool versus alternatives like get_trainings or get_user_summary, nor does it provide exclusion criteria or prerequisites.

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

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

With no annotations, the description should disclose behavioral traits like read-only nature, pagination limits, or performance considerations. It only states what it loads, missing important details for safe invocation.

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 convey purpose and usage efficiently with no wasted words. Front-loaded with the primary action.

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 absence of output schema and nested objects, the description covers the main use case and context. It could be more explicit about return format, but the name and schema fill some gaps.

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 baseline is 3. The description adds no parameter-specific meaning beyond the schema's descriptions, which are already adequate.

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 loads recent workouts with specific metrics and places it in context of analysis after summary. It distinguishes from siblings by specifying use cases for analyzing load, progress, fatigue, or consistency.

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 says 'Use after the summary when analyzing load, progress, fatigue, or consistency,' providing clear context. However, it does not mention when not to use it or alternative 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?

No annotations are provided, so the description must carry the full burden. It lists loaded content but does not disclose whether the tool is read-only, requires authentication, or has any side effects. The description is insufficient for a tool that loads extensive data.

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

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

The description is a single sentence, which is concise, but it is overloaded with many items listed in a run-on fashion. It front-loads the usage guidance well but could be more structured.

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

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

Given the tool's importance as a starting point and the lack of output schema, the description is incomplete. It does not explain what each loaded item entails, how to use the optional section parameter, or what the response format looks like.

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 has an optional 'section' parameter with enumerated values, but the description does not mention this parameter at all. With 0% schema description coverage, the description fails to compensate by explaining the parameter's meaning or usage.

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 'Start here for most conversations' and enumerates a comprehensive list of what the tool loads, such as profile, goals, rules, recent load, etc. This distinguishes it from sibling tools that handle specific actions like committing changes or creating 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 explicitly advises to use this tool at the start of most conversations, providing clear context. It does not explicitly mention when not to use it, but the sibling tool names imply alternatives for specific tasks.

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

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

No annotations are provided, so the description must cover behavioral traits. It clearly states the tool does not update the athlete profile, mentions canonical text building and rejection of old labels for goals, and warns about confirmation copy governance. However, it could be more explicit about any other side effects (e.g., whether it stores data), but overall it 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?

The description is relatively long but efficiently packed with essential information. It starts with the main purpose and then provides specific usage details. Every sentence adds value, so it earns its place, though it could be slightly more concise.

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 complexity (5 parameters, nested objects, no output schema), the description covers input usage well but lacks details on the preview output. It mentions 'show the user the exact full text' but does not specify the response format or structure, leaving some ambiguity for the 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?

Although schema coverage is 100% with detailed parameter descriptions, the tool description adds semantic value by advising to prefer structured for goals, highlighting that newText is a legacy fallback and must be canonical, and explaining validation rules. This goes beyond the schema and helps the agent choose parameters correctly.

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 creates a controlled preview for a goals, rules, or profile memory section change, identifying the specific resource and action. It distinguishes itself from the sibling commit_profile_section_change, which commits after preview.

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?

Provides explicit guidance: prefer structured for goals, newText is a legacy fallback and must be canonical. States it does not update the profile and instructs to show the user the exact preview text before commit, with separate UX spec for confirmation copy. Clearly differentiates when to use this preview versus the commit 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?

No annotations are provided, and the description fails to disclose behavioral traits such as safety (read-only), authentication needs, rate limits, or return format. For a read operation, this lack of transparency is a significant gap.

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

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

The description is two sentences long: first sentence identifies the tool's core function, second provides usage guidance. It is front-loaded and contains 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?

Given the tool has three optional parameters and no output schema, the description covers the primary use case but lacks details about return format, pagination, or error handling. It is minimally complete for a small 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?

With 0% schema description coverage, the description partially compensates by mentioning relevant enum values (previewed, committed, restored, expired for status; goals, rules, profile for section). However, it does not explain the 'limit' parameter or provide full parameter semantics.

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 action (Read) and resource (goals, rules, or profile memory change history), and distinguishes itself from siblings like restore_profile_change by specifying the purpose of inspecting changes before restore decisions.

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 advises using the tool 'before restore decisions,' providing clear context for when to invoke it. However, it does not discuss when not to use it or mention alternative tools like preview_profile_section_change.

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

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

No annotations, but description discloses read-only nature, conditional support based on server, and the purpose of the returned hash for later preview. Does not mention authorization or rate limits, but for a read tool this is acceptable.

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 core purpose, followed by actionable usage instruction. No redundant or vague wording.

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

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

Given no output schema, the description should elaborate on the return structure (e.g., format of sections and hashes). It only mentions hashes for preview, but doesn't specify that the return is an object or list. Slightly incomplete for an agent to fully interpret results.

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?

No parameters, so baseline 4. Description adds context about what sections are read (goals, rules, profile) and the role of the hash, but no parameter details needed.

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

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

Clearly states action (read) and resource (controlled STAS profile memory sections with hashes). Adds context about supporting goals, rules, and profile depending on server. Distinguishes from siblings like preview_profile_section_change which modifies.

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?

Provides explicit guidance: 'Use the returned hash as previousHash before previewing a change.' This links the tool's output to a subsequent step. However, lacks explicit when-not-to-use or alternatives, though siblings imply read vs write distinction.

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

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

No annotations are provided, so the description carries full burden. It discloses constraints (section must match, goals restriction) and mentions a separate UX spec. However, it does not explain success/failure outcomes or side effects beyond restoration. The description is good but could be more explicit about behavioral 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?

The description is five sentences, each adding necessary detail. It is not overly long, but the sentence about UX spec is vague and may not be actionable. Otherwise, it is well-structured and front-loaded with the core purpose.

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

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

Given the tool has one parameter and no output schema, the description covers purpose, constraints, and usage. However, it does not mention what the tool returns upon success or failure, which is a gap. The absence of output schema means the description should at least hint at the outcome. Still, the core information for invocation is present.

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

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

Schema coverage is 100% and the schema description already explains the parameter changeId's usage and conditions. The tool description repeats some of this but adds no new semantic meaning beyond the schema. 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 clearly states the action (restore) and the resource (committed profile memory change). It distinguishes from sibling tools like commit, preview, and read history, making its purpose unambiguous.

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

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

Explicit instructions are given: call only after user confirmation of exact full text, server restores only if current section matches committed change, and for goals old-format labels, use an alternative (rebuild canonical preview). This provides clear when-to-use and when-not-to-use 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?

Without annotations, the description fully discloses key behaviors: requires explicit user confirmation, must build from current data, cannot copy previous wording, specifies length and required sections, and clarifies when not to use.

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 front-loaded with the core action and includes many necessary rules, though it is long and somewhat redundant with the schema description. Still well-structured.

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 usage and constraints well but does not specify the tool's return value (e.g., success/failure), which would be helpful for an agent to confirm the operation.

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

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

Schema coverage is 100%, and the schema already describes the parameter's constraints and details. The tool description adds no new parameter-level semantics beyond what the schema provides.

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 saves the athlete's long-term STAS strategy only after explicit user confirmation, differentiating it from calendar or weekly plan tools among siblings.

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 states when to use (meaningful changes to long-term training logic) and advises against one-off weekly edits, but does not name specific alternative sibling tools for other tasks.

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

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

No annotations are provided, so the description carries the full burden. It effectively discloses the tool's purpose and usage context, but lacks details on behavioral traits such as rate limits, authentication requirements, or error handling. However, it does not contradict any annotations, and the context provided is useful for understanding its diagnostic role.

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 highly concise and front-loaded, consisting of only two sentences that directly state the purpose and usage guidelines. Every sentence adds clear value without redundancy, making it efficient and easy to parse for an AI agent.

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

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

Given the tool's low complexity (0 parameters, no output schema), the description is largely complete for its diagnostic purpose. It covers what the tool does and when to use it, but could benefit from additional context on output format or error cases. However, for a simple authentication check tool, this 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?

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description does not need to add parameter details, but it implicitly confirms this by not mentioning any inputs, aligning with the schema. A baseline of 4 is appropriate for zero-parameter tools.

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 explicitly states the tool's purpose: 'Check which STAS user is currently authenticated.' It uses a specific verb ('Check') and identifies the resource ('STAS user'), clearly distinguishing it from sibling tools like create_note_event or get_user_summary, which involve different operations and 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 provides explicit guidance on when to use this tool: 'Use only for diagnostics or reconnect troubleshooting.' This clearly defines the intended context and excludes other use cases, helping the agent avoid misuse in favor of alternative tools for general user operations.

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