Skip to main content
Glama

Star/Unstar Segment

strava_star_segment
DestructiveIdempotent

Star or unstar a segment for the authenticated athlete (one write API request). Unstarring removes an existing preference. Reconcile a lost response before retrying.

Instructions

Star or unstar a segment for the authenticated athlete (one write API request). Unstarring removes an existing preference. Reconcile a lost response before retrying.

Input Schema

NameRequiredDescriptionDefault
starredYesTrue to star, false to unstar
segment_idYesThe segment ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv4.4.1
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / segment_id / exclusiveMinimum
      Added value: +0
    • addedInput schema / properties / segment_id / maximum
      Added value: +9007199254740991
  2. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare the write, destructive, idempotent and open-world profile, so the bar is lower; the description still adds real value by stating it is a single write request, that unstarring removes an existing preference, and that a lost response should be reconciled before retrying. There is mild tension with idempotentHint=true but it is advisory guidance rather than a contradiction.

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

Conciseness5/5

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

Three short sentences, front-loaded with the core action, and every sentence carries distinct information (scope, unstar semantics, retry safety). No filler.

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

Completeness4/5

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

For a two-parameter toggle with full schema coverage, rich annotations, and no output schema, this covers what an agent needs to invoke it and to handle a failed response. Only the absence of explicit alternate-tool routing keeps it from a 5.

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

Parameters3/5

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

Schema coverage is 100%, so both parameters (segment_id, starred) are already documented, including the boolean meaning. The description adds nothing beyond that, so the baseline 3 applies.

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

Purpose4/5

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

The description names a specific verb pair (star/unstar) and resource (segment) plus the actor scope (authenticated athlete), so the tool is easy to tell apart from strava_get_segment or strava_list_starred_segments. It stops short of explicitly naming a sibling to route against.

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

Usage Guidelines3/5

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

"Unstarring removes an existing preference" and "Reconcile a lost response before retrying" give useful usage context, but there is no explicit when-to-use/when-not or comparison against alternatives such as the starred-segment listing.

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