garmin-connect-api

Find exercise

find_exercise

Read-onlyIdempotent

Search Garmin's strength exercise catalogue by name to get the display name, category, and variant needed before creating or logging strength workouts and sets.

Instructions

Search Garmin's strength exercise catalogue by name, best match first; each result has the display name, category and exercise (the variant).

Use it before create_strength_workout, log_strength_session or edit_activity_sets whenever the Garmin pair is not known: those reject any other name, and accept a result's category and exercise as they are. Matching is by word starts ("lat pull" finds "Lat Pull-down"), with plurals and common gym names (rdl, ohp, skull crusher) understood. To turn one free-text name into exactly one exercise or nothing, use match_exercise. Answered from a bundled copy of the catalogue: no Garmin request, no login needed.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Most matches to return.
`query`	Yes	Part or all of an exercise name, e.g. "bench", "lat pulldown", "rdl".

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 20, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower, but the description adds real behavior: matching is by word starts, plurals and gym slang (rdl, ohp, skull crusher) are understood, and results come from a bundled catalogue with no Garmin request or login. That last point is genuine operational context an agent would otherwise have to infer.

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?

Front-loaded with what the tool does, then routing, then matching semantics, then the offline data source. Every sentence carries distinct information; none is padding.

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

Completeness5/5

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

An output schema exists so return values need no explanation, and the description covers routing, matching behavior, and the no-login data source. An agent has everything needed to call this correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description meaningfully deepens the query parameter by explaining the matching algorithm ('lat pull' finds 'Lat Pull-down') and alias handling. It adds semantics the schema's terse examples do not convey.

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

Purpose5/5

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

States a specific verb (Search) and resource (Garmin's strength exercise catalogue), plus the ordering (best match first) and the result shape (display name, category, exercise variant). It explicitly distinguishes itself from match_exercise, which is the nearest sibling.

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

Usage Guidelines5/5

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

Names the exact downstream tools it precedes (create_strength_workout, log_strength_session, edit_activity_sets) and the condition that selects it ('whenever the Garmin pair is not known'), including why those tools reject other names. It also names the alternative (match_exercise) with the condition that selects it ('exactly one exercise or nothing').

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