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

Annotations indicate a write operation (readOnlyHint=false) and non-idempotent behavior. The description aligns with this by stating it 'Logs a new workout result' and adds that it returns the created result with its assigned ID. This is useful behavioral context beyond what the annotations provide. It does not contradict any annotation.

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 somewhat long due to the 17 parameters, but it is well-structured: it opens with a one-sentence summary, distinguishes required and optional fields, then provides an organized argument list, and ends with the return value. Each section earns its place, though the Args section is largely redundant with the schema. Slight verbosity prevents a 5.

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 17 parameters and no output schema, so the description carries the burden of explaining inputs and return value. It covers required and optional fields, provides inline examples for time and weight_class, and states that the created result is returned with an ID. It does not discuss error handling or permissions, but for a create tool with this schema coverage, this is fairly complete. A 4 is justified.

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% description coverage for all parameters, including examples. The description's 'Args' section mostly reiterates the schema information (types, defaults, examples). It does add a useful grouping of required vs optional fields and combines heart_rate_avg/min/max into one line, but overall it adds limited new semantic meaning beyond the schema. Thus baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Log a new workout result to the Concept2 Logbook.' The verb 'log' is specific, the resource is 'workout result', and the target system is named. It distinguishes from siblings like concept2_create_results_bulk (bulk creation) and concept2_update_result (updating an existing result).

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 clearly indicates when to use: to log a new single workout result. It lists required and optional fields, giving the user a sense of prerequisites. It does not explicitly mention alternatives or when not to use, but the sibling names (e.g., bulk create, update) imply the boundaries. This is clear context without explicit exclusions, so a 4 is appropriate.

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

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

Annotations already mark this as a non-read-only, non-idempotent operation; the description adds that it returns created results with IDs and supports markdown/json output. It does not discuss batch failure handling or rate limits, so it remains adequate but not deeply 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 front-loaded with a one-sentence summary and uses a clean Args bullet structure. It repeats some schema details but remains readable and not bloated.

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 bulk create tool, it covers purpose, per-item fields, optional fields, and return behavior; no output schema exists, so the return description helps. It omits batch limits/error semantics, but schema's maxItems and annotations cover some constraints.

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

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

The schema already describes all parameters (100% coverage), but the description adds crucial units ('tenths of a second', 'meters') and clarifies the default for user_id and response_format. This goes beyond field types/enums in the schema.

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

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

The description opens with a clear, specific verb ('Log') and resource ('multiple workout results to the Concept2 Logbook'), and the title/name emphasize bulk creation. This unambiguously distinguishes it from the sibling concept2_create_result.

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 frames the tool as a bulk operation ('in a single request') and references concept2_create_result for required fields, implying the single-result alternative. However, it does not explicitly state 'use for multiple, use concept2_create_result for one' or mention 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?

The description adds value beyond the annotations by stating 'Returns the raw export file content as text' and noting that export types vary by workout. These are useful behavioral details that the readOnlyHint and idempotentHint do not convey.

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

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

The description is concise, front-loaded with the purpose, and uses a structured Args list. It avoids fluff, though the Args section slightly duplicates schema details. Overall, it is efficient and well-organized.

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

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

The tool has no output schema, so the description compensates by explaining the return format. It covers purpose, parameters, and output, and the annotations provide safety context. This is complete for an export tool, missing only explicit error scenarios, which are rarely necessary.

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 clear descriptions for all parameters, including defaults and enums. The description's Args section mostly repeats this information without adding new semantic depth, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'Export' and the resource 'workout result from the Concept2 Logbook', specifying the output format. This distinguishes it from sibling tools like get_result (retrieve raw data) and create_result, 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 implies when to use this tool (to export in a specific format) but does not explicitly mention alternatives or when not to use it. It does note that export types vary by workout, giving some contextual guidance, but no direct comparison to sibling 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is clear. The description adds value by detailing the return fields (id, name, type, start_date, etc.) and the response_format arg, which goes beyond annotations. However, it doesn't discuss edge cases like empty results, which keeps it from a 5.

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

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

The description is concise and well-structured: a clear purpose sentence, a bullet list of return fields, and a parameter summary. No unnecessary words, and all content is directly relevant.

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 (1 param, no output schema, read-only), the description is complete. It states what the tool returns and how to control output format, which is all an agent needs to invoke it correctly and understand the result.

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

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

Schema description coverage is 100% with the response_format parameter already fully described in the schema. The description repeats this without adding extra meaning beyond what the schema provides, so it meets the baseline 3 but doesn't 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 description clearly states the specific verb+resource+scope: 'Retrieve currently active Concept2 challenges.' This distinguishes it from sibling tools like get_upcoming_challenges and get_season_challenges, which target different time frames.

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: use this tool when you need currently running challenges. It does not explicitly mention alternatives or exclusions, but the phrase 'currently active' gives enough guidance for an agent to differentiate from sibling tools, though not as explicit as naming them.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds only domain context about event challenges (tied to events/competitions) but no behavioral details such as error handling or output structure. This is acceptable for a read-only tool.

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

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

Description is brief and front-loaded with the core purpose. The domain clarification sentence is useful, and the Args block is redundant but standard. It could be slightly tighter, but overall it is efficient.

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

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

For a simple retrieval tool with 2 well-documented params and strong annotations, the description covers the essentials. However, the presence of multiple sibling challenge tools (event, season, current, upcoming) makes the lack of differentiation a completeness gap. No output schema means return structure is unspecified, but the response_format param hints at it.

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

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

Input schema covers 100% of parameters with descriptions. The description's Args section merely repeats the schema information (year required, response_format default). Per rubric, baseline is 3 when schema coverage is high.

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 'Retrieve Concept2 event challenges for a specific year' with a specific verb and resource. However, it does not explicitly distinguish from sibling challenge tools like get_season_challenges or get_current_challenges, relying on the 'event challenges' naming.

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?

There is no explicit guidance on when to use this tool versus alternatives. The statement 'Event challenges are typically tied to specific Concept2 events and competitions' implies a use case but does not mention exclusions or 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by detailing the response contents (e.g., split_data, stroke data availability) and clarifying the output format options, which annotations do not cover.

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

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

The description is front-loaded with the purpose and return details, then lists parameters. It is fairly concise, though the Args section is redundant with the schema, making it slightly less efficient than it could be.

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

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

For a simple, read-only retrieval tool with thorough annotations and a fully described schema, the description adequately covers the tool's purpose, output fields, and parameter defaults. No output schema exists, so the explicit list of returned fields fills that gap appropriately.

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 all parameters, including defaults and enums. The description's Args section merely restates the schema information without adding new meaning, so it meets the baseline but provides no extra semantic value.

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 ('Retrieve a single workout result by ID') and the resource ('Concept2 Logbook'), distinguishing it from siblings like list_results or get_result_strokes. The title reinforces the purpose without ambiguity.

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

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

It clearly indicates this is for fetching a single result by ID, which implies the appropriate use case. However, it does not explicitly mention alternatives or exclusions (e.g., 'for multiple results use concept2_list_results'), so it falls short of full 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?

Annotations already declare the tool safe (readOnly, idempotent, non-destructive). The description adds valuable behavior: the availability condition, the returned array structure, and the field names. It also notes that stroke data is typically large, justifying the default response_format. This goes beyond annotations.

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

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

The description is well-organized with a clear purpose statement, followed by a caveat, return type overview, and parameter list. Every sentence serves a purpose. The 'Args' section duplicates schema somewhat but adds the 'typically large' note. It could be slightly more concise, but it earns its length.

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

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

With no output schema, the description adequately explains what the tool returns (array of stroke objects with possible fields). It covers the only relevant prerequisite (stroke tracking) and parameter details. Given the tool's simplicity, this is complete enough for an agent to use 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%, so the baseline is 3. The description adds extra meaning by explicitly listing requiredness for result_id, the default for user_id, and the rationale for response_format default (large data). It also clarifies that response_format can return markdown or json, which is already in schema but reinforced.

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 ('Retrieve') and resource ('per-stroke data for a specific workout result'), clearly distinguishing it from sibling tools like concept2_get_result (which likely returns result summary without strokes) and concept2_list_results. It is immediately obvious what this tool does.

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

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

The description provides a clear prerequisite: stroke data is only available if stroke tracking was enabled, and tells the user to check the 'stroke_data' field on the result. This implicitly guides the user to first use a sibling tool like concept2_get_result to verify availability. It does not explicitly name alternatives but gives clear contextual 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?

Annotations already disclose read-only, idempotent, and non-destructive behavior. The description adds no extra behavioral context such as response structure or edge cases. It does not contradict annotations.

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

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

The description is compact, front-loaded with purpose, and the args list is minimal and directly usable. 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 and parameters are fully known. However, there is no output schema and the description does not specify the exact return structure or example, so the agent's understanding of the response relies on inference from the name and response_format parameter. Still, for a straightforward read-only retrieval, this is nearly complete.

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

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

The schema already covers both parameters with descriptions and constraints (year range, enum for response_format). The description merely repeats this information without adding new meaning, so it meets the baseline for high schema coverage 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 description clearly states the tool 'Retrieve Concept2 challenges for a specific season/year,' using a specific verb and resource with clear scope. This differentiates it from sibling tools like get_current_challenges or list_challenges, which target different scopes.

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

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

The description implies the tool is for retrieving challenges by year, but it does not explicitly contrast with alternatives or specify when not to use it. Sibling tool names are available but not referenced. Thus, usage guidance is only implied.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds the time-window scoping context, but does not disclose potential behaviors like result ordering, pagination, or timezone handling. This is acceptable for a simple read 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 extremely concise, consisting of one purpose sentence and a compact parameter list with defaults and constraints. Every piece of content adds value, and the purpose is front-loaded.

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

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

Given the tool's low complexity (2 optional parameters, full schema coverage), the annotations that indicate safe read-only behavior, and the absence of an output schema, the description is sufficiently complete. The response_format parameter already indicates the output type, so no additional return-value explanation is necessary.

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%, with both parameters ('days' and 'response_format') having clear descriptions, defaults, and/or enums. The description's Args section essentially paraphrases the schema, adding no new semantic meaning beyond what is already structured.

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 ('Retrieve'), resource ('upcoming Concept2 challenges'), and scope ('starting within a given number of days'). It differentiates from siblings like get_current_challenges and get_season_challenges through the 'upcoming' and time-window focus, but does not explicitly name alternatives.

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 when to use this tool (when needing challenges that start within a specified future window) but provides no explicit exclusions or references to sibling tools. The context is clear enough for an agent to infer appropriate use, but lacks direct 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?

Annotations already establish read-only, idempotent behavior. The description adds meaningful context by enumerating the exact returned fields (id, username, first_name, etc.) and documenting the 'me' alias for the authenticated user, which goes beyond the structured metadata.

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

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

The description is well-organized: a one-line purpose, a critical note about 'me', a return-field list, parameter definitions, and examples. Each section is concise and directly useful, with 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?

For a simple read-only Get with two optional parameters and no output schema, the description effectively covers all necessary context: return fields, parameter semantics, defaults, and usage examples. It is sufficiently 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?

Input schema covers both parameters with descriptions and defaults (100% coverage). The description repeats these details and provides usage examples, but does not introduce new meaning beyond what the schema already states, aligning with the baseline 3 for high 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 opens with a specific verb-resource statement: 'Retrieve a Concept2 Logbook user's profile information,' clearly distinguishing this from sibling tools focused on results and challenges. The special 'me' behavior for the authenticated user is also explicitly called out.

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 that this tool is for fetching user profiles, with examples for both own and specific user IDs. It does not explicitly name alternatives or exclusions, but the intended use is unambiguous given the sibling tool names.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds value by detailing the returned fields, the 'all time' scope, and the response_format parameter behavior, going beyond what annotations alone provide.

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

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

The description is concise and front-loaded with the main purpose, followed by a compact returns list and a minimal parameter section. Every sentence contributes useful information 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?

For a simple read-only list tool with one optional parameter, the description fully covers the operation: what is listed, the output fields, and the output format control. Combined with rich annotations and a complete schema, no needed context is missing.

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

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

The input schema fully documents the single parameter (response_format) with a clear enum and description, achieving 100% coverage. The description's Args section merely restates the schema without adding new meaning, so it meets the baseline 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 description clearly states the action ('List') and the resource ('all available Concept2 challenges (all time)'), with an explicit scope ('all time') that distinguishes it from sibling tools like get_current_challenges and get_upcoming_challenges. It also enumerates the returned fields, reinforcing the 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 clear context by emphasizing 'all time' and 'all available', implying comprehensive coverage. However, it does not explicitly name alternative tools or state when to use this over more specific challenge endpoints, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral detail: the output includes a paginated list with specific fields, pagination metadata (total, count, per_page, etc.), and a response_format option. No contradictions with annotations.

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

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

The description is front-loaded with the core purpose, then structured into Returns, Args, and Examples sections. Despite its length, every part serves a purpose—parameter documentation, return fields, pagination metadata, and usage examples—without fluff.

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 7-parameter tool with no output schema, the description covers all necessary context: what the tool does, all parameters (including defaults and enum options), the shape of returned results, pagination metadata, and response formats. Examples further illustrate common use cases.

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 7 parameters are fully documented in the schema (100% coverage), so the baseline is 3. The description's Args section repeats schema info but adds value with concrete examples (e.g., type='rower', from='2024-01-01') that clarify parameter combinations and default 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 'List workout results (rows/ergs) for a Concept2 Logbook user with pagination and filtering,' which is a specific verb+resource+scope statement. It clearly distinguishes from siblings like concept2_get_result (single result) and concept2_list_challenges (different resource).

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?

Clear context is provided: this is for paginated/filtered listing of workout results. Examples show how to filter by type and date range. However, it does not explicitly mention when not to use it or point to alternatives like concept2_get_result for a single result.

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

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

Annotations already indicate a write operation (readOnlyHint: false) and non-destructive behavior. The description adds valuable context: the ownership restriction and partial-update semantics. However, it does not disclose failure modes or response content, though the idempotentHint and destructiveHint reduce the need for more.

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 structured with an intro, ownership note, instruction, and Args block. The Args block largely duplicates the schema's property descriptions, adding redundancy. The unique content (ownership, partial update) is concise, but the section could be trimmed to reduce 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?

With no output schema, the description mentions response_format but does not describe the response body or error cases (e.g., missing result ID, unauthorized access). For a tool with 16 parameters, the description covers the key operation and constraints but lacks result/error details, making it adequate but not comprehensive.

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

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

Schema description coverage is 100%, so the schema already documents all 16 parameters. The description reinforces the partial-update behavior ('only provided fields will be changed') but otherwise the Args section simply restates the schema, providing minimal additional meaning.

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

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

The description clearly states the tool updates an existing workout result in the Concept2 Logbook, using a specific verb ('update'), resource ('workout result'), and context. This distinguishes it from siblings like concept2_create_result, concept2_get_result, and concept2_list_results.

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

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

The description gives clear usage context: 'Only the result's owner can update it' and 'Provide only the fields you want to change.' It does not explicitly name alternative tools or state when not to use this tool, but the instructions make the intended scenario clear.

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

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

Annotations already signal readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds valuable context beyond these: the ownership restriction, the list of updatable fields, and the return value ('updated user profile'). It doesn't contradict annotations and provides behavioral expectations for a mutation tool.

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

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

The description is well-structured: a one-sentence purpose, a critical constraint, a compact field list, and a detailed Args section. While the Args section largely mirrors the schema, it is useful for quick reference and doesn't waste words. It's appropriately sized for an 11-parameter 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?

For a tool with 11 optional parameters and no output schema, the description covers the operation, constraints, all parameters, and the return value. It doesn't explicitly state that omitted fields remain unchanged, but the optional nature of all fields implies a partial update. Overall, it provides sufficient context 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?

With 100% schema coverage, the baseline is 3, but the description adds meaning beyond the schema by clarifying that user_id must be 'me' or the authenticated user's ID. It also groups fields with their formats and examples, enhancing the schema's individual parameter 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 states a specific verb ('Update') and resource ('authenticated user's Concept2 Logbook profile'), clearly distinguishing it from sibling tools like get_user or create_result. It also adds the key constraint that only the authenticated user's own profile can be updated.

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 clearly conveys that this tool is for updating the authenticated user's own profile, with an explicit constraint on user_id. It doesn't explicitly name alternatives (e.g., 'use get_user to read'), but the scope and use case are unambiguous, providing clear context without exclusions.

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