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 carries the burden of behavioral disclosure. It details the dry_run parameter's effect, the server-side mapping of activity_type, datetime format requirements, workout_builder syntax rules, validation error handling, and the fact that icu_training_load may be partially weighted. It also mentions reading back with get_planned_events to verify structure. No contradictions with annotations (none exist).

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 very verbose and includes a large example repeated in the schema description. While comprehensive, it lacks conciseness and could be better structured with sections. Important information is present but not front-loaded efficiently for quick scanning.

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 events array and no output schema, the description covers most contextual needs: it explains validation errors, workout_builder formatting, and side effects. However, it does not explicitly state what the API returns on success (e.g., the created/updated event object), relying on inference from the example and mention of reading back with get_planned_events.

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%, but the description adds substantial meaning beyond schema: it explains the external_id pattern, gives a full example, provides detailed workout_builder syntax (e.g., 'repeat headers do not start with "-", step lines are flush-left'), and clarifies the mapping of activity_type to Intervals types. It also warns about not including ## STAS or ## Workout in workout_builder.

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's purpose: 'Create or update planned WORKOUT events in Intervals.' This is a specific verb-resource combination. It distinguishes from sibling tools like create_note_event (note events) and delete_plan_events (deletion) by clarifying it handles creation/updates and that updates should reuse 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 when-to-use guidance: it states 'do not delete the day/window just to edit time, name, note, load, color, or workout_builder' and advises using this tool again for updates. It also says 'This tool is self-contained; do not look for SKILL.md or examples in the athlete's calendar.' However, it does not explicitly list alternative tools like get_planned_events for reading, though that is 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?

Discloses dry_run preview behavior and warns about deleting notes without proper id, but no annotation provided. Does not mention permissions or side effects.

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

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

Three sentences, front-loaded with purpose, then id details, then window guidance. No redundancy.

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

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

For a tool with 5 parameters and no output schema, the description covers all key aspects: id usage, window deletion, dry_run, and warnings about user-created notes.

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 description adds crucial context: explains dual usage modes, id formats, and the role of each parameter beyond 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?

Explicitly states 'Delete STAS note events' and differentiates from sibling tools like delete_plan_events. Provides specific id format details.

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

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

Gives clear guidance on when to use specific ids vs window deletion, warns about user-created notes, and explains dry_run requirement.

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 discloses that dry_run is required, false deletes and true previews, and explains the difference between using external_ids (specific deletions) vs window parameters (bulk replacement). It lacks mention of error conditions or authorization, but the dry_run mitigates risk and the description is otherwise 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 concise, consisting of a few front-loaded sentences that first state the action, then provide specific guidelines. Every sentence adds value with no redundancy or filler.

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

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

Given no output schema and no annotations, the description covers purpose, usage guidelines, and parameter semantics adequately. It does not describe return values, but for a deletion tool with dry_run, this is acceptable. The description is sufficiently complete for an agent to use the tool correctly.

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

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

Although schema coverage is 100%, the description adds significant meaning beyond the schema: it explains the usage pattern (window vs specific ids), clarifies that external_id is a compatibility alias, and notes that window parameters are required unless external_ids provided. This helps the agent choose the correct combination.

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 plan events' and distinguishes between deleting specific events via external_ids/external_id and deleting a date window via oldest/newest. It also mentions a compatibility alias, making the tool's purpose unambiguous and distinct from siblings like create_plan_event and delete_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?

Explicitly states when to use window deletion ('only when the user is replacing the whole STAS plan') and when not to ('do not use window deletion for simple edits; update with create_plan_event instead'). Also requires dry_run parameter and explains its role, providing clear decision 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?

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 provided, so description carries full burden. Lists data loaded but does not disclose if read-only, authentication needs, side effects, or limitations. The phrase 'persistent STAS memory opportunities' hints at interaction but is vague.

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?

Single sentence lists key elements efficiently and is front-loaded with the usage hint. Slightly long but each component 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?

Provides a good overview of the summary contents but lacks detail on parameter usage, behavioral traits, and output format (no output schema). Adequate for an entry-point tool but incomplete in specifics.

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 has one enum parameter with 0% description coverage. The description makes no mention of the 'section' parameter or its values, failing to add meaning 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 it loads a comprehensive athlete summary including profile, goals, recent load, fitness context, etc., and positions itself as the starting point for most conversations, effectively distinguishing it from 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?

Explicitly says 'Start here for most conversations,' providing strong context for when to use. However, it does not discuss when not to use or mention alternatives among 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 carries the full burden. It clearly states 'This does not update the athlete profile,' which is crucial for a preview tool. It also explains that the server builds canonical text, rejects old labels, and that visible confirmation copy is governed by a separate spec. This covers key behaviors, though more details on error cases or output format could enhance transparency.

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 purpose and then provides detailed guidelines. It is structured logically with clear sentences. While it is lengthy, the complexity of the tool (multiple nested parameters for different sections) justifies the length. Minor redundancy exists (e.g., mentioning 'do not invent final chat-copy' could be tighter), but overall it is well-organized.

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 complexity (5 parameters, nested objects, no output schema), the description covers purpose, usage, behavior, and parameter guidance comprehensively. It addresses all three sections (goals, rules, profile) and provides specific instructions for each. However, it lacks explicit information about error handling or the exact output format, which would improve completeness.

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 significant value beyond the schema, particularly explaining when to use 'structured' vs 'newText', the format requirements for goals, and the behavioral implications of each field. For example, it clarifies that 'newText' must already be canonical for goals, which is not in the schema 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 creates a controlled preview for a profile memory section change, distinguishing it from the sibling 'commit_profile_section_change' tool. It specifies supported sections (goals, rules, profile) and provides detailed guidance for goals with structured input, making the purpose specific and 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?

The description explicitly states that the tool does not update the profile and should be used before commit, and it instructs to show the full preview text to the user for confirmation. It also advises preferring structured input over 'newText' for goals and warns about legacy fallback constraints. However, it lacks explicit exclusion of alternative tools like 'commit_profile_section_change' in the description itself, though the context makes it 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?

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.