STAS Running Coach for Claude

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

With no annotations, the description carries the full burden. It discloses the optimistic locking behavior (hash match condition) and mentions the confirmation copy is governed by a separate UX spec. Missing details on error handling or exact return values, but sufficient for a commit 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?

Three sentences, each serving a clear purpose: states the action, specifies preconditions, and notes the update condition and UX scope. 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 no output schema and one parameter, the description covers essential preconditions and behavior. Missing details on failure conditions (e.g., hash mismatch) and return value, but otherwise complete for a commit 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?

The single parameter changeId has 100% schema description coverage, including a detailed explanation. The tool description essentially repeats that information, adding no new semantic value 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 it commits a previously previewed change to a goals or rules profile memory section. It specifies the action (commit) and resource, and distinguishes itself from the sibling preview_profile_section_change 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?

Explicitly states 'Call this only after the user explicitly confirms the exact full text shown for that preview.' Also notes the server updates only if the section hash matches the preview, providing clear context on when and when not to use.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool can 'Create or update' (implying mutation) and has a specific constraint on external_id format, but doesn't cover important behavioral aspects like authentication needs, rate limits, error handling, or what happens during updates versus creates. For a mutation tool with zero annotation coverage, this is insufficient.

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 appropriately sized with two sentences that are front-loaded with the core purpose. Every sentence earns its place: the first establishes the tool's function and use cases, the second provides a critical constraint. There's zero waste 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?

Given the complexity (mutation tool with array input and nested objects), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on behavioral traits, most parameter meanings, return values, and error conditions. While it provides some usage context, it doesn't adequately cover what an agent needs to invoke this 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?

With 0% schema description coverage and 2 parameters (one required array 'events' and one optional boolean 'dry_run'), the description adds minimal parameter semantics. It only mentions the 'external_id' parameter constraint ('starting with note:'), leaving the other parameters (including nested ones like name, dates, description) and the purpose of 'dry_run' completely unexplained. The description doesn't compensate for the low schema coverage.

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

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

The description clearly states the verb ('Create or update') and resource ('note events in Intervals'), making the purpose specific. It distinguishes from siblings by specifying 'note events' rather than 'plan events' or other types, though it doesn't explicitly contrast with all siblings like '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?

The description provides clear context on when to use this tool: 'for STAS notes, plan explanations, or weekly review notes' and 'only with external_id values starting with note:'. This gives specific application scenarios and a constraint, though it doesn't explicitly mention when NOT to use it or name alternatives like 'create_plan_event'.

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 mentions 'Create or update' which implies mutation, but doesn't specify permissions, side effects, error handling, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in 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 and efficient with two sentences that convey key information without waste. However, it could be slightly more structured by separating usage guidelines from constraints, but overall it's appropriately sized and clear.

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

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

Given the tool's complexity (mutation with 2 parameters, no output schema, and no annotations), the description is incomplete. It lacks details on behavioral traits, full parameter explanations, and output expectations, making it inadequate for safe and effective use by an AI agent.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions 'external_id' constraints ('starting with plan:') and implies 'events' usage, but doesn't explain other parameters like 'dry_run', 'name', dates, or 'color'. This adds minimal value beyond the schema, failing to adequately cover the 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 verb ('Create or update') and resource ('workout events in Intervals'), making the purpose specific. However, it doesn't explicitly differentiate from sibling tools like 'create_note_event' or 'delete_plan_events' beyond mentioning 'STAS plan events', leaving some ambiguity about sibling distinctions.

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 this tool: 'after reading the current plan' and 'only for STAS plan events with external_id values starting with plan:'. This gives explicit prerequisites and constraints, though it doesn't mention alternatives like 'create_note_event' or when not to use it, which prevents a perfect score.

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 discloses the destructive nature ('Delete') and the date-window constraint, but doesn't mention permissions needed, rate limits, whether deletions are permanent, or what happens if no events exist. For a destructive tool with zero annotation coverage, this is a significant gap in 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, efficient sentence with zero waste. It front-loads the core action ('Delete STAS note events') and adds necessary context ('in a date window before writing replacement notes'), making it appropriately sized 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 tool's complexity (destructive operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover parameter details, behavioral traits like safety or permissions, or return values, leaving critical gaps for an AI 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 description coverage is 0%, so the description must compensate. It mentions 'date window' which relates to 'oldest' and 'newest' parameters, but doesn't explain their format (YYYY-MM-DD as per schema pattern) or meaning (inclusive/exclusive bounds). It also omits the optional 'dry_run' parameter entirely, failing to add sufficient meaning beyond the bare schema.

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

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

The description clearly states the verb ('Delete') and resource ('STAS note events'), and specifies the scope ('in a date window before writing replacement notes'). It distinguishes from siblings like 'delete_plan_events' by specifying 'note events' rather than 'plan events'. However, it doesn't explicitly contrast with 'create_note_event' or other tools, keeping it from a perfect score.

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

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

The description implies usage context ('before writing replacement notes'), suggesting this tool is for cleanup or preparation. However, it lacks explicit guidance on when to use this versus alternatives like 'delete_plan_events' or 'create_note_event', and doesn't mention prerequisites or exclusions, leaving some ambiguity.

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 indicates this is a destructive operation ('Delete') and mentions the purpose of preventing old workouts from remaining. However, it doesn't specify authentication requirements, rate limits, error conditions, or what happens if no events exist in the date range. The mention of 'dry_run' parameter in the schema suggests a testing capability that isn't explained in the description.

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

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

The description is a single, efficient sentence that front-loads the core purpose and follows with the usage context. Every word serves a purpose with no redundancy or unnecessary elaboration. It's appropriately sized for a tool with a clear, focused function.

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

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

For a destructive operation with no annotations and no output schema, the description provides adequate purpose and usage context but lacks important behavioral details. It doesn't explain what constitutes success/failure, whether deletions are permanent or reversible, or what the tool returns. The parameter semantics gap is significant given the 0% schema coverage. The description is complete enough for basic understanding but insufficient for confident implementation.

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 0% description coverage, so the description must compensate. While it mentions 'date window' which relates to 'oldest' and 'newest' parameters, it provides no details about date format, timezone handling, or boundary inclusion. The 'dry_run' parameter isn't mentioned at all in the description, leaving its purpose undocumented. The description adds minimal semantic value beyond what's implied by parameter names.

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 specific action ('Delete STAS plan events'), identifies the resource ('plan events'), and specifies the scope ('in a date window'). It distinguishes from siblings like 'delete_note_events' by focusing on plan events rather than note events, and from 'create_plan_event' by being a deletion rather than creation operation.

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 this tool: 'before writing a replacement plan, so old workouts do not remain in the calendar.' This provides clear context about the intended workflow and distinguishes it from other tools like 'get_planned_events' (for reading) or 'create_plan_event' (for adding new events).

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?

No annotations are provided, so the description carries the full burden. It implies a read operation ('Load') but doesn't disclose behavioral traits like authentication requirements, rate limits, pagination, or error handling. The description adds some context about the data returned but lacks operational details needed for a higher score.

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 and concise, with two sentences that efficiently convey purpose and usage guidelines. Every sentence adds value without redundancy, making it appropriately sized for the tool's complexity.

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 annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers purpose and usage well but lacks parameter details and behavioral transparency. For a tool with 4 parameters and no structured support, this is a moderate gap, making it adequate but with clear deficiencies.

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 for undocumented parameters. It mentions no parameters at all, failing to explain the meaning or usage of 'full', 'limit', 'newest', or 'oldest'. This leaves significant gaps, scoring below the baseline of 3 for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Load recent workouts with pace, heart rate, sport metrics, intervals, and athlete reports.' It specifies the verb ('Load') and resource ('recent workouts') with detailed content. However, it doesn't explicitly differentiate from sibling tools like 'get_planned_events' or 'get_user_summary', which prevents a perfect score.

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 usage context: 'Use after the summary when analyzing load, progress, fatigue, or consistency.' This indicates when to use the tool relative to another tool ('get_user_summary'). However, it doesn't specify when NOT to use it or name alternatives among siblings, so it falls short of a 5.

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

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

With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions loading data from 'STAS' but doesn't describe authentication requirements, rate limits, error conditions, or what happens if the athlete doesn't exist. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.

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

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

The description is efficiently structured in two sentences that establish primary use case and scope. The first sentence clearly states the tool's role, and the second enumerates the data components loaded. There's minimal wasted verbiage, though it could be slightly more specific about the relationship between the parameter and data returned.

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 1 parameter with 0% schema description coverage, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what data format is returned, how the optional 'section' parameter filters results, or what 'STAS' refers to. For a tool that appears to be a central data access point, more contextual information is needed.

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 mentions loading multiple data sections but doesn't explain the 'section' parameter or its enum values. With 0% schema description coverage and 1 parameter documented only as an enum in the schema, the description fails to add meaningful semantic context about what each section value retrieves or how parameter usage affects the response.

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 an athlete's comprehensive profile data including profile, goals, rules, recent load, fitness context, and planning guidance from STAS. It specifies the verb 'load' and resource 'athlete's profile data', though it doesn't explicitly distinguish from sibling tools like 'get_trainings' or 'get_planned_events' which might retrieve more specific subsets.

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 with 'Start here for most conversations', indicating this is the primary entry point for athlete data retrieval. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for more targeted queries.

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 full burden. It clearly states the tool does not update the profile (non-destructive) and provides workflow constraints (don't invent chat-copy). It lacks details on side effects or auth, but is sufficient for a preview action.

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, each sentence adds unique value. 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?

Given the tool's simplicity and lack of output schema, the description adequately explains the preview workflow and constraints. It does not describe return values or errors, but these are less critical 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?

All four parameters have descriptions in the input schema (100% coverage), so the description adds marginal value beyond schema. It reinforces the purpose of previousHash (prevent overwrite) but does not elaborate on all parameters 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 creates a controlled preview for a goals or rules profile memory section change and explicitly notes it does not update the profile, distinguishing it from the sibling commit 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 instructs to use the tool before committing and to show the preview text to the user for confirmation, providing clear usage context. It does not explicitly mention when to avoid using it, but the sibling tools imply 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?

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, pagination, or side effects. It only says 'Read' which implies safety but lacks explicit confirmation.

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

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

The description is short (two sentences) with no redundant text. However, it is overly terse and omits essential details, making it less effective despite 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?

Given the tool has three parameters and no output schema or annotations, the description lacks information about return format, ordering, filtering behavior, or how results are structured. It only hints at the purpose.

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 adds no meaning to the three parameters (limit, status, section). It only recites some enum values for status from the schema without explaining their significance.

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

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

The description clearly states that the tool reads change history for goals or rules profiles, and mentions specific statuses (previewed, committed, restored, expired). It distinguishes from sibling tools like preview or commit by focusing on history inspection.

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 use case: 'inspect ... before restore decisions.' However, it does not specify when not to use this tool or mention alternatives like preview_profile_section_change for current previews.

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. The description adds behavioral context: it is a read operation (safe, idempotent) and returns hashes. It also mentions V1 limitations. However, it does not explicitly state safety guarantees or side effects, which a description should bear when annotations are absent.

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 concise sentences. First sentence declares purpose and scope. Second sentence provides a critical usage tip. 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?

Given no output schema, the description explains the return value's purpose (hashes for preview). It sets expectations with 'V1 supports only goals and rules.' Could add more detail about the output structure, but sufficient for a simple read 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?

Input schema has no parameters, and schema coverage is 100%. Description adds no parameter-specific meaning, which is fine. Baseline 3 is appropriate as the description does not need to compensate for missing 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?

Description clearly states it reads controlled STAS profile memory sections (goals and rules) with their hashes. The verb 'read' and resource are specific. However, it does not explicitly differentiate from sibling tools like preview_profile_section_change, though the hash usage hint indirectly distinguishes.

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 indicates a workflow ordering. It does not mention when not to use or alternatives, but the hint 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?

The description discloses key behaviors: the restore only succeeds if the current section still matches the committed change, and confirmation copy is governed by a separate UX spec. However, it lacks details on destructiveness (overwrites current), permission requirements, or what happens on failure. Given no annotations, this is adequate but not comprehensive.

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, front-loaded with the purpose, then key usage conditions. Every sentence adds value, with no wasted words 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?

The tool has 1 parameter and no annotations or output schema. The description covers purpose, usage condition, and a success condition, but omits failure behavior, output details, and side effects (e.g., whether the change is reversible). While the tool is simple, these gaps reduce completeness 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 already provides 100% coverage with a detailed description for changeId, including the confirmation and restore conditions. The tool description adds no new parameter semantics beyond what the schema states, so 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 verb 'restore' and the resource 'committed goals or rules profile memory change', making it distinct from sibling tools like 'commit_profile_section_change' and 'preview_profile_section_change'. It specifies the action and scope precisely.

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: 'Call this only after the user explicitly confirms the exact full text that will be restored'. It also notes a condition for success (current section matches committed change). While it doesn't explicitly list alternatives or when-not-to-use, the condition and confirmation requirement are strong enough to guide usage.

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 the tool saves data for future use, implying a write operation, but lacks details on permissions, side effects, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage, as critical behavioral traits are missing.

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

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

The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured by separating usage context. Overall, it's appropriately concise for a simple tool.

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 as a mutation operation with no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't address behavioral aspects like side effects, return values, or error conditions, leaving significant gaps for the agent to operate safely and effectively.

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 for the single undocumented parameter. It mentions 'strategy' and 'training foundation', which loosely relates to 'strategy_md', but doesn't explain the parameter's meaning, format (e.g., markdown as implied by '_md'), or constraints beyond the schema's minLength. The description adds minimal semantic value, meeting the baseline for low coverage.

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

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

The description clearly states the action ('save') and resource ('athlete's long-term strategy'), with a specific purpose ('so future planning uses the updated training foundation'). It distinguishes from siblings like create_note_event or create_plan_event by focusing on strategy rather than events. However, it doesn't explicitly contrast with all siblings, preventing a perfect score.

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

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

The description implies usage for saving long-term strategies to influence future planning, but provides no explicit guidance on when to use this tool versus alternatives like create_plan_event or other siblings. There are no exclusions, prerequisites, or comparisons mentioned, leaving the agent to infer context without clear direction.

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.