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

No annotations are supplied, so the description carries the full behavioral burden. 'Adds an entry' hints at append semantics, but it does not say what happens if a note already exists for that date, whether existing content is overwritten or merged, or whether any permissions are needed for this mutation. Return values are covered by the output schema, so that omission is acceptable.

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?

A single sentence with zero waste; the action is front-loaded and the parameter hint follows in parentheses. Nothing is redundant or padded.

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 two-parameter tool with an output schema, the definition covers the essential call mechanics: what it does and how to format the optional date. The remaining gap is behavioral detail about same-date collisions, which is a modest omission for a straightforward note-append tool.

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. It does well for 'date' by giving the YYYY-MM-DD format and the today-by-default behavior, which the schema only expresses as a null default. The required 'text' parameter gets no explanation of expected content, length, or formatting, leaving half the parameters undocumented.

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: it adds an entry to the training notes. That is clearly distinct from the sibling read_training_notes, though the description never names that sibling explicitly.

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 write-oriented purpose implies when to use it (recording a note rather than reading notes), but there is no explicit when-to-use or when-not-to-use guidance and no mention of read_training_notes as the counterpart for retrieval.

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

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

With no annotations supplied, the description carries the full burden and does well: it discloses irreversibility ('Permanently'), the ownership restriction (USER_TRAINING_PLAN only), and the confirmation requirement. It omits side effects such as what happens to workouts or data referencing the deleted plan, which keeps it from a 5.

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?

Two short sentences with zero filler, and the destructive nature plus scope constraint are front-loaded ahead of the confirmation caveat. Every sentence earns its place.

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 one-parameter destructive tool with an output schema (so return values need no explanation), the description covers permanence, ownership scope, and the confirmation workflow. The only material gap is guidance on how to source a valid plan_id.

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 single parameter plan_id has 0% schema description coverage, so the description must compensate. The phrase 'own training plan (USER_TRAINING_PLAN only)' implicitly constrains what plan_id may be (a user-owned plan, not a catalog plan), but it never says where to obtain the id or what happens with an invalid or non-owned id.

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?

Names a specific verb and resource ('Permanently deletes') and narrows the scope with '(USER_TRAINING_PLAN only)', which distinguishes it from plan-related siblings like get_available_plans and get_plan. It stops short of naming the sibling to use for non-owned plans, but an agent can still tell what this tool does.

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?

Provides an explicit usage precondition: 'Only after the user has confirmed.' That is genuinely actionable guidance for a destructive tool. It does not state when-not to use it or point to alternatives such as save_plan for modifying rather than removing a plan.

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

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

No annotations are supplied, so the description carries the full burden, and it discloses nothing: not that this is a read-only, per-user snapshot, nor whether 'points' and 'weekly goal' are computed or stored values. The 'get_' prefix weakly implies a read, but that is naming convention, not description content.

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?

It is only one short fragment, so there is no padding, but it is under-specified rather than concise and reads like a field list rather than a statement of purpose. There is no front-loaded verb to anchor the reader.

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?

The existence of an output schema means return values need not be explained, and with zero parameters the call itself is trivial to invoke. Still, with no annotations at all, the description should say at minimum that this returns the current activity summary for the authenticated user, which it never does.

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 tool takes zero parameters, so there is no parameter meaning for the description to add. Baseline 4 applies; nothing is missing on this dimension.

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 enumerates the data involved (activity level, points, weekly goal), which is slightly more informative than the name alone, but it is a bare noun phrase with no verb and no resource scope. An agent can infer this returns the user's current activity standing, but it is not stated, and nothing distinguishes it from siblings like get_bio_age or get_body_composition.

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?

There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool. The agent must guess whether this is a current-snapshot call or something to combine with get_recent_workouts.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose a non-obvious trait: plans listed here can surface the values last trained, unlike get_plan's stored values. It does not address permissions, whether plans are user-editable, or how the default (own_only=false) changes result breadth.

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 dense sentences cover a lot of ground with little waste, but the opening fragment ('Training plans in the app with planId: ...') is telegraphic and the semicolon-joined clause about last-trained values is easy to miss. Front-loading the scope and the parameter meaning is good; phrasing could be cleaner.

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?

This is a low-complexity, one-parameter read; an output schema exists so return values need no explanation. The description covers what the tool returns, the parameter's effect, and how it differs from get_plan. Only minor gaps remain around sibling selection and default behavior.

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 0% and the single parameter is undocumented in the schema, but the description fully defines it: True restricts results to the user's own plans, and by contrast the default includes trainer and gym-template plans. That is nearly the complete semantic of the one parameter.

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 states the resource (training plans with planId) and its scope: the user's own USER_TRAINING_PLAN plus plans from trainers and gym templates. It also explicitly contrasts with the sibling get_plan, so an agent can separate the two. The verb is only implied ('get'), but the resource and scope are specific enough to act on.

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 explains the single switch ('own_only=True returns only the user's own plans') and hints at a distinction from get_plan via the last sentence. It never states when to call this instead of get_plan, get_recent_workouts, or get_coach_context, so routing still requires inference.

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

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

No annotations exist, so the description carries the burden; it does disclose what the response contains (bio age plus its component sub-scores, including flexibility measurements), which is real behavioral value. It says nothing about permissions, freshness of the underlying data, or whether missing components can occur, leaving moderate gaps for an unannotated 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?

A single front-loaded sentence with no filler, and the return-value summary leads. The trailing 'including flexibility measurements' is mildly redundant with the parenthetical list but not wasteful.

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?

With zero parameters and an output schema present, the description needn't document return values or arguments, and it still sketches the response components. It is nearly complete; only the relationship to get_bio_age_history is left implicit.

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 are zero parameters, so the baseline is 4; however the description adds no parameter-related meaning because there is nothing to parameterize. It is slightly reduced only because the enumeration of parts reads as response shape rather than input semantics.

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 uses a specific verb-resource pairing ('Current bio age') and enumerates the returned components (muscle, metabolism, cardio, flexibility), which distinguishes it from get_bio_age_history. It stops short of naming that sibling explicitly, so an agent must infer the current-vs-historical split.

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 word 'Current' implies this is the snapshot tool versus the historical one, but no explicit when-to-use or when-not-to-use guidance is given and no alternative is named. Usage is only implied by the scope word.

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

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

No annotations are provided, so the description carries the full burden. It discloses key semantics (period granularity, shift counted backwards from now, zero meaning current) that an agent needs to call it correctly, but says nothing about read-only safety, whether shift is bounded, or how many points are returned.

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?

A single compact sentence with the resource and both parameter meanings front-loaded and no filler. It is appropriately sized, if slightly telegraphic.

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?

An output schema exists, so return values need no explanation, and both parameters are defined. What is missing is how this relates to get_bio_age and any constraint on shift, which matters for an unbounded history query among many metric-history siblings.

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 define the parameters and it does: period takes 'month' or 'year', and shift means how many periods back with 0 as the current period. That is meaning the bare schema titles ('Shift', 'Period') do not convey, though defaults and bounds are not restated.

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 states a specific resource (bio age history) and its granularity options, so the agent can tell it returns a time series rather than the single current value that sibling get_bio_age likely returns. It stops short of naming that sibling explicitly.

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?

Usage is only implied: the word 'history' plus the shift parameter suggests trend retrieval over time, and '0 = current' hints at how to reach the latest period. There is no explicit statement of when to prefer this over get_bio_age or how far back shift may go.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It implies a safe read of a current snapshot, but says nothing about behavior when no measurements exist, recency/freshness of "latest", or any permissions needed. The presence of an output schema covers the return shape, which lowers the bar somewhat.

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?

A single short sentence with the key qualifier ("Latest") front-loaded and no wasted preamble. The trailing "and so on" is vague filler that weakens precision but costs little in length.

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 no-parameter read tool with an output schema already defining return values, the description covers what is needed to select and call it. The main omission is disambiguating it from get_body_metric_history and stating behavior when no data is available.

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 tool takes zero parameters, so there is no parameter semantics to explain; a baseline of 4 applies. The description adds nothing misleading about inputs and correctly implies no filtering arguments are needed.

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 the resource (body metrics) and enumerates representative fields (weight, body fat, muscle mass, BIA values), so an agent knows what data comes back. The word "Latest" implicitly distinguishes it from the sibling get_body_metric_history, but it never names that sibling explicitly.

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?

Usage is only implied: "Latest" signals a current-snapshot read as opposed to the history tool, and the sibling list does contain get_body_metric_history. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer the routing.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It says nothing about what the history looks like — sampling granularity, ordering, whether gaps are filled — nor that the default window is 180 days, leaving the agent to infer behavior entirely from the schema default.

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?

A single compact sentence, front-loaded with the core purpose and back-loaded with the example and prerequisite. No filler; the only cost is that the terseness borders on under-specification.

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?

An output schema exists, so return shape needn't be explained here. Still, for a 2-parameter tool with zero schema descriptions, the missing coverage of `days` and of history semantics (granularity, ordering) leaves the definition only marginally complete.

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 add real value for `types` by giving example values and a source for valid names. But the `days` parameter is never mentioned, so half the parameters remain undocumented in both schema and description.

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?

Names a specific resource (history of single body metrics) with a concrete example of the `types` values, which makes the operation recognizable. It implicitly contrasts with get_body_composition by pointing there for valid names, though it never explicitly says 'use this for time series, that one for a snapshot'.

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 pointer to get_body_composition gives the agent a prerequisite step (fetch valid metric names first), which is genuine routing guidance. However, there is no explicit statement of when to prefer this tool over siblings like get_body_composition or get_bio_age_history, and no exclusions.

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

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

No annotations are supplied, so the description must carry the behavioral load, and it does disclose the data source (Markdown files in the coach folder) and a caching-style caveat about already-loaded files, which implies a read-only, idempotent operation. It stops short of stating what happens if the folder or files are missing, or whether output is truncated.

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?

Two sentences, front-loaded with what the tool returns and followed by the call-order rule. Every clause carries actionable information, with no restatement of the name 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?

The tool has no parameters and an output schema, so return-value structure need not be described here. Given that simplicity, the description covers source, content, and call ordering completely — the only conceivable addition would be error behavior for missing files, which is marginal.

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 are zero input parameters, so there is no parameter semantics to explain and the baseline is 4. Nothing in the description misdescribes or omits argument behavior.

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 the exact resource (coaching context from the user's Markdown files in the coach folder) and enumerates its contents: role, planning rules, athlete profile. That makes it distinguishable from data-oriented siblings like get_recent_workouts or get_bio_age, though it never explicitly contrasts itself with read_training_notes, the closest neighbor.

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 an explicit ordering instruction ('Call this first before planning or reviewing training') plus a precise exclusion ('unless these files are already loaded'). Both the when and the when-not are stated, leaving nothing to inference.

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

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

No annotations are supplied, so the description carries the full behavioral burden, and it discloses almost nothing: no statement that this is a read-only retrieval, no time window or scoping (does it cover the latest assessment or all history?), no permission or prerequisite context. The presence of an output schema relieves it of explaining return values, which keeps this above a 1.

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?

A single short sentence with zero filler, front-loading the resource and immediately qualifying it with the two analysis axes. It is appropriately sized, though it is on the edge of under-specification rather than genuine economy.

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 zero-parameter tool with a published output schema, the description covers what the tool returns at a high level, which is the main thing needed. What is missing is any framing of scope or freshness — an agent cannot tell whether the analysis is current or historical, which matters for how results should be presented alongside siblings like get_strength_history.

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 tool takes zero parameters, so there is no parameter semantics for the description to add; the baseline of 4 applies. No parameter meaning is missing or misrepresented.

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 identifies the resource precisely (muscle imbalance analysis) and even names the two axes evaluated: agonist/antagonist and left/right. It is a noun phrase rather than a verb+resource construction, and it does not explicitly contrast itself with neighbours like get_strength_status or get_body_composition, but the subject matter is distinct enough that confusion is unlikely.

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?

There is no when-to-use guidance at all — nothing says whether this is a current snapshot, a historical view, or how it relates to get_strength_status / get_body_composition. The agent must infer the use case entirely from the tool name.

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

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses that the response includes all exercises and sets for any plan type, but it does not state read-only status, permission requirements, or error behavior. For a simple read operation this is minimally viable but leaves gaps.

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 single, front-loaded sentence with no wasted words. It efficiently states the resource and the returned contents, making it appropriately concise for a simple get-by-id tool.

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 the low complexity, one required parameter, and the presence of an output schema, the description is just adequate. However, it omits parameter semantics and sibling differentiation, which are important for an agent choosing and invoking the tool correctly.

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 input schema has 0% description coverage and the description never mentions the required plan_id parameter. It implies that a plan is identified somehow, but does not explain what plan_id represents, where to obtain it, or any format details.

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 identifies the resource: details of a plan, including all exercises and sets, and notes it works for any plan type. It does not explicitly distinguish this tool from sibling tools such as get_available_plans, save_plan, or delete_plan, so it falls short of a 5.

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?

There is no explicit guidance about when to use this tool versus alternatives like get_available_plans, save_plan, or delete_plan. The implied usage is to retrieve full plan details when a plan_id is known, but no exclusions or alternative conditions are stated.

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

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

With no annotations, the description carries the behavioral burden and usefully discloses that results are limited to completed workouts and include today. However, it does not mention ordering, pagination, maximum range, or whether incomplete workouts are excluded beyond the word 'completed'.

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 single front-loaded sentence with no wasted wording. It efficiently packs timeframe, completion status, and returned exercise detail.

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 one-parameter retrieval tool with an output schema, the description covers the essential scope and contents. It is slightly incomplete on operational details such as ordering and maximum lookback, and it does not clarify sibling selection.

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. It does so by defining `days` as the lookback window in days and clarifying that today is included, which is meaningful beyond the bare integer schema.

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 states a specific resource and scope: completed workouts over the last `days` days, including today, with exercise/set/weight/rep detail. It is clear what the tool returns, but it does not explicitly distinguish itself from the sibling `get_workouts`.

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?

Usage is implied by the recent-timeframe and completed-workout scope, so an agent can infer this is for recent completed workouts. There is no explicit guidance on when to use this instead of `get_workouts`, `get_strength_history`, or other workout-related siblings.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It states the data scope and optional activity filter, but does not disclose authentication needs, pagination, default behavior, units, or what happens when `activity_id` is omitted.

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 single front-loaded sentence with no redundant wording. It communicates the resource, time window, and optional filter efficiently.

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?

An output schema exists, so the description need not explain return values. However, with no annotations and no schema descriptions for either parameter, the definition is still thin on behavioral context and parameter semantics for an agent to call it confidently.

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 explain both parameters. It does add meaning by indicating `days` is a lookback window and `activity_id` is an optional single-activity filter, but it omits the default of 180 days, what null means, and how activity IDs should be obtained.

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 resource, EGYM strength measurements, and scopes it to a `days` lookback with an optional activity filter. It is clear enough to distinguish from generic workout tools, but it does not explicitly separate itself from sibling tools such as `get_strength_status` or `get_recent_workouts`.

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?

There is no explicit guidance on when to use this historical strength tool rather than `get_strength_status`, `get_recent_workouts`, or `get_workouts`. The history framing implies usage, but alternatives and exclusions are left to inference.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about read-only semantics, permissions, empty-result behavior, or how 'maximum strength' is computed (actual vs. estimated). The 'get_' prefix and zero-parameter schema imply a simple read, but that is inference, not disclosure.

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?

A single short sentence that front-loads the resource and adds the cross-reference at the end. Nothing is wasted, but the parenthetical is cryptic without prior knowledge of activityId.

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?

An output schema exists and no parameters need documenting, so much of the burden is covered. Still, the definition leaves open what 'maximum strength' represents and whether results cover all machines or only ones with recorded data — gaps an agent would want closed for a status tool.

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 tool takes zero parameters, so there is no parameter meaning for the description to add; the baseline of 4 applies. The parenthetical about activityId is a cross-tool hint rather than a parameter explanation.

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 the specific resource returned: current EGYM maximum strength, broken down per machine/exercise. The word 'Current' implicitly contrasts with the sibling get_strength_history, though the distinction is left for the agent to infer rather than stated outright.

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?

Usage is only implied by the contrast between 'Current' and the sibling get_strength_history. The parenthetical '(activityId for get_strength_history)' hints at a workflow linking the two tools, but there is no explicit when-to-use or when-not-to-use statement.

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

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

With no annotations, the description carries the full burden, and it does disclose two real behavioral facts: only completed workouts are returned, and both date bounds are inclusive. It says nothing about result ordering, pagination, auth, or what happens with an empty or inverted range.

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?

A single front-loaded sentence with the resource first and the format/scope parenthetical second. Nothing is wasted and nothing essential is buried.

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 two-parameter read tool with an output schema, most requirements are met: both parameters are explained and the filter semantics are clear. What remains missing is how the result set is ordered or bounded and any acknowledgment of the get_recent_workouts alternative, which leaves the agent to determine sequencing and pagination on its own.

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 schema gives only bare 'Start Date' and 'End Date' titles. The description compensates well by specifying the ISO YYYY-MM-DD format and clarifying that both endpoints are inclusive, which is exactly the ambiguity an agent would otherwise guess at.

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 states the resource (completed workouts) and the scope (a bounded date range), which distinguishes it from get_recent_workouts by implication. It omits an explicit verb and never names the sibling it differs from, so the differentiation is inferential rather than stated.

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?

Usage is only implied: the date-range framing suggests this is the tool for bounded historical retrieval versus get_recent_workouts, but the description neither says when to prefer it nor states any exclusions or prerequisites. An agent must infer the choice from the parameter set alone.

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

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

No annotations are supplied, so the description carries the full behavioral burden, yet it never states that this is a read-only operation, whether notes are paginated or time-bounded, or whose notes are returned. The one genuinely useful disclosure is the scope boundary 'free-weight loads that are not in EGYM', which clarifies what this data covers relative to the EGYM-sourced tools.

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?

A single short fragment with no filler, front-loaded with the resource name. It is under-punctuated and reads like a keyword list rather than a sentence, but nothing is wasted.

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?

With zero parameters and an output schema present, return values and inputs need no explanation, so the definition is close to complete for a simple read tool. The remaining gap is the total absence of usage framing and of any explicit read-only statement, which no annotation covers.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description adds nothing beyond the schema because no parameter semantics exist to add.

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 fragment lists the note contents (runs, felt state, mobility, free-weight loads not in EGYM), which tells an agent what data comes back, but there is no verb — the read action is only implied by the tool name. It does not distinguish itself from siblings like get_recent_workouts or add_training_note.

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?

No when-to-use or when-not-to-use guidance is given, and no alternative is named. An agent must guess whether to call this versus get_recent_workouts or get_strength_history for overlapping information.

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

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

With no annotations present, the description carries the full behavioral burden and does substantial work: it discloses that replacement is a full overwrite of the whole plan, that weight is per-dumbbell for paired dumbbells, that weight is required for strength exercises unless body-weight based, and that setType is auto-added. It does not mention permissions/scopes or what happens on invalid activityIds, which is the main remaining gap for a destructive write.

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?

Purpose and overwrite warning are front-loaded in the first and last lines, with the field reference correctly placed in the middle as reference material. The dense line-wrapped field list is necessary detail but is formatted as prose rather than a clean list, which slightly hurts scannability.

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 3-parameter destructive write with no annotations, the definition covers payload construction, units, conditional requirements, and overwrite risk, and an output schema exists so return values need not be explained. Missing only auth/permission expectations and failure behavior, which keeps it short of a 5.

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% and the exercises parameter is an untyped free-form object array, yet the description fully specifies the set schema: numberOfReps, weight units and conditional requirement, recoveryTime, duration, optional distance/speed/incline/heartRate, plus the sideMode and trainingMethod enumerations and a concrete example payload. This is close to the maximum value a description can add over the provided schema.

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 first sentence gives a specific verb and resource ('Creates an own training plan in the EGYM app') and immediately distinguishes the two modes of operation (new plan vs replacement via plan_id). Against siblings like get_plan, get_available_plans and delete_plan, an agent can tell this is the write/persist path without opening the 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 states the selection condition for replace mode (supply plan_id) and gives an explicit guardrail: 'only replace plans the user has agreed to change.' It also routes the agent to search_exercises for activityId values. It stops short of stating when not to use this tool at all (e.g., prefer a dedicated update path), but the create-vs-replace guidance is clear.

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

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

With no annotations, the description carries the burden and does so well: it discloses that the catalogue is cached locally, that `refresh=True` re-fetches from EGYM, and that refresh only applies to missing exercises. It omits any note on auth needs, rate limits, or result ordering, which keeps it from a 5.

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 purpose and matching rule are front-loaded and every sentence carries information. The closing line about `appName`, presumably an output field, is slightly dangling and reads as if it belongs elsewhere, which costs a point.

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?

An output schema exists, so return values need no explanation, and the caching/refresh semantics cover the most surprising behavior. The one gap is `limit` — its default of 15 and effect on result truncation are never mentioned, which matters for an ~1200-item catalogue.

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 0%, so the description must compensate, and it explains three of four parameters: `query` (all words must match local or English name), `category` (with concrete example values), and `refresh` (re-fetch scope). Only `limit` is left entirely undocumented.

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 states a specific verb and resource ('Searches EGYM's exercise catalogue') plus scale (~1200 exercises) and the outcome ('the exact name an exercise has in the app'). No sibling tool does name lookup, so the agent can place it immediately.

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 clear context for use — find the app name for an exercise, with optional category narrowing — and the AND-matching rule tells the agent how to phrase a query. It stops short of explicit when-not-to-use guidance or naming alternatives, but no sibling overlaps this function.

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