STAS Running Coach for Claude

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

With no annotations provided, the description carries the full burden. It reveals that the server rejects stale data and returns the new authoritative editing state. For a commit operation, this adequately describes the outcome and a key constraint. It does not explicitly state it modifies data, but 'commit' implies persistence, and 'rejects stale data' hints at state mutation.

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 consists of two efficient sentences with no redundant words. The first sentence immediately states the action and scope, while the second sentence provides critical usage constraints and outcome. Every sentence earns its place.

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

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

Given the tool's simplicity (one parameter, no output schema, low complexity), the description covers the essential aspects: what it does, when to call, and what happens with stale data. It mentions the return (editing state). It does not detail error scenarios or require additional context beyond what is provided.

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

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

The input schema has 100% description coverage for the single parameter 'changeId', detailing its source and required usage. The description adds no additional parameter meaning beyond the schema. Under the rule that high schema coverage yields a baseline of 3, this score 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 it commits a previewed change, listing the types of changes (goal, start, activity-link, result). It distinguishes itself from its sibling 'preview_goal_result_change' by specifying it is the commit step after preview. The purpose is 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 when to call: 'only after the user explicitly confirms the exact preview from preview_goal_result_change'. It also warns about stale data rejection. However, it does not provide explicit when-not-to-use scenarios or alternative tools beyond the mention of preview_goal_result_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?

With no annotations available, the description carries the disclosure burden. It reveals that the server updates the profile only if the section hash still matches the preview, adding behavioral context. It does not explicitly state it's a write operation (though 'commit' implies it) or describe error scenarios, but the hash check disclosure is useful.

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

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

The description is three sentences, front-loaded with the core purpose, and every sentence provides essential information without redundancy or filler. The structure is 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 the simplicity of the tool (one parameter, no output schema, no annotations), the description covers key aspects: preconditions (user confirmation, noChange check) and the conditional update behavior. It lacks mention of the return value or what happens on hash mismatch, but for a commit action this is adequate.

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 parameter description already includes the requirement to call only after explicit user confirmation. The tool description reinforces this but does not add new meaning beyond what the schema provides, so the baseline of 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 identifies the action ('Commit') and the resource ('previously previewed rules or profile memory change'), using a specific verb+resource structure. It distinguishes this tool from siblings by focusing on committing a preview, unlike other tools that preview or restore changes.

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 usage guidance is provided: 'Call this only after the user explicitly confirms the exact full text shown for that preview' and 'If preview returned noChange=true, do not call commit.' This clearly delineates when to use the tool and when not to, matching the 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?

Without annotations, the description fully discloses behavior: dry_run explicitly distinguishes between writing and previewing, and it details date conventions, field omissions, and weekly note handling. It also warns against creating a seven-day range for weekly notes, which is critical to using the tool correctly.

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 dense but every sentence earns its place. It front-loads the core purpose, then systematically addresses dry_run, external_id, dates, weekly notes, and field omissions in a compact format without 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?

Given the tool's complexity and lack of annotations/output schema, the description is remarkably complete. It covers key parameters, edge cases (weekly notes), constraints (omit certain fields), and behavioral distinctions (dry_run), leaving no major gaps for the agent to infer blindly.

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 the schema covers 50% of parameters, the description adds substantial meaning: it explains the role of dry_run, the external_id pattern, the for_week flag, and the requirement to use all-day local times. It also instructs to omit fields like type, moving_time, icu_training_load, and workout_doc, which are absent from the schema but important for correct behavior.

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

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

The description opens with 'Create or update NOTE events in Intervals,' which precisely identifies the action, resource, and scope. It clearly distinguishes itself from siblings like create_plan_event and delete_note_events by focusing on NOTE events with a specific external_id pattern.

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: it specifies the required category, external_id format, all-day date usage, and the for_week flag for weekly review notes. However, it does not explicitly mention alternatives or exclusions, such as saying 'for plan events use create_plan_event instead,' so it falls short of full when/when-not 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does so thoroughly: dry_run semantics, server-side mapping from activity_type to Intervals type/category, target inference, local datetime requirement, server-added wrappers, and verification via get_planned_events are all explicitly described.

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 very long single paragraph with redundant content: the example JSON is repeated multiple times (in the description, the schema's description, and the events property), and guidance about workout_builder is repeated. It lacks visual structure like bullets or sections, making it harder to parse despite the useful content. Most sentences earn their place, but conciseness is poor.

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 there is no output schema, the description covers the full context: validation error format, post-write verification steps, required/forbidden fields, workout_builder syntax, and update semantics. It is complete for a complex mutation tool and leaves no critical 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% (baseline 3), but the description adds substantial meaning beyond the schema: it enumerates allowed activity_type values, explains external_id format, details workout_builder syntax rules, clarifies dry_run effects, and notes icu_training_load caveats. The description significantly enriches parameter understanding.

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

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

The description opens with 'Create or update planned WORKOUT events in Intervals,' a specific verb+resource statement that clearly defines the tool's primary function. It also distinguishes from siblings like create_note_event by emphasizing 'planned WORKOUT events' and the update semantic, making the 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?

The description provides extensive usage guidance: it explicitly states when to update an existing event (keep same external_id, don't delete the day), when dry_run should be used, when workout_builder is mandatory vs optional, and how to handle validation errors ('inspect error.data.issues[].path'). This goes well beyond typical 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 provided, the description bears full responsibility for behavioral disclosure. It comprehensively covers key behaviors: the required dry_run parameter (false deletes, true previews only), the semantics of external_id as a compatibility alias, and the safety constraint about user-created notes. It also clarifies the window-deletion use case. This goes far beyond the bare function.

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

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

The description is three sentences and every sentence adds unique value. It front-loads the purpose, then details usage modes and safety rules. No fluff or redundancy—exemplary 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?

Despite five parameters and no output schema, the description covers the essential operational aspects: how to delete one vs. many events, when to use window deletion, and the mandatory dry_run flag. It also includes a critical safety warning. Given its complexity, the description is fully complete for an agent to invoke the tool correctly.

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

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

Schema coverage is 100% and each parameter already has a description, so the baseline is 3. The description adds meaning beyond the schema by explaining the relationship between external_id and external_ids (alias vs. preferred form), when to use window deletion, and the required dry_run behavior. This enriches but does not fully redefine the schema, meriting a 4.

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

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

The description opens with a specific verb and resource: 'Delete STAS note events.' This clearly distinguishes it from sibling tools like delete_plan_events and create_note_event. It also narrows the scope by contrasting single-event deletion via external_ids vs. whole-window deletion, leaving no doubt about the tool's function.

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 strong usage context: it explicitly says to use external_ids for one specific note, and to use oldest/newest window deletion only for replacing a whole note set. It also warns against deleting user-created notes without a note: external_id. However, it does not name alternative tools (e.g., 'use delete_plan_events for plan events'), so while clear, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the required dry_run flag behavior ('false deletes, true previews only') and the distinction between exact id deletion and window replacement. It also reveals that external_id is a compatibility alias for external_ids, which is a behavioral nuance not obvious from the schema alone.

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

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

The description is three sentences, front-loaded with the core action and then progressively adding usage constraints and the dry_run requirement. Every sentence contributes necessary information with zero filler, making it easy to parse and apply.

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 5 parameters and no output schema, but the description covers all invocation modes, the required dry_run behavior, and when to use window deletion versus exact id deletion. It is complete enough for an agent to decide when to use this tool and how to invoke it correctly, though it doesn't describe return values or edge cases like deleting note events alongside plan 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 coverage is 100%, providing baseline 3. The description adds meaningful semantics beyond the schema: it explains that external_id is a compatibility alias, clarifies that oldest/newest are for full-window replacement only, and advises preferring external_ids for multiple ids. This adds contextual value beyond raw parameter definitions.

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

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

The description opens with a specific verb+resource phrase: 'Delete STAS plan events.' It clearly distinguishes from sibling delete_note_events by specifying 'plan events' and further explains the exact id format (plan:YYYY-MM-DD:<slug>). This makes the tool's 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?

It explicitly states when to use each mode: 'Use oldest/newest window deletion only when the user is replacing the whole STAS plan in that date window.' It also provides an exclusion: 'Do not use window deletion for simple edits; update with create_plan_event using the same external_id instead.' This is excellent guidance that prevents misuse.

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

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

With no annotations provided, the description carries the burden of disclosure. It states the tool is read-only and compact, and explicitly lists what the response omits (source payloads, route coordinates, latlng, raw stream arrays). This gives valuable behavioral context, though it does not cover error handling or authentication.

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 purpose, and every sentence adds distinct value: what it does, when to use it, and what it omits. No fluff 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?

Given the low complexity (one required parameter, no output schema), the description is quite complete. It explains the tool's scope, usage context, and key omissions. A small gap is the lack of any detail about the return structure or error behavior, but for a simple read-only detail tool this is acceptable.

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 100% coverage for the single parameter training_id, and its description matches the tool description's mention of getting the ID from get_trainings. The tool description adds no additional parameter semantics beyond the schema, so a baseline score of 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 tool loads a compact read-only passport for one completed workout, with a specific verb and resource. It distinguishes itself from sibling tools like get_trainings by focusing on a single workout and listing the types of details provided (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 gives explicit guidance to use this tool after identifying the training_id with get_trainings, and says it is for detailed one-workout questions. It does not explicitly name alternatives or when-not-to-use cases, but the omission of raw data implicitly warns against using it for that purpose.

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 bears the full burden. It correctly states the tool is read-only and that it provides data required for previews. However, it omits details like authentication needs, side effects, or error conditions beyond the stated 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 consists of two efficient sentences. The first sentence clearly states the function, and the second adds essential context about stable IDs and read-only behavior. No unnecessary words 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?

Given the tool has no parameters and no output schema, the description is reasonably complete. It covers the tool's purpose, read-only nature, and a usage hint. However, it does not define 'bounded editing state' or clarify the output structure, which could be beneficial 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?

The input schema has zero parameters, so schema description coverage is 100%. According to the guidelines, this merits a baseline of 4. The description does not need to add parameter information, and it does not.

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 'Read' and specifies the resource as 'complete bounded editing state' for multiple goal and result types. It distinguishes the tool's purpose for editing state, but does not explicitly differentiate it from siblings like 'get_current_goals_races_results' or 'preview_goal_result_change'.

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 implicitly suggests using this tool before preview operations by stating that stable public IDs and dataVersion are required for later previews. It also confirms it is read-only ('does not change anything'), but does not give explicit when-to-use or when-not-to-use guidance compared to other 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?

With no annotations provided, the description explicitly states 'This tool does not change the start, activity, or result', making it clear that the tool is non-destructive and read-only. It adds this behavioral context beyond what annotations would provide, though it lacks details on authorization 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?

The description consists of three concise sentences, each adding value: reading candidates, using the output, and confirming non-destructiveness. It is front-loaded with purpose and avoids 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 one parameter and no output schema, the description explains the purpose and output usage (opaque selectionId). Missing details on the return structure or error conditions, but overall adequate for selection and invocation.

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

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

Schema description coverage is 100% for the single parameter goalPublicId. The tool description adds no additional parameter meaning beyond the schema's description, which is sufficient. Baseline score of 3 is appropriate as no extra semantic value is provided.

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

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

The description clearly states the verb 'read' and the resource 'safe nearby activity candidates for one exact start'. It distinguishes from siblings by specifying the context of activity candidates for a goal and references the output usage for another 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 explains how to use the output (opaque selectionId for previewing result_link_activity), providing clear context. However, it does not explicitly mention when to use this tool over siblings like get_activity_detail or get_editable_goals_results, nor does it include when-not-to-use conditions.

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

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

No annotations are provided, so the description carries the full burden. It only says 'Read', which implies a safe read operation, but does not disclose behavior such as auth requirements, return format, pagination, or what exactly constitutes a 'planned event' or 'STAS plan'. The special-purpose context is vague, leaving the agent with gaps in understanding.

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 tightly written sentences. The first sentence front-loads the action and scope; the second provides a clear usage directive. No wasted 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 is simple with only two parameters, but the absence of annotations and output schema means the description should provide more context. It lacks details on what the returned data looks like, how to interpret 'planned events', and the meaning of 'STAS plan', making the description incomplete for an agent unfamiliar with the domain.

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 0%, so the description must compensate. It mentions 'date window' which loosely maps to the oldest and newest parameters, but it does not explain their semantics (e.g., inclusive/exclusive, required, format beyond the regex). The agent cannot infer parameter purpose from the description alone.

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

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

The description clearly states a specific action ('Read') on a specific resource ('planned events from the Intervals calendar') with a defined scope ('in a date window'). This distinguishes it from sibling tools like create_plan_event and delete_plan_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 phrase 'Use this before rewriting or replacing an existing STAS plan' explicitly provides a usage context. It implies that this is a prerequisite read operation for modification tasks, though it does not explicitly mention when not to use it or name 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 provided, the description carries the full burden. It discloses that the list is bounded and size-safe, that full mode adds a 'bounded compact interval projection' and is 'not raw data', and that default mode returns a 'rich index' with chronology, load, reports, and compact summaries. This gives a good sense of behavior and limitations, though it doesn't detail exact error conditions or response format.

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 purpose, then mode guidance, then an alternative recommendation. Every sentence contributes meaningful guidance with no filler or 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 read-only list tool with no output schema and no annotations, the description covers the essential context: purpose, two usage modes, when to use alternatives, and the safety/boundedness. It could mention pagination or date boundaries, but the schema already covers parameters, and the description adds enough strategic context.

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 value beyond the schema by explaining that full=true is for multi-workout comparison and is not for single-workout detail, and by framing default mode as a way to locate workouts and choose training_id. This contextualizes the parameters without repeating them.

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

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

The description opens with a specific verb and resource: 'Load one bounded, size-safe list of completed workouts.' It clearly distinguishes from sibling get_activity_detail by stating 'For one selected workout, use get_activity_detail instead of full=true.' This goes beyond a simple restatement and clearly identifies the tool's role.

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

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

The description gives explicit guidance: use default mode to find workouts and pick training_id, use full=true only for analysis-rich comparison across multiple workouts, and use get_activity_detail for a single workout. This not only states when to use the tool but also explicitly tells when not to use it and names the alternative.

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 implies a read-only operation ('Load'), but does not explicitly state safety or side effects. The mention of 'persistent STAS memory opportunities' is ambiguous and could suggest memory-related side effects without clarification.

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

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

One sentence, front-loaded with the main usage directive. It lists many data categories but remains concise; however, it could be slightly more structured for readability.

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 is simple (1 optional param, no output schema). The description gives a rich overview of what data is loaded, but misses parameter guidance and return format. It's adequate as a starting point but has clear 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?

The schema has a single 'section' parameter with enum values (profile, history, evidence, pace, plan) and 0% description coverage. The description does not mention the parameter or explain how to choose a section, failing to compensate for the schema's lack of 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 the tool loads comprehensive athlete context across many dimensions (profile, goals, rules, load, fitness, evidence, planning, STAS memory). It uses specific action verb 'Load' and names the resource, distinguishing it as the summary tool to start with.

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', giving a strong when-to-use directive. It doesn't mention alternatives or exclusions, but the context is clear for an initial data-loading 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?

With no annotations, the description fully covers behavioral traits: it states the tool never saves, previews effects including calendar/activity changes, and is read-only. This is sufficient for an agent to understand it is safe to call without side effects. The only minor gap is the lack of detail on the preview output format.

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 extremely concise: three sentences, no repetition, and all information is essential. The first sentence captures purpose, the second states the prerequisite, and the third gives usage instructions. 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?

Given the tool's complexity (14 command variants) and the absence of an output schema, the description covers the key points: purpose, prerequisite, non-saving nature, and the need to show preview to the user. It does not detail the preview's structure, but the primary output is meant for user presentation, so the agent's role is clear enough. The description is sufficiently complete for correct invocation.

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

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

Schema coverage is 100%, and the description adds significant value beyond the schema: it mandates loading get_editable_goals_results and clarifies that the command must represent exactly one change (not a bulk replace). The description also explains the purpose of expectedDataVersion. This exceeds the baseline of 3.

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

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

The description uses a specific verb (preview) and enumerates the exact resources it operates on (general goal, calendar-linked start, activity pairing, race result, standalone result, legacy result), making the tool's scope crystal clear. It also distinguishes itself from siblings like commit_goal_result_change by explicitly stating it only previews.

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 mandatory prerequisite ('Always load get_editable_goals_results first') and an explicit workflow step ('ask for explicit confirmation before commit_goal_result_change'), guiding the agent on proper usage. It could be strengthened by directly contrasting with sibling preview tools, but the guidance is clear and actionable.

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 and does well. It explicitly states the tool does not update the athlete profile, making it clear this is a read-only preview. It also discloses a behavioral requirement—showing the exact text and obtaining explicit confirmation—which goes beyond the schema. 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?

The description is four sentences, each earning its place: main action, sibling differentiation, non-mutation disclaimer, and user-confirmation requirement. It is front-loaded and free of 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 the complexity (nested objects, 5 parameters, no output schema, no annotations), the description provides sufficient context. It implies the return value ('exact full text from the preview'), clarifies the non-committing nature, and complements the schema's parameter details. It is complete for a preview tool.

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

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

The input schema already has 100% coverage with detailed descriptions for all 5 parameters, including the section enum and the structured object. The description adds no new parameter-specific semantics beyond what the schema already states (e.g., rules/profile), so the baseline score of 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 opens with 'Create a controlled preview for rules or profile memory,' using a specific verb and resource. It explicitly distinguishes from sibling tools by stating that goals, starts, activities, and results must use preview_goal_result_change, clearly scoping the tool's 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 provides explicit when-not guidance: 'Goals, starts, activities, and results must use preview_goal_result_change.' It also clarifies the preview is non-mutating ('This does not update the athlete profile') and gives interaction workflow ('Before commit, show the user the exact full text from the preview and ask for explicit confirmation'), which effectively tells the agent how 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 explicitly declares the tool as 'read-only', which is a key behavioral trait. Since no annotations are provided, this disclosure is critical. It also mentions the content returned (full text and hashes), adding transparency about the output.

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 redundancy. The first sentence states the core function, the second adds usage context and read-only note. Every phrase is necessary and 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 simple, single-parameter tool with no output schema, the description provides adequate context: what it does, when to use it, and that it's read-only. It could optionally describe the output format more, but the mention of 'full text and hashes' sets reasonable expectations.

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 parameter description in the schema already explains that changeId is returned by read_profile_change_history. The tool description merely reinforces this without adding new semantic details. A baseline of 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 uses specific verb 'load' and clearly identifies the resource as 'profile-memory record' with 'full text and hashes'. It distinguishes itself from sibling tools like read_profile_change_history (which lists changes) and restore_profile_change (which restores a change).

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 'should be used only for details or before considering a restore', providing clear guidance on when to use this tool. It implies not to use it for other purposes, but does not explicitly name alternative tools for listing changes.

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 burden; it discloses that results are compact, paginated, and that text bodies and hashes are intentionally omitted. It also signals a read-only operation through 'Read', adding meaningful behavioral context beyond the schema. It doesn't mention sort order or filter semantics, but for a non-mutating list it is reasonably 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 short sentences are front-loaded with the primary purpose and immediately give navigation and omission details. No repetition, no filler.

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

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

No output schema exists and no annotations, yet the description does not fully describe the response shape beyond saying text/hashes are omitted. It does not mention sort order or status filtering, so an agent may still be uncertain what fields each compact record contains.

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 covers only 50% of parameters (limit, cursor); description compensates partly by mentioning nextCursor and goals/rules/profile as content sections. However, it does not explain the status filter or clarify limit behavior, leaving gaps for the undocumented enum 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?

Description opens with a specific verb ('Read') and resource ('compact paginated index of goals, rules, or profile memory changes'), clearly identifying the tool's scope. It distinguishes itself from the sibling detail tool by naming read_profile_change_detail for exact records.

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

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

It explicitly instructs using nextCursor for subsequent pages and read_profile_change_detail for a single exact record, which is clear alternative guidance. This tells an agent when this list tool is appropriate versus the detail 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?

With no annotations, the description carries the burden of disclosing behavior. The verb 'Read' implies a safe, non-mutating operation, and the description adds context about the returned hashes and their role in subsequent preview operations. It does not detail permissions or other potential side effects, but for a read-only tool this is sufficient.

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 with no fluff. It front-loads the core purpose, then gives a concise, actionable instruction about hash usage. 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 parameterless read tool, the description is complete: it states what is read, highlights the exclusion of goals/results, and explains how the returned hashes should be used. Combined with sibling tool names, the domain context is clear, and the lack of output schema is acceptable given the simple 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?

The tool has zero parameters, so the 100% schema coverage trivially covers all inputs. The baseline for 0 params is 4, and the description adds valuable context about the output (hashes and their usage) without needing to explain any 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 the tool reads controlled rules and profile memory with hashes, using a specific verb and resource. It also distinguishes itself from get_editable_goals_results by explicitly noting that goals/results are only available there, which prevents confusion among 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 explicit guidance on when to use this tool: to read rules/profile memory, and explicitly says goals/results are not available here but via get_editable_goals_results. It also instructs to use the returned hash as previousHash before previewing changes, giving a clear workflow 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 burden and does well: it discloses the conditional success ('Restore only succeeds when the current section still matches that change'), the goal label restriction, and the need for explicit confirmation. It stops short of explaining whether a restore creates a new history entry or is irreversible, but the core behavior is adequately 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 three sentences, front-loaded with the primary purpose, then preconditions and a special-case exception. Every sentence adds necessary information without 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?

For a one-parameter restore operation, the description covers the action, required sequence (read detail first), user-confirmation requirement, and an exception. It lacks explicit mention of return values or post-restore state, but the effect is clear and the schema handles the parameter. Minor gap in side-effect description prevents a 5.

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

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

The schema fully documents the single parameter changeId, including its preconditions. The description adds value by telling the user to obtain the exact record via read_profile_change_detail, which indicates where to get the ID. This exceeds the schema baseline, so a 4 is warranted.

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 'Restore' and the resource: 'a committed profile, goals, or rules profile memory change back to its previous text'. This precisely distinguishes it from siblings like preview_profile_section_change and commit_profile_section_change, which handle previews and commits, not restores.

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 preconditions: 'First load the exact record with read_profile_change_detail' and 'Call this only after the user explicitly confirms the exact full text'. Also gives an alternative for a blocked case: 'For goals, restoring old-format labels is blocked; rebuild a canonical goals preview instead.' This clearly signals when and how 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?

With no annotations provided, the description carries the full burden, and it excels. It discloses the explicit confirmation requirement, the contamination-risk treatment of previous strategy, the exact types of information to store vs. exclude (e.g., 'Do not store session frequency...'), and the delegation to the private Planning Gate. These are non-obvious behavioral traits well beyond what the schema states.

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 excessively long and largely duplicates the input schema's parameter description. While the first sentence is front-loaded, the remainder becomes repetitive and bloated, with many sentences that restate schema constraints verbatim. This violates the 'every sentence should earn its place' principle.

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 tool's purpose, content constraints, behavioral prerequisites, and usage guidelines comprehensively. It lacks only explicit mention of the return value or error behavior, but for a save operation this is a minor omission. Overall it is complete enough for the tool's complexity.

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

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

Schema description coverage is 100% for the single parameter strategy_md, with the schema already providing a detailed description of content, sections, length, and exclusions. The tool-level description repeats this content almost verbatim without adding new parameter-specific meaning. Thus it meets the baseline 3 but does not exceed it.

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

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

The opening sentence 'Save the athlete's direction-only STAS strategy only after explicit user confirmation' uses a specific verb and resource, and the subsequent 'It is not a calendar, weekly plan, block contract, or full coaching analysis' explicitly distinguishes it from sibling tools like create_plan_event or create_note_event. This makes the tool's unique purpose unmistakable.

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

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

The description states 'Use for durable direction changes, not one-off weekly edits' and explicitly calls out what the tool is not (calendar, weekly plan, block contract, full coaching analysis). It also mandates 'Before calling this tool, show the exact full markdown and ask for explicit confirmation' and warns 'Never show one version and save another', giving clear when-to-use and usage rules.

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 of behavioral disclosure. It indicates a read-only check of authenticated state but does not mention potential error conditions, response format, or whether any side effects exist. For a simple whoami tool, this is adequate but not rich.

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

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

The description is two concise sentences, front-loaded with the action ('Check which STAS user...') and followed by usage guidance. Every word earns its place with no redundancy.

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

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

Given the tool's trivial complexity, empty schema, and no output schema, the description covers the essential purpose and usage context. It does not describe the return value, but for a whoami operation this is a minor omission, leaving it just short of fully 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 tool has zero parameters, and the schema already reflects this with 100% coverage. The description adds no parameter details because none exist, which is appropriate. The baseline of 4 applies.

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

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

The description clearly states the verb 'Check' and the resource 'which STAS user is currently authenticated.' This is a specific, unambiguous action that is distinct from all sibling tools, which focus on goals, profile sections, notes, plans, and activity 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?

The description provides explicit context for when to use the tool: 'Use only for diagnostics or reconnect troubleshooting.' It does not, however, mention when not to use it or suggest alternative tools, so it falls slightly 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.