get_goalsRetrieves Garmin Connect user goals, optionally filtered by active, future, or past status. Without a filter, retrieves all goals, each marked with its status.
Get user goals. Without a status every status is queried in turn and the results are merged, each goal carrying the status it was found under.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status. Defaults to all three. |
Changes observed during successful MCP inspections.
v4.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation. The description adds transparency about the merge behavior when no status is supplied, which is not disclosed in annotations or schema. This adds valuable context without contradicting the 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 two sentences long, with the primary purpose front-loaded in the first sentence and the behavioral nuance in the second. Every word serves a purpose, with no redundancy or 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?
Given a single optional parameter, clear annotations, and no output schema requirement for a simple getter, the description provides sufficient context. The merge behavior clarifies the main edge case, and the tool's usage is fully understandable.
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 covers the status parameter with enum values and a description. The tool description goes beyond by explaining the runtime behavior when the parameter is omitted (all statuses queried and merged, each goal tagged with its status), which enriches the parameter semantics. This is a meaningful addition to the schema's static documentation.
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 function: 'Get user goals.' The verb 'get' and resource 'goals' are specific, and the behavior when no status is provided is explained, distinguishing it from other getter tools. No sibling tool targets goals, so it 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 explains the effect of omitting the status parameter—queries all statuses and merges results—which serves as a usage guideline for parameter selection. However, it does not explicitly mention alternative tools or conditions when not to use it, though this is less critical given the tool's unique scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.