get_exercises_by_body_part

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

With no annotations provided, the description bears the full burden and does add genuine behavioral context: 'Get' signals a read operation, and the Args section discloses pagination semantics (limit default 20 and max 100, offset default 0 to skip), which go beyond the schema's bare defaults. However, it does not disclose edge-case behavior such as handling of an unknown body part, empty result sets, or case sensitivity, which are the remaining behavioral unknowns.

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 a compact docstring: a one-line front-loaded summary, three tightly written per-parameter lines, and a Returns line. Every sentence earns its place with no repetition of schema structure or filler, making it quick for an agent to scan.

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 simple 3-parameter retrieval tool with an output schema, the description covers purpose, all parameters with constraints and examples, and the return shape, which is largely sufficient. The notable gap is contextual routing among the many similar sibling read tools and the lack of error/edge-behavior details; an agent facing overlapping alternatives like search_exercises or get_exercises_by_equipment gets no disambiguation help.

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 description coverage is 0%, so the description must compensate, and it does: body_part gets concrete examples beyond the schema's bare type, limit gets both default and the cap of 100 (not present in the schema), and offset is explained as 'Number of exercises to skip.' Each argument is meaningfully enriched, though body_part validity rules remain only illustrative rather than exhaustive.

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 opens with a specific verb-resource pair, 'Get exercises targeting a specific body part,' which precisely names the action, object, and filter scope. The body-part examples ('chest', 'back', 'legs') plus the named filter distinguish it from sibling read tools like get_exercises_by_equipment, get_exercises_by_target_muscle, and get_all_exercises 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?

The intended use — retrieving exercises filtered by a body part — is clearly implied by the summary and the body_part argument. However, there is no explicit when-to-use versus when-not-to-use guidance, and with six-plus overlapping read siblings (by equipment, by target muscle, by id, search, all), no alternatives are named or contrasted.

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