MyFitnessPal MCP

by thesaaspreneur

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools target distinct resources (diary, foods, meals, exercises, water, measurements, goals, fasting), and descriptions are detailed enough to prevent confusion. A few near-boundary pairs exist—mfp_set_goals vs mfp_set_nutrient_goals and mfp_create_meal vs mfp_create_recipe vs mfp_create_custom_food—but their descriptions clarify the differences.
Naming Consistency4/5
The overwhelming majority follow the mfp_verb_noun pattern with clear verbs like get, set, create, delete, log, and search. Minor deviations include refresh_browser_cookies (no mfp_ prefix) and bulkier constructions like mfp_add_food_to_diary / mfp_remove_food_from_diary and the slightly odd mfp_bulk_log, but the overall pattern remains predictable.
Tool Count2/5
At 33 tools, this server exceeds the 25+ threshold that indicates a bloated surface, even for a broad fitness-tracking domain. The toolset covers many features, but the count is heavy and includes legacy-tagged tools, settings tweaks, and maintenance operations that could likely be consolidated.
Completeness4/5
The server offers unusually deep coverage: diary CRUD, custom food CRUD, meals, recipes, exercises, water, measurements, goals, and fasting. Minor gaps exist—diary entries can be added/removed but not updated in place, and fasting entries cannot be listed—but agents can work around these in most workflows.
Average 4/5 across 29 of 33 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that the operation is non-read-only, non-destructive, idempotent, and open-world. The description adds no additional behavioral context (e.g., side effects, permission requirements, or impact on diary data). It does not contradict annotations, but also does not go beyond them, so a baseline score of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the core purpose and includes a helpful example. The '[stable]' marker is extraneous but harmless. There is no waste; information is front-loaded and directly actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setting tool, the description covers the essential purpose, and the output schema and annotations handle return values and safety. However, it does not mention any edge cases (e.g., invalid nutrient names, behavior when fewer than 6 are provided) or note that the operation only changes the diary view. Still, given its simplicity and available schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. However, it only mentions 'up-to-6 nutrients' and gives an example, without listing valid values or explaining constraints. The schema itself does provide a list of nutrient IDs, but since coverage is 0% per context, the description fails to adequately explain parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Choose') and the resource ('nutrients shown in the diary'), and gives a concrete example ('swap Sugar for Fiber'). It is unambiguous what the tool does, though it does not explicitly contrast with sibling tools—none of which are directly similar, so this is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It does not mention related tools like mfp_set_nutrient_goals or mfp_set_goals, leaving the agent to infer usage context. This is a clear omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clarifies that the tool logs all meal foods together in one call, which is useful beyond the raw annotations. However, it doesn't disclose whether repeated calls duplicate entries or whether logging replaces an existing meal for that diary day.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with a stability tag. The action and target are front-loaded, and every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema and annotations provide enough for a basic invocation, but the description is thin on choosing between this and closely related siblings like mfp_add_food_to_diary or mfp_bulk_log. Given the large sibling set, the missing routing and side-effect context makes this only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains no parameter-level guidance, but the input schema documents the important semantics: food_id source, servings units, date format/default, allowed meal names, and response_format. Since the schema covers these details, the missing parameter info in the description does not create a major gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Log') and names the exact resource ('a meal's foods to a diary day'), which clearly conveys the core action. It does not explicitly contrast itself with mfp_add_food_to_diary or mfp_bulk_log, 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.
Usage Guidelines2/5
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 mfp_add_food_to_diary (single food) or mfp_bulk_log, nor any exclusions or prerequisites. 'In one call' hints at batching, but the description never states when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the description adds limited behavioral context beyond confirming it deletes a saved meal by ID. The '[stable]' tag adds a small amount of contract stability context, but no detail about cascading effects, permissions, or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant words. It communicates the action, resource, and identifier method efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-required-parameter delete tool, the description plus annotations and schema are largely sufficient. The main missing piece is explicit usage guidance or prerequisites, but the schema's meal_id description and the tool name cover most operational needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions deleting 'by id' and says nothing about the response_format parameter. The schema itself supplies the meal_id source, but the description does not explain either parameter's role or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Delete a saved Meal by id.' This clearly distinguishes it from sibling tools that list, create, log, or rename meals. The verb and object are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, or on prerequisites such as obtaining the meal_id via mfp_list_meals. The description simply states what the tool does, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: calories are considered required by MFP, and when omitted they are computed using the same METs x body-weight x hours formula as MFP's client. The '[legacy]' marker also signals that this tool may be deprecated. This is valuable context for an agent deciding whether the tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by the most important behavioral detail about calories. Both sentences earn their place, with no redundant filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the annotations indicate a non-read-only, non-idempotent operation, the description covers the main unique ground: legacy status and calorie computation. It could be more complete by pointing to a recommended alternative or mentioning the need to first search for an exercise_id, but the schema already notes the exercise_id source.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes most fields, and the description contributes one useful clarification for the calories parameter: the exact auto-computation formula and MFP's conceptual requirement. This is incremental but limited to a single parameter; no additional meaning is added for date, minutes, exercise_id, or response_format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Log a cardio/strength exercise to the diary.' This clearly identifies the operation and distinguishes it from meal, food, measurement, and fast logging siblings. It does not explicitly name alternatives, so it misses the top score, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to choose this tool over related tools such as mfp_log_meal, mfp_bulk_log, or mfp_add_food_to_diary. The only context is the '[legacy]' flag, which hints that there may be a newer alternative but does not name it. The calorie note is about parameter behavior, not use-case selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate mutability (readOnlyHint=false), non-idempotency, and non-destructiveness. The description adds the behavioral nuance of logging identical foods across many dates, but nothing about overwrite behavior, validation, or side effects beyond that. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. The [stable] marker is a useful addition and the statement is appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutating bulk operation with nested input, but the detailed schema, annotations, and presence of an output schema make it callable. The description is terse and does not note edge cases like maximum dates, overwrite semantics, or per-date failure behavior, though these may be covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself mentions no parameters, but the input schema provides detailed semantics for foods, servings, dates, meal, and response_format. The description adds no additional parameter meaning, so it relies fully on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('log') and resource ('the same foods'), with a clear scope ('to many days at once'). This distinguishes it from single-day siblings like mfp_add_food_to_diary without requiring the agent to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario: when the same foods need to be logged across multiple days. However, it does not explicitly mention alternatives or when not to use this tool, leaving some 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the output scope ('foods and ids') and a stability marker, but provides no additional behavioral context such as ordering, pagination, or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with the action and key output front-loaded, followed by a concise stability tag. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 with one self-documenting optional parameter, a rich output schema, and comprehensive annotations, the description is largely sufficient. It could be more complete with explicit alternative routing, but nothing essential to invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: the description does not mention the response_format parameter or explain how to choose markdown vs json. Although the schema itself fully documents the parameter, the description does not add meaning beyond the schema as required when coverage is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('List'), resource ('your saved Meals'), and includes the key return fields ('their foods and ids'). This distinguishes it from siblings like mfp_list_own_foods, which lists custom foods, and mfp_get_diary, which lists diary entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'List your saved Meals' implies the tool is for retrieving previously saved meals, but it does not explicitly state when to prefer it over related tools or mention exclusions. No alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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 context beyond annotations by stating the exact output tuple and the legacy status. It does not contradict any annotation, so it earns credit for the added behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loaded: it states the action, resource, return shape, purpose, and legacy status in two short sentences. Every word earns its place, and nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search tool, the description plus annotations and schema are mostly sufficient. It states the return value, and the schema covers input parameters; the main missing piece is a clear alternative or migration path given the '[legacy]' flag, but that is not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level meaning: it never mentions query, exercise_type, or response_format, and it does not explain how to construct a valid search. With the reported schema description coverage at 0%, the description fails to compensate for the lack of parameter documentation. The nested schema partially rescues the situation, but the description itself carries none of this burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Search'), a specific resource ('MFP's exercise database'), and explicitly states the returned fields ('exercise_id, name') and their purpose ('for logging'). This clearly distinguishes it from sibling tools like mfp_get_exercises or mfp_search_food without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for logging' implies this is a lookup step before logging an exercise, and the '[legacy]' tag signals deprecation. However, it never explicitly states when to use this tool instead of alternatives, nor does it name a replacement, which is especially important given the large sibling set and the legacy marker.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a multi-step behavior beyond the annotations: it stages foods in the diary, saves them via MFP's 'Remember a Meal' flow, clears the scaffolding, and returns the meal_id. It also marks the tool as '[legacy]'. This gives the agent a clear picture of side effects and expected return value, which is significant for a mutating tool with no idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then gives the operational flow in two short sentences. The '[legacy]' tag and returns clause earn their place. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-trivial mutation, the description covers the operational mechanism and return value, and annotations give safety hints. It does not mention prerequisites such as needing an existing food_id from mfp_search_food, but the schema already notes that. The main gap is the lack of any caution about the temporary diary staging or the legacy status implications, though these are minor given the behavioral detail already present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself does not explain parameters, but the input schema provides detailed descriptions for name, foods, food_id, servings, and response_format. While the context signal claims 0% schema description coverage, the actual schema text contradicts that and appears to cover the parameters well. Since the description adds no parameter-specific value and the schema carries the load, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a reusable saved Meal from existing foods.' It clearly conveys that the tool creates a meal rather than logs one, distinguishing it from related tools like mfp_log_meal or mfp_create_custom_food. However, it does not explicitly name or differentiate against siblings, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'reusable saved Meal' implies the tool should be used when the goal is to create a named, reusable meal rather than simply log foods. There is no explicit when-to-use, when-not-to-use, or mention of alternatives such as mfp_log_meal or mfp_create_recipe. Guidance is therefore 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it creates a new custom food, computes summed per-portion nutrition, and returns a recipe food id that can be logged/edited. The annotations already cover non-read-only and non-idempotent side effects, and the description does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences front-load the core purpose and end with a practical output-use hint; the [stable] marker is compact metadata. There is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool creates, how nutrition is computed, and what the return value is for, while the annotations and nested input schema cover safety and parameter requirements. It is slightly short on explicit alternative selection, but for a create-with-recipe workflow the core context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not name parameters directly, but 'multi-ingredient' and 'per-portion' reinforce the meaning of ingredients and portions. The nested schema carries detailed descriptions for name, ingredients, portions, and food_id, so the description's contribution on top of the schema is modest; given the reported low direct schema coverage, it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Create'), a specific resource ('multi-ingredient recipe as a custom food'), and the key behavior ('summed, per-portion nutrition'). It also tells the agent what to do with the result ('log/edit it like any food'), which distinguishes it from sibling tools like mfp_create_meal and mfp_create_custom_food.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: a recipe is for combining multiple foods into a custom food, and returning a food id signals reusability. However, it never explicitly says when to prefer this over mfp_bulk_log, mfp_create_meal, or mfp_create_custom_food, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description openly discloses that the action deletes all exercise entries on a date, which is important destructive behavior. This aligns with the annotations (destructiveHint=true, readOnlyHint=false). It adds the useful warning that the deletion is scoped to an entire day's entries, not just one selected entry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description is one compact, front-loaded sentence with no filler. The '[legacy]' flag is a meaningful addition rather than noise, and the resource-action-scope structure makes the intent immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool, the description plus annotations are mostly sufficient: the action, scope, and destructive nature are clear, and the output schema covers return expectations. The only noticeable gap is that it does not explicitly mention irreversibility, but destructiveHint=true already communicates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the date format and default ('YYYY-MM-DD', defaults to today) and the response_format enum with its markdown/json choices. The description's reference to 'date' is consistent but does not add meaningful parameter detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Delete all exercise entries logged on a date.' It clearly identifies scope (all entries, not a single entry) and differentiates the tool from sibling tools like mfp_delete_meal or mfp_delete_custom_food. The subject matter is immediately obvious from the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you want to remove every exercise entry for a specific day. However, it does not explicitly state when not to use it, and the '[legacy]' marker hints that the tool may be deprecated without naming a successor or alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the tool's safety profile is known. The description adds valuable behavioral specifics: it uses PATCH, preserves the food id, and only changes provided fields. This goes beyond the annotations and gives the agent confidence about partial updates and state preservation. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose and a stability marker, followed by the key behavioral nuance. No filler words, and every clause adds value. Perfectly structured for scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters and a low schema coverage, the description is too thin to be fully self-sufficient. It does not mention that the food must be from the user's own list (though the schema hints via 'from mfp_list_own_foods'), nor does it explain error cases like a missing food_id, or the return format. Annotations carry some weight but the description could be richer to cover these gaps. It's adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context signals, so the description must compensate for parameter meanings. However, it only gives a general rule ('Only the fields you pass are changed') without explaining that null means 'no change' or detailing what each field (e.g., fat, carbs, brand_name) represents. The schema has minimal descriptions for a few fields, but the description itself adds almost no per-parameter semantics, leaving the agent to infer from names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Edit' and the resource 'custom food', and adds the critical scoping phrase 'IN PLACE' which distinguishes it from creating or deleting. It also mentions the food id is preserved, which differentiates it from a create operation. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need to modify an existing custom food while keeping its identity) without explicitly naming alternatives. It states that only passed fields change, which guides partial updates, but does not explicitly compare with create or delete tools. Still, the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (not read-only, idempotent, not destructive), so the description only needs to add context. It adds the default-slot mapping and a '[stable]' note, but does not disclose effects on existing diary entries or whether renamed slots are persisted beyond the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. The key action, resource, and transformation are all immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename operation with full annotations and an output schema, the description covers the essential semantics. The main gap is the lack of explicit usage guidance and side-effect detail, but the schema and annotations account for most operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies that the 'names' array should replace the default diary meal-slot labels and provides the default-to-custom mapping that the bare schema does not fully express. The optional 'response_format' parameter is left to the schema, but the main parameter's semantics are meaningfully enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Rename') and a clear resource ('the diary meal slots') with a useful transformation mapping ('Breakfast/Lunch/Dinner/Snacks -> your own'). This distinguishes it from sibling tools like mfp_list_meals, mfp_create_meal, or mfp_log_meal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it evident that the tool is for renaming diary meal-slot labels, but it does not explicitly state when to prefer it over alternatives or when not to use it. Usage context is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover mutation (readOnlyHint false), idempotency, and non-destructiveness. The description adds a meaningful behavioral caveat: MFP recomputes fiber from calories so custom fiber values are ignored. It also marks the tool as [stable]. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences plus a focused note. The primary purpose is front-loaded and the fiber caveat is placed where it is most useful. No filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety, the description is mostly adequate. But the missing semantics around null values and units, plus the absence of any mention of response_format, leave meaningful gaps for an agent trying to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate. It does not explain units (grams vs milligrams), the meaning of null defaults (leave unchanged vs set to zero), or how to interpret the integer minimums. Field names are self-explanatory but this is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with a specific verb and resource: 'Set daily goals for ANY nutrient across every weekday.' The phrase 'not just the 4 macros' explicitly differentiates this tool from macro-focused siblings, giving agents a clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for use (setting nutrient goals across weekdays) and an explicit when-not/alternative for fiber: 'use mfp_set_tracked_nutrients to surface fiber.' However, it does not fully delineate when to prefer the sibling mfp_set_goals for basic macro/calorie goals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply readOnlyHint=false and idempotentHint=false, so the description carries the burden of explaining behavior. It adds meaningful detail: the tool writes to the user's MFP account, fills the full nutrition panel, returns the new food's id, and has a non-obvious net-carbs caveat verified with concrete examples. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary action, then covers nutrition scope, endpoint behavior, return value, the carb gotcha, and the alternative correction path. The length is justified by the complexity, and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers auth requirements, return values, the relationship to sibling tools, and the most important parameter trap. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The nested schema already documents each field with units, so the description does not need to repeat them. The prose adds load-bearing semantics beyond the schema: default country_code='NL' means carbs are net, fiber must not be pre-added, and the field affects stored values materially. The Args listing is only a name list, but the critical parameter knowledge is present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a private custom food in the user's MyFitnessPal account.' It also distinguishes itself from related tools by referencing mfp_add_food_to_diary and mfp_edit_food.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly routes corrections to mfp_edit_food and explains that the returned id is accepted by mfp_add_food_to_diary. It also notes that the cookie-authenticated endpoint requires no running browser, giving the agent practical context for when this tool can be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![myfitnesspal-mcp MCP server](https://glama.ai/mcp/servers/thesaaspreneur/myfitnesspal-mcp/badges/card.svg)](https://glama.ai/mcp/servers/thesaaspreneur/myfitnesspal-mcp)

Score Badge

Copy to your README.md:

[![myfitnesspal-mcp MCP server](https://glama.ai/mcp/servers/thesaaspreneur/myfitnesspal-mcp/badges/score.svg)](https://glama.ai/mcp/servers/thesaaspreneur/myfitnesspal-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/thesaaspreneur/myfitnesspal-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server