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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered and 'it reads only and changes nothing' is largely redundant. The description does add non-annotation context: a connected Phorme account is required, and weights are returned in pounds. That is meaningful added behavior for a data-returning 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?

Front-loaded with the usage trigger, then what it returns, then constraints, then units – a sensible ordering with no wasted framing. Two clauses are redundant against structured data ('it reads only and changes nothing' vs. readOnlyHint; the full return enumeration vs. the existing output schema), which keeps it just short of a 5.

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 single-optional-param read tool with an output schema, the agent has everything it needs: when to invoke it, what data domain it covers, the account prerequisite, and the unit convention. Return-shape detail is arguably unnecessary given the output schema, but its presence costs nothing and nothing required is missing.

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?

There is a single optional 'limit' parameter and schema description coverage is 100%, so the schema already fully documents count semantics, default of 10, and the 1-20 range. The description only implies newest-first ordering via 'most recent logged workouts' and adds no syntax or formatting detail beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

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 names a specific verb+resource (their own logged training in Phorme) and enumerates exactly what comes back: recent workouts with sets, best set, estimated max, volume, 7/30-day workout counts, and latest records. That level of detail makes it distinguishable from siblings like get_lift_progress (trend analysis), get_planned_sessions (future sessions), and get_saved_training (saved items) 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?

It gives explicit trigger phrases – 'what they did last time', 'how often they trained', 'personal records', 'a next workout built on their recent sessions' – and scopes usage to the user's own data. It stops short of naming alternatives or stating when NOT to use it (e.g., for progress trends use get_lift_progress, for upcoming sessions use get_planned_sessions), so it is clear context without exclusions.

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