mfp-mcp

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

The read-only claim just restates readOnlyHint=true, but the description adds real behavioral context beyond the annotations: sync_first is off by default and trades freshness for speed on cached data, and an unset range defaults to the last 30 days. It does not mention any rate limits or size caps on very large exports.

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-loads the payoff (what gets exported) in the first sentence, then handles the range and sync parameters compactly. Every sentence adds a fact the agent needs; there is no 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?

With no output schema, the description still names the returned content, and with no parameter descriptions in the schema it supplies formats, defaults, and sync semantics. Nothing required for a correct call 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?

Schema description coverage is 0% and the schema supplies no descriptions, titles beyond the key names, or formats, so the description carries the full burden. It documents all three parameters: start/end as YYYY-MM-DD with a last-30-days default, and sync_first as an opt-in MyFitnessPal gap-fill.

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 (Export) plus scope (a whole date range at once) and enumerates exactly what is returned: per-day nutrition totals, food entries with macros, daily note, and feel notes. That scope language distinguishes it from single-day siblings like fitness_get_day and from fitness_get_trends.

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?

Frames the use case ('for analysis') and gives a clear conditional for sync_first ('gap-fill from MyFitnessPal before exporting', off by default to keep large historical exports fast). It never explicitly contrasts itself with fitness_get_day, so the agent must infer when a single-day call is preferable.

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?

Annotations already mark it destructive, non-read-only, and idempotent. The description adds behavioral context by stating what is forgotten and that future logs will re-draft options, which is valuable beyond the structured hints. It does not cover permissions or scope subtleties, but with annotations the bar is lower.

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. It packs purpose, parameters, and outcome into one efficient statement. Appropriate for the tool's complexity.

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 annotations cover safety and idempotency, and no output schema exists, the description supplies the core purpose and effect. It leaves minor gaps around omitted-parameter behavior and relationship to the list sibling, but remains adequate for correct invocation.

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% for two parameters, so the description carries the burden. It explains query as the food choice and clear_all=True as clearing every choice, but omits that query is optional, default null, and what happens when no query is given with clear_all=False. Partial compensation yields a middle score.

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 (forget) and resource (remembered food choice), and states the effect on future logs. It distinguishes itself from listing siblings implicitly as the removal action, though it does not explicitly name an alternative. Clear enough for an agent to identify the tool's core job.

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?

Implies usage by explaining the outcome: after forgetting, the next log drafts options again. However, it offers no explicit when-to-use/when-not guidance, prerequisites, or mention of siblings like fitness_list_food_pins. The context hint is useful but not a full usage guide.

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?

Annotations already flag destructiveHint=true and non-idempotency, and the description goes well beyond them: default single-row deletion, exact-match precedence, error behavior when several or zero matches occur, which identical row is removed, and the warning that a short query can wipe many entries. That is exactly the blast-radius context an agent needs before a destructive call.

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 is front-loaded and every subsequent sentence (error cases, all_matches semantics, date format) adds operational value. It is longer than average, but the density is justified; only the 'like fitness_delete_food' aside could be trimmed without loss.

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 no output schema, the description still covers default vs. bulk behavior, ambiguity/zero-match error outcomes, and per-parameter formats. An agent has everything required to call it correctly and anticipate the consequences.

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 carries the load entirely — and it does: query is a case-insensitive substring/exact match against logged names, all_matches switches from one-entry to all-contains deletion, and date is documented with its YYYY-MM-DD format and today-default. All three parameters gain meaning beyond the bare 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 opens with a precise verb+resource ('Remove exercise-diary entries') and adds the matching mechanism (case-insensitive name match). It is clearly distinguishable from the sibling food-deletion tools and from the read-only fitness_get_exercise_entries.

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 concrete context for the all_matches flag ('for cleaning up syncs that log one workout as several same-named rows') and directs the agent to check fitness_get_exercise_entries first. It stops short of an explicit exclusion statement (e.g. use fitness_delete_food for food entries), so it is strong context rather than full when/when-not guidance.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the exact duplicate-removal semantics (identical name+quantity+meal entries are interchangeable, one removed per call), what the error payload contains, and the date/meal defaults. It does not mention permissions or whether the removed entry can be restored, keeping it out of 5 territory.

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 core purpose, then grouped per-parameter with clear labels. Every sentence carries actionable information about retry behavior, but it is denser than strictly necessary and slightly verbose in the error-recovery clauses.

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 destructive tool with no output schema, the description covers the essentials: what is removed, how ambiguous matches and duplicates are handled, error-recovery path, and argument defaults. The only missing element is any statement about authorization or reversibility of the deletion.

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?

With 0% schema description coverage, the description fully carries the load: `query` is defined as a name match with an example ('banana'), `meal` is constrained to breakfast|lunch|dinner|snacks or any account meal name, and `date` is specified as YYYY-MM-DD defaulting to today. Every parameter gets semantics the bare schema lacks.

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 in the very first clause — 'Remove a food from the MyFitnessPal diary by name match' — including the matching mechanism. This cleanly separates it from siblings like fitness_log_food, fitness_modify_food, and fitness_delete_exercise without the agent needing to open a 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?

Gives strong contextual guidance: use `meal`/`date` to disambiguate duplicates, retry with the error's listed candidates when the query matches nothing or multiple entries, and call again to remove further duplicates. It does not explicitly say when to prefer this over modify_food or other alternatives, so it stops short of a full when/when-not/alternatives 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?

Annotations already declare readOnlyHint and openWorldHint, so the bar is lower, yet the description adds real behavioral traits: options are ordered with fits_targets=false near-misses after fits, a previously confirmed food is pinned to the top, the order is immutable once drafted, and drafts expire in 24 hours. It does not discuss error conditions or what happens if no option fits.

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 core action, then moves to output shape, ordering rules, the follow-up call, and finally the date parameter. Dense but every block earns its place; the trailing 'date: YYYY-MM-DD (default: today).' is slightly orphaned from the rest of the flow.

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?

There is no output schema, and the description compensates by describing the returned option structure (every serving size with calories/protein/carbs/fat, a suggested_serving, and the fits_targets flag). Combined with the draft TTL and the logging handoff, an agent has everything needed to draft, interpret, and act.

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% across 13 parameters, so the description carries the load and largely does: it fixes units ('grams; calories in kcal'), explains that min_/max_ targets apply to the whole entry (serving × quantity), gives the date format and default, and defines quantity semantics. However, 'meal' and 'limit' are never explained, leaving two parameters 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?

States a specific verb and resource ('Draft a food entry: numbered options to choose from before logging'), and immediately frames it as a pre-logging step, which cleanly separates it from fitness_log_food and fitness_search_food in the sibling list.

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?

Explicitly routes the agent onward: 'Log a choice with fitness_log_food(draft_id=..., option=N, serving=M)' and 'call this again with different targets to refine.' The draft lifecycle ('Drafts last 24 hours') tells the agent the time window for acting on a draft.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that this is a multi-source aggregate (nutrition summary, diary entries, MFP daily note, local feel note), which is genuinely useful context, but it says nothing about return shape, size, or behavior when a day has no data.

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 lines, front-loaded with what is returned and followed by the parameter format. Every sentence earns its place; the only minor weakness is that the opening is a comma-list rather than a single crisp verb+resource statement.

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?

There is no output schema, so the description must convey return content — and it does, listing the four sections returned. Combined with the date format/default note and the read-only annotation, an agent has enough to call this correctly; only the empty-day behavior is unaddressed.

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 single 'date' parameter has no schema-level description, so the description carries the full burden. It supplies both the required format (YYYY-MM-DD) and the default behavior (today), which is exactly the missing semantics an agent needs.

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 ('Get day summary' via the title, and 'Nutrition summary, diary entries...') and enumerates exactly what the day aggregate contains, which differentiates it from siblings like fitness_get_note or fitness_get_trends. It is clear, though the retrieval action itself is implied rather than stated in the description body.

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 enumerated contents: this is the one-call aggregate for a single day, as opposed to fitness_get_note or fitness_get_trends for narrower/longer scopes. However, no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external-data profile is covered. The description adds which data categories are returned (cardio + strength), but says nothing about pagination, result volume, or auth requirements; adequate but not rich given the lowered bar.

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 lines, purpose first, parameter format second, zero filler. 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, no-output-schema read tool with annotations carrying the safety profile, the description supplies what is needed: what is read, the scope, and the date format/default. Only the lack of sibling disambiguation keeps it from being fully 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 coverage is 0% and the sole 'date' property carries no description in the schema, so the description's 'YYYY-MM-DD (default: today)' is genuinely additive meaning that the agent cannot get elsewhere. It could go further (timezone, date range limits) but it compensates for the coverage gap well.

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 (Read) and resource (MyFitnessPal exercise diary) and even scopes the content to cardio + strength for a single day. It does not distinguish itself from the nearby sibling fitness_get_exercise_entries, which an agent would need to disambiguate against, so it stops 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?

Only usage hint is the default date behavior; there is no statement of when to prefer this over fitness_get_day or fitness_get_exercise_entries, and no prerequisites or exclusions. The agent must infer the use case from the 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely new behavioral detail beyond the annotations: the shape of what comes back (section, name, and per-section columns) and the caveat that entry_id cannot be used for deletion, which the annotations do not convey.

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 is front-loaded in the first sentence, then return shape, then the delete caveat, then the parameter format. Every sentence earns its place, though the column enumeration is slightly dense and the entry_id caveat leans toward the delete tool's concern.

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 no output schema, the description compensates by describing the entry structure and its cardio/strength columns, and it documents the sole parameter's format and default. Combined with annotations that cover the read-only profile, an agent has enough to invoke it 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?

Schema description coverage is 0%, so the description must carry the parameter. It does: 'date: YYYY-MM-DD (default: today)' supplies both the format and the default behavior that the bare schema property lacks. Only the null-vs-today default nuance is left implicit.

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 and resource ('List a day's cardio and strength exercise-diary entries') and scopes it to a single day, which separates it from the broader fitness_get_day and the single-item fitness_get_exercise. It also names the sibling fitness_delete_exercise so the agent understands this tool is a read path, not the delete path.

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 'list a day's entries' framing, and the note that entry_id is informational while deletion is by name match gives useful cross-tool context. However, it never states explicitly when to call this versus fitness_get_day or fitness_get_exercise, so the agent must infer the boundary.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The phrase 'straight from your account' adds a live-fetch nuance consistent with openWorldHint, but the description says nothing about behavior when the note box is empty, whether it errors or returns blank, or any freshness/rate-limit characteristics.

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 the core identity front-loaded and the parameter format folded into a single parenthetical. Nothing is padded or repeated from the name.

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 read-only, single-optional-param tool with no output schema, the description covers the resource location and the date default/format, which is enough to invoke it correctly. Only edge-case return behavior (empty note) is unaddressed, a minor gap.

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% for the single date parameter, so the description must compensate and largely does: it gives the format 'YYYY-MM-DD' and the default 'today'. It stops short of stating the accepted range or timezone 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 states a specific verb ('Read') and a precise resource: the free-text 'Notes' box at the bottom of the day, which implicitly separates it from fitness_get_day. It never explicitly names a sibling or scope boundary, so an agent must infer the distinction rather than being told it.

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: reading the note versus fitness_log_note for writing is obvious from the verb, but there is no explicit when-to-use, when-not, or named alternative. Adequate but leaves the routing inference to the agent.

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?

Annotations only declare readOnlyHint and openWorldHint; the description goes further by disclosing the default range (last 30 days), the accepted date format, and that null data points are omitted from the series. That null-omission detail is genuinely useful behavior an agent could not infer from the schema.

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 short, front-loaded lines: purpose first, then parameter semantics, then return shape. Every line earns its place and nothing is repeated from the name or title.

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 no output schema, the description correctly specifies the return envelope {metric, points:[{day, value}...]}, and all three parameters are documented. Only minor gaps remain (units, range inclusivity, behavior on an empty range).

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 schema defines no enum, so the description carries the burden — it supplies the full allowed value list for metric (weight | calories_in | protein | carbs | fat), the YYYY-MM-DD format for start/end, and the 30-day default. It is strong compensation, though it omits units for weight and whether the range is inclusive.

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+resource ('a single metric over a date range') and enumerates exactly which metrics, so the agent knows this returns time series, not snapshots. It does not explicitly contrast itself with the closest sibling fitness_get_day (single-day view), so differentiation is implicit 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?

The phrase 'for charts/analysis' implies the use case (series over time rather than a daily log lookup), but there is no explicit when-to-use/when-not and no named alternative such as fitness_get_day. Usage must be inferred from the metric enumeration and date-range framing.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds meaningful context beyond that: 'Stored locally only' corroborates the closed-world nature, and the '(query → food and serving)' mapping describes what each listed item contains in the absence of an output schema.

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 no filler; the resource and its item structure are front-loaded, followed by the reuse relation and storage scope. Nothing is wasted and nothing needed 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 zero-param, read-only list with no output schema, the description supplies the essential missing context: what the entries contain and that storage is local. It omits only secondary details like ordering or result limits, which are minor for this 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, and the schema is fully described (coverage 100%), so there is nothing for the description to compensate for. Baseline 4 applies for a parameterless listing tool.

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 ('List remembered food choices') and clarifies the shape of each item (query → food and serving). It explicitly ties the tool to the sibling fitness_log_food, which reuses these pins, making it distinguishable from fitness_search_food, fitness_draft_food, and fitness_clear_food_pin.

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 implies usage by noting the pins are what fitness_log_food reuses, so an agent can infer this is the way to inspect saved shortcuts before logging. However, it never states when to use this instead of siblings like fitness_search_food or fitness_clear_food_pin, and gives no explicit exclusions or prerequisites.

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?

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=false. The description usefully adds that data is stored locally and never sent to MyFitnessPal, which is real context beyond the annotations. It does not, however, disclose the overwrite/destructive semantics implied by idempotent+destructive (re-logging a date replaces the prior note), which is the most important behavioral gap.

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-loads the purpose, then the local-storage caveat, then parameter hints in three tight lines with no filler. Efficient, though the trailing parameter lines are slightly clipped.

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-param logging tool with no output schema, the description covers storage scope, rating, and date, which is adequate. It is incomplete on the note parameter and on the overwrite behavior a caller would need to know given the destructive+idempotent annotations.

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 carry the parameter burden. It documents two of three parameters with useful format detail (rating 1-5 optional, date YYYY-MM-DD defaulting to today) but completely omits the 'note' parameter, which is the core payload of the tool.

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 (save) and resource (a 'how I feel today' note), and adds the notable constraint that it is stored locally only. However, it never distinguishes itself from the closely named sibling fitness_log_note, so an agent cannot tell the two apart from the description alone.

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 when-to-use guidance, no condition that selects this tool over fitness_log_note, and no prerequisites or exclusions stated. The only implicit cue is the 'how I feel' framing, which is weak given a near-identical sibling 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?

Annotations only cover the safety triplet (readOnly=false, destructive=false, idempotent=false, openWorld=true). The description adds substantial behavioral context beyond that: it writes to the real (not simulated) diary, the pin flag persists a food/serving choice for future reuse, and ambiguous queries produce a needs_choice=true draft instead of logging anything.

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 preferred path, then conditional branches, then a compact parameter glossary. Dense but every clause carries routing or default information; the only minor cost is that the three modes are stated in prose rather than as an obvious list.

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 ten-parameter mutation tool with no output schema and zero schema coverage, the description is close to sufficient: it covers all input modes, defaults and the needs_choice return branch. It stops short of describing failure/error behavior or duplicate-logging consequences, which an agent might want.

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 carries the entire burden, and it does: it explains draft_id, option, serving, meal (allowed values), quantity (default 1), date (YYYY-MM-DD, default today), pin, query, food_id and weight_id. Nearly all ten parameters gain meaning the bare schema lacks.

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+resource ('Log a food to the real MyFitnessPal diary') and distinguishes itself from the many other log_* siblings in the set. An agent can tell it apart from fitness_log_note, fitness_log_weight and fitness_modify_food 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?

Explicitly routes between three invocation modes: prefer draft_id+option from fitness_draft_food, fall back to query, or use food_id+weight_id from fitness_search_food. It names the sibling tools to obtain those IDs and states exactly what happens in each case, including the 'nothing is logged, a draft is returned' path.

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?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description earns credit by going beyond them: it discloses that writes go to the live MFP account ('synced to your account') and that the default behavior replaces the existing note unless append is set, which is precisely the destructive consequence an agent needs spelled out.

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 scope and sibling distinction come first, then a compact three-line parameter block. Every clause carries information — no restatement of the tool name, no filler — and the ragged trailing whitespace is cosmetic.

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 no output schema, the description need not explain return values, and annotations already cover the safety profile. It covers what is written, where it lands, and all three parameters, leaving only minor gaps such as whether the call errors when the day does not yet exist or what confirmation is returned.

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 carries the full burden and largely meets it: text as the note body, append as 'add to the existing note on a new line instead of replacing it', and date as YYYY-MM-DD defaulting to today. The format and default details for date are genuine additions the schema does not provide; only the exact type expectations for text are left thin.

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 ('Write the MyFitnessPal daily diary note') and pins down exactly which artifact is touched (the free-text 'Notes' box at the bottom of the day). It also names the sibling it must not be confused with (fitness_log_feel, local-only), so an agent can route correctly 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 distinguishes this tool from fitness_log_feel and explains the replace-vs-append decision point, which is the main usage choice an agent faces. It stops short of naming fitness_get_note as the read counterpart or stating when not to write at all, so it is clear context rather than a full when/when-not/alternatives map.

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?

Annotations already declare destructiveHint=true and idempotentHint=false; the description goes further by explaining that amount=0 clears the day (matching the destructive profile), that the call returns previous_ml, and exactly how to reverse a mistake. It also confirms the operation targets the real remote tracker, consistent with openWorldHint=true. No contradiction with 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?

Front-loaded with purpose, then one compact block per parameter, with the highest-value caveat (replace and undo) surfaced rather than buried. Dense but every sentence carries information an agent needs; nothing is 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?

There is no output schema, and the description compensates by stating the return value (previous_ml) and how to use it for undo. Combined with the unit/date format details, an agent has everything needed to call this correctly on the first attempt.

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 carries the full burden and does so: amount is additive to the day's total, unit lists cup/fl_oz/ml/l plus accepted spellings, replace is defined with the amount=0 edge case, and date specifies the YYYY-MM-DD format and today's default. All four parameters gain meaning beyond their bare schema types.

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 opening sentence gives a specific verb and resource — logging water to the MyFitnessPal water tracker — which is unambiguous and immediately distinguishable from siblings like fitness_log_food or fitness_log_weight. No inference required to know 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?

It gives an explicit conditional for the non-obvious path: use replace=True to correct a mislogged total, and call again with amount=previous_ml to undo. That is genuine usage guidance. It stops short of naming alternatives or stating when not to use the tool, so it is clear context rather than full 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?

Annotations already declare non-readonly, idempotent, destructive, open-world behavior; the description adds the meaningful detail that re-logging the same date overwrites that day's value, which explains why idempotent/destructive hints are set and what gets replaced. It does not mention auth/permission requirements, a minor gap.

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 short lines, front-loaded with the action, then per-parameter semantics. Every sentence earns its place with zero 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?

For a 2-parameter mutation tool with annotations and no output schema, the description covers action, both parameters, units, date format, and overwrite behavior. Only the return/confirmation behavior is unstated, which is minor.

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?

With 0% schema description coverage, the description carries the full burden and does: weight is in the account's display unit (kg or lbs) and date is YYYY-MM-DD defaulting to today. Both parameters are given format and semantics the bare schema lacks.

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 (log) and resource (weight measurement) plus the destination (MyFitnessPal). The resource is unambiguous against siblings like fitness_log_water and fitness_log_food, so an agent can route correctly 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?

Provides useful context (repeat logs for the same date update that day; date defaults to today) but gives no explicit when-to-use or when-not-to-use guidance versus alternatives such as fitness_modify_food or fitness_get_trends. Usage is implied rather than 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?

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds substantial context beyond them: the two-phase delete-then-add behavior, the exact-match/duplicate resolution rules, and the draft flow (needs_choice=true) with the required follow-up call. It discloses what is destroyed and how failures are recovered.

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 core operation is front-loaded, then each parameter gets a compact, purposeful line with no filler. It is long but every sentence carries behavioral or parameter information; the density is justified by the workflow complexity.

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 an 8-parameter mutation tool with no output schema and no annotation-documented return behavior, the description covers the full workflow including error responses and the draft-confirmation round trip. An agent has everything needed to invoke and recover 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?

Schema description coverage is 0%, so the description must carry all parameter meaning, and it largely does: query, new_query, meal (with allowed values and dual use for delete and add), quantity, and date all get explicit semantics. draft_id, option, and serving are only touched in the retry flow, leaving their exact meaning (e.g., option as a draft index) somewhat implicit.

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 ('Replace a MyFitnessPal diary entry') and immediately clarifies the compound operation: 'deletes the match, then adds a food.' This distinguishes it from siblings like fitness_delete_food and fitness_log_food, which an agent can tell apart 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?

Explains the replace-in-place use case and elaborates the retry/error paths (no match, multiple matches, duplicates). It references fitness_log_food for selection semantics, which helps route the agent. It stops short of an explicit 'use this instead of delete_food + log_food' statement, so 4 rather than 5.

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?

Annotations already establish readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral value by enumerating the candidate fields returned, which matters since no output schema exists and an agent must know what the results carry.

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 tight sentences, front-loaded with the action and resource, then the return contract. No filler, though the second sentence could be slightly more compact.

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?

Good coverage of return shape compensates for the absent output schema, but with three parameters at 0% schema description coverage the input side is left entirely unexplained, which is a meaningful gap for a search tool whose filters drive result quality.

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 description explains none of the three parameters. It never clarifies the meaning of query, the purpose of limit (default 5), or what with_macros toggles, so an agent gets no help on inputs beyond the bare schema types.

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 (search) and resource (MyFitnessPal food database) and gives the complementary handoff to fitness_log_food via food_id/weight_id, which cleanly differentiates it from the logging sibling. An agent can tell exactly what this tool produces.

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 names fitness_log_food and explains the workflow (search candidates, then log exactly that item), giving clear context for when this precedes logging. It stops short of explicit when-not guidance or naming alternatives like fitness_draft_food or fitness_list_food_pins.

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