post_create_activity

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

Since annotations are absent, the description carries the burden. It discloses that the operation modifies Strava data and requires the activity:write scope, which is useful. However, it does not describe what the response will be (e.g., the created activity object), whether the operation is reversible, or any rate limits. The core behavior (creating a manual activity) is clear, but the side effects and success semantics are under-specified.

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 relatively short but includes redundant lines: 'Create an Activity' is repeated as 'Creates a manual activity', and the endpoint 'POST /activities' is redundant given the tool name. The key scoping requirement (activity:write) is present. The structure is acceptable but could be tightened by removing the repeated title and endpoint, making it more 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 create operation with nine parameters and no output schema, the description provides only the essential behavior. It does not explain what the API returns (likely the created activity), which an agent would need to know. It also does not clarify the distinction between 'type' and 'sport_type' or any validation rules. Given the complexity, the description is 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 coverage is 100%, so each parameter already has a description. The tool description adds no parameter-specific context beyond the schema. It does not clarify the relationship between 'type' and 'sport_type' or explain expected formats, but the schema handles those. Per the rubric, the baseline is 3 when schema coverage is high, and the description does not enhance this further.

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 ('Create') and resource ('Activity'), clarifying it creates a manual activity for an athlete. It distinguishes itself from siblings like put_update_activity_by_id (update) and post_create_upload (upload) through the 'manual activity' phrasing and the explicit endpoint. The purpose is 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 only states what the tool does, not when to use it versus alternatives. It mentions 'manual activity' which implies it is for direct entry rather than file upload, but it does not explicitly say 'use this instead of post_create_upload' or provide any exclusion criteria. No guidance on prerequisites beyond the scope requirement, and no mention of when not to use it.

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