Create Concept2 Workout Result

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.