garminGet

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

With no annotations, the description does the minimum safety work by declaring the call 'read-only GET'. But for an arbitrary-endpoint escape hatch it says nothing about authentication, rate limiting, error behavior on bad paths, or response shape, all of which matter more here than for a fixed-endpoint 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?

Three sentences, each load-bearing: purpose, path format, query format. The format constraints are front-loaded before the examples, and there is 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?

Only two parameters and no output schema, but this is a generic pass-through where an agent has no idea what comes back or what a failed call looks like. The description covers inputs thoroughly and is silent on return/error semantics, which is the remaining gap for a catch-all tool with zero annotation coverage.

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 already 100%, so baseline is 3. The description exceeds that by adding format rules the schema omits: 'path' must be relative and start with '/', 'query' takes no leading '?', plus concrete examples of both. The example path and query string materially reduce malformed calls.

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?

States a specific verb and resource ('read-only GET on the Garmin Connect Personal API') and immediately carves out its niche: endpoints not covered by the other tools. That positioning lets an agent distinguish it from the named get* siblings without opening any schema.

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?

Gives two explicit selection conditions: the endpoint isn't covered by another tool, or a query parameter name must be adjusted. The 'not covered by the other tools' phrasing functions as an implicit 'when not to use' that routes the agent to the specialized siblings first.

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