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

The description correctly states that the tool mutates the diary by adding an entry and returns a confirmation string. This aligns with annotations (readOnlyHint=false, idempotentHint=false). It adds a small amount of context by noting the date and quantity defaults, but it does not disclose whether entries are appended vs. replaced, how duplicates are handled, or whether authentication/session state is required. Annotations cover the basic safety profile, so this does not feel like a serious 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?

The description is front-loaded with the core purpose, followed by a brief usage pointer and a structured Args list. It is reasonably sized and easy to scan. The Args block is slightly redundant with the schema, and the first two sentences could be tightened, but overall it is organized and free of fluff.

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 tool with five documented parameters, an output schema, and annotations indicating a mutating operation, the description supplies the essential execution chain: search for the food, obtain mfp_id, then add with date/meal/quantity/unit. It does not leave major calling details uncovered. It could mention alternative addition routes or duplicate behavior, but those are secondary for basic 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?

The description's Args block echoes the parameter information already present in the input schema, which documents all five fields with defaults and examples. It does add the closed set of allowed meal names ('Breakfast', 'Lunch', 'Dinner', 'Snacks') and explicitly ties mfp_id to mfp_search_food. However, most of the value is redundant with the schema, so it only modestly exceeds the baseline.

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 clear, specific statement: 'Add a food item to your MyFitnessPal food diary for a specific date and meal.' It identifies the verb (add), the resource (food entry in diary), and the key qualifiers (date, meal). However, it does not distinguish itself from similarly purposed siblings like mfp_log_meal or mfp_bulk_log, 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?

The only usage hint is that users should call mfp_search_food first to obtain mfp_id. There is no explicit guidance on when to use this tool versus alternatives such as mfp_log_meal, mfp_bulk_log, or mfp_edit_food, and no exclusion criteria are given. The context 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?

The description adds substantial context beyond annotations: it discloses the cookie-authenticated web endpoint (no browser needed), the nuanced net-carbs behavior tied to country_code, the fact that MFP has no update endpoint, and that it returns the food id. This is exactly the kind of behavioral detail that helps an agent avoid errors. No contradiction with the 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?

The description is dense but every paragraph adds critical information: purpose, nutrition coverage, carb semantics, and update limitation. It is structured with clear paragraphs and an Args/Returns section. Slightly verbose, but each 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?

Given the complexity of the nutrition model and the critical country_code behavior, the description covers all essential context: what it creates, how it authenticates, what it returns, and how it relates to other tools. The output schema is present, so return-value details are not needed, and the description still clarifies the return format.

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?

Although the schema has rich per-parameter descriptions, the tool description adds concrete behavioral detail not in the schema: the verified example of how carbs/fiber store under different country_code values, and the warning 'Never pre-add fiber.' This goes beyond merely listing parameter names, earning an above-baseline 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?

The first sentence clearly states the action ('Create a private custom food') with a specific resource ('MyFitnessPal account'). It distinguishes from sibling tools like mfp_search_food (searching existing foods) and mfp_delete_custom_food (deleting). The mention of 'private' and 'custom' further differentiates it from diary-logging tools.

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 explains a key usage pattern: the returned id is accepted by mfp_add_food_to_diary, and because MFP has no update endpoint, corrections require creating a new food and deleting the old one. It does not explicitly state when to avoid using this tool (e.g., if a food already exists), but the context is reasonably 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?

Beyond the destructiveHint annotation, the description explicitly warns that deletion is 'not recoverable' and that MyFitnessPal may refuse deletion of a food referenced by a logged diary entry. It also states the return is a confirmation string with the HTTP status, adding useful behavioral context annotations alone do not provide.

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 compact and well-structured: operation, critical caveats, then Args/Returns. Every sentence adds information, and the destructive warning is front-loaded near the purpose 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?

For a single-parameter destructive deletion, the description plus annotations cover the action, the risk of irreversibility, the refusal edge case, and the return value. No essential caller information appears to be 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?

With schema description coverage at 0%, the description needed to explain how to obtain or identify food_id, but it only lists '(food_id)' without elaboration. It adds no meaning beyond the parameter name, leaving the agent to inspect the schema or infer from sibling tools.

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 ('Delete'), a specific resource ('user's custom foods'), and the lookup method ('by id'), which distinguishes it from other deletion/removal siblings like mfp_remove_food_from_diary. The operation is immediately unambiguous.

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 purpose sentence implies the tool is used when a custom food needs to be deleted, but it does not explicitly contrast it with alternatives such as mfp_edit_food, mfp_delete_meal, or mfp_remove_food_from_diary. There is no when-to-use/when-not-to-use guidance beyond the basic operation.

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 carry destructiveHint, and the description reinforces with 'Destructive and not recoverable', adding that deletion cannot be undone. It also discloses a platform constraint (no MFP read endpoint) and the return shape (deleted id and HTTP status), which goes beyond the structured fields.

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 compact and front-loaded: the action and destructiveness appear first, followed by the critical id-origin constraint, then Args/Returns. Every sentence earns its place with no redundant 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 one-parameter destructive delete tool, this covers the essential operational context: irreversible effect, valid id provenance, inability to list existing fasts, and return value. With an output schema present, no further detail is needed for an agent 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%, and the description compensates by saying the id identifies a fasting entry and must come from a prior mfp_log_fast call. However, response_format is only listed by name in Args with no added meaning, so the compensation is partial.

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?

Opens with a specific verb+resource: 'Delete a fasting entry by id' — clear and distinct from siblings like mfp_delete_meal. It also names the exact target (fasting entry) and the key dimension (id), so an agent immediately knows 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 explicit guidance on where the id must come from (prior mfp_log_fast or MFP app) and why listing is impossible, preventing a dead-end search. It does not name alternative tools for non-delete intents, but the prerequisite and limitation are clear enough for correct 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 convey read-only, idempotent, and non-destructive behavior. The description adds useful behavioral detail by stating that date defaults to today, response_format controls output, and the result includes daily totals and goals. No contradiction with the annotations exists.

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 well-structured with a clear summary, Args, and Returns sections, keeping the core purpose in the first sentence. The Args section is somewhat redundant with the input schema, but the return details add value given the absence of an exposed output schema. 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?

For a simple read-only retrieval tool, the description covers the essential inputs, default behavior, and expected return content. The annotations complete the safety profile. It is missing explicit usage guidance, but that gap is already reflected in the usage_guidelines score.

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 reported as 0%, so the description carries the burden of explaining parameters. It explains date with format and default value, and response_format with allowed values and meaning. The only minor omission is not explicitly stating that response_format defaults to markdown, though the schema provides that.

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: 'Get the food diary for a specific date including all meals and their nutritional information.' It clearly distinguishes this from sibling mutation tools like mfp_add_food_to_diary or mfp_delete_meal, and from other getters like mfp_get_goals or mfp_get_measurements. The resource is unambiguous even without naming alternatives.

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 guidance is provided on when to use this tool versus alternatives or when not to use it. There are no references to sibling getters, exclusions, or context about choosing markdown vs json for downstream tasks. An agent must infer usage purely from the tool name and description.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail: it returns both exercise categories with fields like duration, calories, sets, reps, and weight, and it returns a string representation.

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 front-loaded with purpose and uses a clean Args/Returns structure. The parameter details are somewhat redundant with the nested schema, but they earn their place given the low coverage signal.

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 read-only lookup tool, this description is complete: it states the date scope, output format choice, return type, and the kind of data returned. The strong annotations and output schema cover the remaining context.

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 top-level schema coverage signal is 0%, but the description compensates by explicitly documenting date (optional, YYYY-MM-DD, defaults to today) and response_format (markdown or json). It does not add semantics beyond the nested schema, but it presents enough guidance for correct invocation.

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: 'Get logged exercises for a specific date.' It further clarifies scope by saying it returns both cardiovascular and strength training exercises, which distinguishes it from sibling tools like mfp_search_exercises or mfp_log_exercise.

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 provides clear context for when to use the tool: when the agent needs the user's logged exercises for a particular date, including both cardio and strength details. It does not explicitly name alternatives or exclusions, so it stops short of a 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?

The annotations already cover readOnlyHint, idempotentHint, and non-destructiveness, so the description need not repeat those. It adds useful behavioral detail by enumerating what the response includes: calories, macros, fiber, sugar, sodium, cholesterol, vitamins, minerals, and serving sizes.

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 front-loaded with the main purpose, followed by a concise breakdown of return contents and a structured Args/Returns section. A small amount of repetition exists between the nutrition list and the Returns section, but overall it is economical and well-organized.

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, idempotent lookup tool, the description covers purpose, parameters, and output shape adequately. It could mention behavior for invalid or unknown MFP IDs, but that is a minor gap given the annotations and output schema already provide strong context.

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 description explicitly documents both parameters, including that mfp_id comes from search results and that response_format selects 'markdown' or 'json'. This fully compensates for the stated 0% schema description coverage, even though the schema itself also includes descriptions.

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 states a specific verb, 'Get detailed nutritional information', and a specific resource, 'a specific food item by its MFP ID'. This clearly differentiates it from sibling tools like mfp_search_food (searching) and mfp_add_food_to_diary (logging).

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 explicitly connects mfp_id to 'search results', implying this tool is used after a search and before logging or editing food. It does not explicitly name alternatives, but the usage context is clear enough for an agent to select it correctly.

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 idempotentHint=true, so the description does not need to prove safety. The description adds mild context by specifying that it returns configured targets for all tracked nutrients and that date defaults to today, but it does not disclose additional behavioral traits such as timezone handling or behavior when no goals are configured.

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 front-loaded with the core purpose and remains compact. The Args and Returns sections are organized and useful, with no filler. It is slightly redundant with the input schema, but the structure is clear and appropriately sized.

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 read-only tool with strong annotations and a minimal parameter set, the description covers the essentials: what is retrieved, the parameters, and the return type. It does not mention edge cases like missing goals, but an output schema is reportedly available and the annotation set already establishes safety and idempotency.

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 reported schema_description_coverage at 0%, the description carries the parameter documentation burden. It names both parameters: date with format and default, and response_format with accepted values 'markdown' or 'json'. This is sufficient for an agent to construct valid input, even though the schema also happens to contain similar 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 opens with a specific verb and resource: 'Get the user's daily nutrition goals (calories, protein, carbs, fat, etc.)'. This clearly identifies the tool's function and differentiates it from sibling getters like mfp_get_diary. The additional 'Returns the configured daily targets for all tracked nutrients' reinforces the scope.

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

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

The intended use is implied by the name and opening sentence, but no explicit guidance is given about when to choose this over related tools such as mfp_set_goals or mfp_get_report. It does not state exclusions or provide alternate tool routing, so the guidance is adequate but 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the tool's safety profile is clear. The description adds that it returns 'historical measurement data with dates and values' and mentions defaults for date parameters, which clarifies the tool's behavior beyond the annotations. No contradiction exists, and the added context (e.g., 'over a date range') enhances understanding without repeating structured metadata.

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 concise and well-structured: a two-sentence purpose statement followed by a clear 'Args' and 'Returns' section. It front-loads the primary purpose and keeps each sentence informative, avoiding fluff. The parameter list is neatly formatted and adds value without excessive length. It earns a high score for clarity and 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?

The tool is moderately complex with a nested input object and a response_format option. The description covers parameter defaults and return type (str) but does not describe the exact structure of the returned data beyond 'dates and values'. While an output schema is reportedly present (not shown), its absence means the description should still clarify what the JSON or markdown output contains. The description is adequate but lacks detail on the output format specifics, leaving some ambiguity for an agent needing to parse the response.

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% per the signal, so the description must carry the burden of parameter explanation. It does: it enumerates all parameters (measurement, start_date, end_date, response_format) with their defaults and value ranges. It even notes the default measurement is 'Weight' and response_format is 'markdown' vs 'json'. While it does not list all valid measurement string options, it compensates for the absent schema descriptions effectively.

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 states the tool's purpose: 'Get body measurements (weight, body fat, etc.) over a date range.' This specifies the verb (get), resource (body measurements), and scope (date range), distinguishing it from sibling tools like mfp_get_diary (food diary) and mfp_set_measurement (which sets rather than gets). The description is specific enough that an agent can immediately understand what data this tool returns.

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 provides context for when to use the tool ('Useful for tracking weight loss progress and body composition changes') but does not explicitly contrast it with alternatives. It does not mention exclusions or when to prefer mfp_get_report or mfp_get_diary. The guidance is implied through the focus on measurements but lacks direct comparative usage instructions.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns daily values and summary statistics, and clarifies the response_format parameter (markdown or json). However, it does not disclose any additional behaviors such as pagination, range limits, or error conditions. Given the annotations, a 3 is appropriate—it adds some value but does not go beyond what annotations already imply.

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 moderately concise: it leads with the core purpose, then provides a structured parameter breakdown and a return type note. It avoids fluff and each sentence contributes. The numbering and bullet-like format make it scannable. It could be slightly more succinct, but it is not excessively verbose.

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 tool's complexity (date range, nutrient selection, response format), the description covers the main aspects: what it does, parameters, and return type. However, it omits the date format (YYYY-MM-DD) which is present in the schema but not highlighted in the description—significant given low schema coverage. It also does not mention potential limitations like maximum date range or behavior when no data exists. Overall it is adequate but has gaps.

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 schema description coverage is reported as 0%, so the description must compensate. It explicitly lists all parameters (report_name, start_date, end_date, response_format) with types and defaults, and provides concrete examples for report_name ('Net Calories', 'Protein'). It also states the response_format values. While it does not include the date format pattern (which is in the schema), the description covers essentials well enough for an agent to call the tool correctly.

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 states the tool's purpose: 'Get a nutrition report over a date range' and specifies it returns 'daily values for the specified nutrient/metric'. This is a specific verb+resource construction that distinguishes it from sibling tools like mfp_get_diary (which likely returns raw diary entries) and mfp_get_measurements (body metrics). The phrase 'analyzing trends and patterns' adds context.

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 gives only a vague use case ('Useful for analyzing trends and patterns in nutrition intake') but does not explicitly state when to use this tool over alternatives, nor does it mention when not to use it. It provides no comparison with sibling tools like mfp_get_diary or mfp_get_goals, leaving the agent to infer selection criteria from the purpose 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?

Annotations already disclose readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond that: the value is always in millilitres regardless of the account's UI unit setting, and it cites the underlying endpoint field name as evidence. This is useful context not available from annotations or 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?

The description is front-loaded with its purpose, and the millilitre clarification earns its place because it prevents unit confusion. The internal reference to 'python-myfitnesspal's _get_water' is mildly unnecessary for an AI agent but does not detract significantly from clarity.

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 single-parameter read-only getter, the description is complete: it specifies input format, default behavior, return shape, and unit semantics. The annotations cover safety, and the return description covers what the agent needs to interpret the result. Minor missing details like error behavior or zero-intake handling are not critical here.

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 only parameter, date, is already fully described in the schema with format and default behavior. The description repeats that information but adds no new semantic detail. Since the schema covers this parameter well, the baseline 3 is appropriate.

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 ('Get water intake') and qualifies it with 'for a specific date', which distinguishes it from write operations like mfp_set_water. It is immediately clear what this tool does and how it differs from its siblings.

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

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

The intended use is implied by 'Get water intake for a specific date' and the readOnlyHint annotation. However, it never explicitly names alternatives or gives when/when-not guidance, such as 'use mfp_set_water to log water' or 'use mfp_get_diary for broader daily data'.

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 cover read-only, idempotent, and non-destructive behavior. The description adds useful context: ordering (newest first), scope (the user's own custom foods), and return contents (id, description, brand, calories). 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?

The description is compact and front-loaded: a clear one-sentence purpose, a useful routing hint, then explicit args/returns. Every sentence earns its place with no redundancy.

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 read-only list tool it covers why to use it, how it differs from a sibling, ordering, and return fields. Parameter details are in the schema and safety is covered by annotations, so nothing essential 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?

The description only names the parameters (search, limit, response_format) without adding semantic detail, but the schema already documents each parameter's meaning. Therefore the description adds no extra value beyond the schema, matching the baseline for well-documented 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?

States a specific verb and resource: 'List the user's own custom foods, newest first.' It differentiates from mfp_search_food by explaining that private custom foods do not reliably surface there, so agents can tell exactly when this tool is the right lookup.

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 says when to use this tool: when private custom foods don't surface in mfp_search_food and to find the id of something previously created. It names the sibling alternative and the condition that selects it.

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 indicate a write operation (readOnlyHint=false) and non-idempotency (idempotentHint=false). The description adds behavioral details beyond these annotations: it states a new entry is created, explains the UUID generation behavior (matches iOS conventions), and reveals the return structure. It does not contradict annotations and provides useful context about id handling and output format.

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 concise and well-structured: a clear purpose sentence, a behavioral note about id and future modification, then an Args/Returns block. Every sentence serves a purpose, and the most important information (what it does and the id contract) is front-loaded. No fluff or unnecessary 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 straightforward create operation, the description covers the essential points: action, id handling, and return format. It doesn't mention error conditions or prerequisites (e.g., authentication), but the annotations and schema cover the safety and parameter constraints. Given the tool's simplicity, this is adequately 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?

The description lists parameter names (fast_started, fast_ended, id?, response_format) but provides no substantive semantic details beyond what the schema already contains. The schema itself has rich descriptions for each parameter (e.g., ISO 8601 format, UUID pattern, required ordering). Since schema description coverage is 0% per the signal, the description was expected to compensate, but it does not meaningfully add to parameter understanding—only the id generation note, which is also in the 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 clear action: 'Log a completed intermittent fasting window in MyFitnessPal.' It specifies the verb (log), the resource (intermittent fasting window), and the system (MyFitnessPal). It also mentions creating a new entry and explicitly notes that the returned id is used by mfp_update_fast and mfp_delete_fast, distinguishing this tool from its sibling update/delete tools.

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 when to use this tool (to log a new completed fast) and provides a clear link to the update/delete tools by stating the returned id is what those tools accept. However, it does not explicitly contrast with alternatives like mfp_log_meal or state conditions for choosing this over them, so it is clear but not fully explicit.

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 this as destructive, and the description reinforces that with 'Remove (delete)'. It adds valuable behavioral context beyond the annotations: the ID provenance caveat ('NOT a food_entry_id from the diary page'), the safety cap meaning of max_matches, case-insensitive matching, and that the return is a JSON describing removed entries.

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 organized into purpose, two modes, args, and return. Every sentence contributes useful information; there is no filler. The front-loaded purpose and mode breakdown make it easy to scan while preserving necessary 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?

The description fully covers mode selection, parameter semantics, default behavior, matching semantics, and return value for this destructive operation. Given the output schema exists and annotations mark destructiveness, nothing an agent needs to call this tool correctly 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?

Even though the schema already has property descriptions, the tool description adds crucial meaning: it explains that entry_id is the UUID returned by mfp_add_food_to_diary, clarifies how name_contains works, states max_matches acts as a safety cap with default 1, and notes the date default. This meaningfully exceeds the schema's bare descriptions.

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: 'Remove (delete) one or more food entries from your diary.' It then clearly distinguishes two operation modes (precise by entry_id, fuzzy by name_contains), making it easy for an agent to tell this apart from related tools like mfp_delete_meal.

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 gives explicit guidance on when to use each mode: 'Use this when you already know the ID' for entry_id, and describes the fuzzy matching flow for name_contains. It does not explicitly contrast against sibling tools such as mfp_delete_meal, but the internal mode selection guidance is strong and unambiguous.

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?

The annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by specifying exactly what the search returns (name, brand, serving size, calories, MFP ID) and how the limit defaults to 10, which goes beyond the annotation metadata.

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 well-organized with an opening purpose sentence followed by compact Args and Returns sections. It is not bloated, though some of the parameter details duplicate what the input schema already states. Overall it is efficient and scannable.

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 search tool with an output schema and strong annotations, the description is nearly complete: it explains what is returned, names the linked detail tool, and documents all parameters. It could be slightly stronger with explicit notes on empty results or limit cap, but nothing critical 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?

The context signal reports 0% schema description coverage, so the description must carry the parameter-documentation burden. It does so by listing query, limit, and response_format with types, defaults, and a concrete example ('chicken breast'). It also adds semantic value by explaining the returned MFP ID's downstream use.

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 ('Search') and names the exact resource ('MyFitnessPal food database'). It also lists the output fields and explicitly distinguishes itself from the detail-retrieval tool mfp_get_food_details by stating the returned MFP ID is for that tool.

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 gives clear context: use this tool to search for food items and then use mfp_get_food_details for details. It does not explicitly state when not to use it or mention alternatives like mfp_list_own_foods, but the intended flow is clear enough for an agent to select it correctly.

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 cover idempotency, non-read-only, and non-destructive behavior. The description adds valuable behavioral context beyond those annotations by explicitly stating that only provided values are updated and others remain unchanged, plus noting the confirmation string return.

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 well-structured with a clear opening statement, partial-update caveat, labeled Args section, and Returns section. Every sentence adds useful information without redundancy or bloat.

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 update tool with four optional fields, the description provides sufficient information: what is updated, the partial-update behavior, parameter meanings, and return type. The main missing piece is guidance about which sibling should be used instead, but the core calling context is adequately covered.

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 reported as 0%, so the description must compensate. It lists all four parameters with their types, optionality, and units (grams where applicable). This meaningfully helps an agent understand what each parameter controls, even though the nested schema also contains similar descriptions.

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 verb ('Update') and resource ('daily nutrition goals' for calories, protein, carbs, fat). It is clear and specific, but it does not explicitly distinguish itself from similar sibling tools such as mfp_set_nutrient_goals or mfp_get_goals.

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 guidance on when to use this tool versus alternatives like mfp_get_goals or mfp_set_nutrient_goals. The partial-update behavior is described, but no explicit when/when-not conditions or alternatives are mentioned.

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 set readOnlyHint=false and destructiveHint=false, so the write nature is known. The description adds the 'for today' temporal constraint, which is useful. However, it does not disclose what happens if a measurement already exists for today (overwrite vs. duplicate), nor any permission/authentication nuances. Since the description does not contradict annotations, a 3 is appropriate.

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 compact: two introductory sentences plus a structured Args/Returns section. The phrase 'Records the measurement value in MyFitnessPal for tracking progress' is slightly redundant with the first sentence, but it adds context about where data goes. No fluff, and the essential info is front-loaded.

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 tool with an output schema, the description covers purpose, params, and return format. It omits edge cases (e.g., handling duplicate logs) but those are minor for a straightforward logging action. The output schema covers return values, so no need to detail them. Overall, an agent can call this correctly based on the description alone.

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 Args block explicitly lists 'measurement' with default 'Weight' and 'value' with an example (185.5). Even though the schema properties have descriptions, the context signal indicates 0% coverage, so the description compensates well. It clarifies the value is the numeric measurement and that measurement type is optional with a default. This adds meaning beyond the schema's JSON structure.

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 states 'Log a new body measurement (weight, body fat, etc.) for today.' It identifies the verb (log), the resource (body measurement), and the scope (today). Among 30+ sibling tools, this is distinct from set_water, set_goals, and log_exercise, so an agent can easily differentiate it 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?

The description implies the use case: recording a measurement for today. It gives no explicit when-not-to-use or alternatives, but the context is clear enough given the sibling names (e.g., get_measurements for reading). A small gap: it does not mention scenarios like replacing an existing entry.

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?

Beyond the annotations, the description reveals that this tool 'sets the number of cups' for the day, implying an assignment/overwrite behavior rather than an additive log. It also adds the useful unit conversion (1 cup ≈ 237 ml), which helps the agent interpret values correctly.

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 front-loaded with the core purpose, followed by compact args and returns sections. It is reasonably sized with no wasted prose, though the args list partly duplicates the schema.

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 mutation tool, the description covers what it does, the parameters, defaults, and return value. The schema additionally provides bounds and enum-free types, so an agent has enough context to call it correctly. A minor gap is that it does not explicitly discuss replacing prior water entries for the same date.

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 description enumerates both parameters, their expected types, the date format, and the default behavior. Even with the schema documenting similar details, the description adds the unit conversion context and restates the schema semantics in a directly actionable form.

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 states the specific action ('Log water intake') and resource ('for a specific date'), plus the unit of measurement. It is unambiguous relative to read-only siblings like mfp_get_water, but it does not explicitly name or contrast any alternative tool.

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 implicitly tells the agent when to use it: when the goal is to log or set daily water intake. However, it provides no explicit guidance about alternatives or when not to use it, leaving the decision 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?

Annotations already indicate readOnlyHint=false (mutation), destructiveHint=false, and idempotentHint=true. The description adds substantive behavioral details: PATCH is a full replacement of both time fields, and the id sourcing constraint (no list endpoint). These go beyond the annotations and are critical for correct invocation, giving the agent a clear picture of the tool's inner workings.

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 succinct and well-organized. It leads with the purpose, then explains the PATCH behavior and id sourcing in separate concise paragraphs, followed by Args and Returns sections. Every sentence contributes essential information without redundancy. The structure makes it easy for an agent to parse and act on.

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 mutation tool with no read endpoint, the description covers all necessary context: what it does, an important behavioral caveat, how to obtain the required id, and the return value. Even without an output schema shown, the description mentions the return format. The tool is fully contextualized for an agent 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?

The schema already provides descriptions for each property (id, fast_started, fast_ended, response_format). The description reinforces the key semantic: both fast_started and fast_ended are mandatory and must be supplied together due to PATCH replacement. It lists the parameter names but does not add per-field explanations beyond what the schema offers. However, the PATCH note significantly clarifies how to set the time parameters, so the description adds value.

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 states the tool's action: 'Update an existing fasting entry's start and end times.' It specifies the verb, resource, and fields, and distinguishes it from sibling tools like mfp_log_fast (create) and mfp_delete_fast (delete). The purpose is unambiguous and immediately understood.

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 provides critical usage context: it explains that both time fields must be supplied due to PATCH's full-replacement semantics, and it notes the MCP cannot list fasts, so the id must come from a prior mfp_log_fast call or app capture. This informs when and how to use the tool, though it does not explicitly contrast with alternatives like mfp_delete_fast. Still, the guidance is practical and valuable.

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. It discloses the main behavior (extract and save cookies), the browser-scanning logic, the difference for Firefox, and the return format. However, it does not mention potential side effects like overwriting existing cookies, permissions required, or failure modes (e.g., browser locked). It is honest about what it does but lacks depth on caveats.

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 well-organized with explicit 'Args' and 'Returns' sections, and it front-loads purpose and usage. It is a bit long due to the browser option list, but every sentence is informative. Slightly more compact could be achieved with a table, but current structure is clear and scannable.

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 tool's simplicity (single optional parameter), the description covers what the tool does, when to use it, prerequisites, all parameter choices, and a basic return description. It does not detail error conditions or edge cases (e.g., what happens if no browser is found), but it is adequate for the tool's complexity. The existence of an output schema mitigates the need for richer return details.

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 schema only defines 'browser' as a string with a default, with 0% coverage. The description fully compensates by listing all valid options ('auto', 'arc', 'chrome', etc.), explaining what 'auto' does, and noting the Firefox difference. This adds critical meaning beyond the bare schema, making it easy for an agent to choose the right value.

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 immediately states the action ('Extract and save session cookies') and the resource ('from your web browser'), and ties it to a specific trigger (authentication fails for MyFitnessPal). This clearly distinguishes it from all sibling tools, which are all MFP data operations. The verb and resource are explicit and unambiguous.

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 explicitly states when to use: 'Use this tool when authentication fails and you need to refresh your MyFitnessPal session.' It also gives a prerequisite (must be logged into myfitnesspal.com). It does not mention alternatives or when not to use, but since there are no similar sibling tools, the context is sufficient. Lacks explicit exclusions, so not a full 5.

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