MyFitnessPal MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action: diary retrieval, food search, food details, measurement get/set, exercise get, goals get/set, water get/set, report, custom food CRUD, and fast CRUD. The closest pair is mfp_get_diary and mfp_get_report, but they serve clearly different purposes (daily meals vs. trend over a range).
Naming Consistency4/5
The vast majority use the consistent mfp_<verb>_<object> pattern with clear verbs (get, set, add, remove, create, list, delete, log, update). The only exception is refresh_browser_cookies, which lacks the mfp_ prefix but is clearly an auth utility, so it is a minor deviation.
Tool Count4/5
20 tools is on the high end, but the domain is broad: diary, food database, measurements, exercises, goals, water, custom foods, and fasting. Each tool has a clear purpose, though some get/set pairs (e.g., water, measurements) could theoretically be combined. Overall it feels reasonably scoped for a comprehensive MFP client.
Completeness3/5
Core workflows are covered, but there are notable gaps: no way to update or edit diary entries (only add/remove), no tool for logging exercises (only reading them), and no read endpoint for fasting entries (though MFP itself lacks this). Custom food CRUD lacks update due to platform limitations. Agents will need workarounds for these missing operations.
Average 4.3/5 across 20 of 20 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 4 community issues answered or closed in the last 6 months
- 20 commits 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds return-value details ('daily values and summary statistics') and date-range scoping, but no additional behavioral caveats. There is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary action and is generally efficient. It is slightly redundant, stating 'Returns daily values' in the opening and again in the 'Returns' section, but overall it is concise 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 report tool with rich schema and annotations, the description adequately covers purpose, usage, and return nature. It does not enumerate all possible report names or error scenarios, but the openWorldHint and existing schema reduce the need for more detail.
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 nested schema already provides descriptions for all parameters, including defaults and examples (e.g., report_name examples, date formats, response_format). The description restates these without adding new semantic meaning, so it adds little beyond the existing structured metadata.
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 tool's function: 'Get a nutrition report over a date range' and specifies it returns daily values for a selected nutrient/metric. However, it does not explicitly differentiate from sibling tools like mfp_get_diary or mfp_get_measurements, though the emphasis on 'analyzing trends' hints at its distinct role.
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 a usage context: 'Useful for analyzing trends and patterns in nutrition intake,' which tells the agent when to choose this tool. It does not mention alternatives or exclusion criteria, so it stops short of full guidance.
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 and idempotentHint, and the description adds that it returns 'configured daily targets for all tracked nutrients,' which clarifies scope. However, no additional behavioral details like error handling, rate limits, or warning about missing goals are provided. With annotations covering safety, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured but includes an Args section that duplicates schema information, making it slightly redundant. It is not excessively long but has unnecessary repetition, so it doesn't earn a higher score.
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 good annotations and schema coverage, the description is mostly complete. It specifies the return type (str), the default date behavior, and the scope (all tracked nutrients). It doesn't detail edge cases, but those are not critical for a simple getter.
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 provides descriptions for both date and response_format, so the description's Args section adds no new meaning. The description mentions date defaults to today, but that is also in the schema. 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 uses a specific verb ('Get') and resource ('daily nutrition goals'), listing nutrient types and stating it returns configured targets for all tracked nutrients. This clearly distinguishes it from sibling tools like mfp_set_goals and other getters.
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 'get' vs 'set' contrast with sibling tools makes the usage context clear, although no explicit alternatives are named. The description implies this is the read-only tool for retrieving daily goals, but does not mention when not to use it or exceptions.
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, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds return field details and format options but does not disclose additional behavioral aspects like search matching logic or pagination.
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 clear sections (purpose, returns, args, returns) and front-loaded with the main purpose. However, it redundantly repeats parameter information already available in the schema, adding slight waste.
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, the description covers purpose, return content, format options, and links to the related details tool. It lacks error-condition notes but is otherwise sufficiently complete.
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 schema description coverage at 0%, the description's Args section fully compensates by listing query, limit, and response_format with types, defaults, and examples, providing clear meaning beyond parameter names.
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 states 'Search the MyFitnessPal food database for food items' with a specific verb and resource, and clarifies it returns matching items with basic nutrition info. This distinguishes it from sibling tools like mfp_get_food_details.
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 it is used for searching foods and mentions the MFP ID can be used with mfp_get_food_details, but it does not explicitly state when to use this tool over alternatives or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation is a non-readonly, idempotent, non-destructive write. The description adds the key behavior that unspecified values remain unchanged (merge semantics), which is not captured in annotations. This is valuable context for the agent.
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 purpose, behavioral note, args list, and return type. The args list somewhat duplicates the schema but remains concise and readable, with no unnecessary 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?
The description covers the partial update behavior, parameter meanings, and return type. It does not mention authentication requirements, but this is likely implied for all mfp tools. It is complete enough for a straightforward setter, though it could note the no-op behavior when all params are null.
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 lists each parameter with type and meaning, but the schema already provides detailed descriptions and constraints (e.g., min/max). The description adds no new information beyond the schema and omits the value ranges, making it adequate but not additive.
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 updates daily nutrition goals (calories, protein, carbs, fat) with the verb 'Update' and specifies the resource. It distinguishes itself from siblings like mfp_get_goals (read) and other mfp setters by focusing specifically on nutrition goals.
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 useful partial update semantics ('Only updates the values that are provided; others remain unchanged'), which guides usage. However, it does not explicitly mention when to use this tool versus alternatives like mfp_get_goals or other mfp setters; 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 indicate a write operation (readOnlyHint=false) and non-destructive behavior. Description adds that it returns a confirmation string and depends on a prior search, but does not disclose side effects like potential duplicates or required authentication. This is adequate but not rich.
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?
Well-structured with Args and Returns sections, front-loaded with the main purpose. The first two sentences are slightly redundant ('Add a food item...' and 'This tool adds a food entry...'), but the overall length is appropriate and easily 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?
Covers how to obtain the required food ID, lists all parameters, and describes the return format. Combined with annotations and the output schema, the description gives enough context for correct invocation, though it could mention edge cases like duplicate entries or date handling.
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 tool description goes beyond the schema by enumerating meal options ('Breakfast', 'Lunch', 'Dinner', or 'Snacks'), providing date format examples, unit examples, and explaining that mfp_id comes from mfp_search_food. This helps the agent select correct values even if schema descriptions are minimal.
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 clearly states 'Add a food item to your MyFitnessPal food diary for a specific date and meal,' using a specific verb and resource. It distinguishes from siblings like mfp_get_diary (read) and mfp_remove_food_from_diary (delete), making the tool's purpose 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?
Explicitly points to prerequisite workflow: 'You can search for foods using mfp_search_food to find the food ID (mfp_id) needed for this tool.' This provides clear context for when to use the tool, though it does not mention alternatives or exclusions beyond this.
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 destructiveHint annotation, the description explicitly states 'Destructive and not recoverable' and discloses the failure mode if a food is actively referenced. It also specifies the return type (confirmation with HTTP status). This adds meaningful behavioral context without contradicting 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 main purpose, followed by a concise warning and a structured Args/Returns section. Every sentence adds value, and it avoids unnecessary repetition of the schema.
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 destructive tool with a simple input model, the description covers the essential risks (irreversibility, potential refusal), the input (food_id), and the output format (confirmation with HTTP status). The annotations and schema fill in the remaining details, so no important context 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 mentions 'by id' and lists food_id in the Args section, but adds little beyond the input schema, which already provides detailed descriptions for food_id (source) and response_format. The response_format parameter is not mentioned in the tool description, but the schema covers it adequately.
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 action: 'Delete one of the user's custom foods by id.' It names the specific resource (custom foods) and the method (by id), which distinguishes it from sibling tools like mfp_remove_food_from_diary or mfp_list_own_foods.
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 conveys the use case (permanently deleting a custom food) and includes a caveat that foods referenced by diary entries may be refused. However, it does not explicitly mention alternatives, when not to use it, or suggest a workflow to check diary references first.
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 indicate mutation (readOnlyHint=false) and non-idempotency (idempotentHint=false). The description adds valuable context: it logs a 'new' measurement (implying each call appends), specifically 'for today', and returns a confirmation message. It does not disclose potential duplicate behavior or unit nuances, but the key behavioral traits are conveyed.
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 front-loaded with the primary purpose in the first sentence. It includes a structured Args and Returns section, but the Args block largely duplicates schema information. It wastes no words and is appropriately sized for a simple tool.
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 only two parameters and good annotations, the description is complete: it states the action, scope ('for today'), parameters, and return type. It lacks explicit accepted measurement types or units, but the schema covers those examples. No critical information appears missing for correct invocation.
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 explicitly breaks down the nested 'params' object, listing both 'measurement' (with type and default) and 'value' (with type and example). While the schema already provides descriptions for these sub-parameters, the top-level schema coverage is 0% and the description compensates by clarifying the nested structure, default, and example values, adding meaning for agents unfamiliar with 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+resource ('Log a new body measurement') and clearly differentiates from siblings like mfp_get_measurements (read) and mfp_set_goals (set goals). The scope 'for today' adds precision, making the tool's purpose immediately clear.
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: if you need to log a measurement for today, use this tool. However, it does not explicitly mention alternatives (e.g., mfp_get_measurements for retrieving measurements) or provide when-not-to-use guidance. The phrase 'for today' hints at a constraint but no exclusions are 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?
Annotations already mark the tool as destructive, and the description reinforces this with 'Destructive and not recoverable.' It adds useful context about irreversibility and the inability to list existing fasts, which goes beyond the basic destructiveHint flag.
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 front-loaded. It has a clear purpose sentence, a key warning, id provenance, and a structured Args/Returns block. Every sentence adds necessary information.
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 covers purpose, destructive nature, id provenance, no-list limitation, and return type. It lacks details about error handling or response_format options, but given the simple one-parameter API and output schema (response_format enum), the description is sufficiently 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 Args line only repeats parameter names (id, response_format) without explaining response_format's behavior. The id source constraint is valuable and goes beyond the schema, but given 0% schema description coverage, the description does not fully compensate for the undocumented response_format parameter.
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+resource: 'Delete a fasting entry by id.' This clearly distinguishes it from sibling tools like mfp_delete_custom_food and mfp_update_fast.
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 context on when this tool can be used: it requires an id from mfp_log_fast or the MFP app because no read endpoint exists to list fasts. It does not explicitly name alternative tools, but the no-list constraint is clear usage guidance.
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 non-destructive behavior. The description adds valuable context about the return content (both cardiovascular and strength exercises with details like sets, reps, weight) and notes that response_format controls output style. This goes beyond safety profile and clarifies what the tool actually returns.
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: a one-sentence purpose, a one-sentence summary of return contents, then Args and Returns sections. Every sentence adds information; there is no fluff 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 read-only lookup tool, the description covers the purpose, parameters, and return type. It doesn't mention error behavior or pagination, but the presence of an output schema may cover those aspects. Overall, it is complete enough for a tool of this simplicity.
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 explains that date is optional and defaults to today, and that response_format accepts 'markdown' or 'json'. Given the schema has 0% coverage (per context signals), the description fully compensates by providing meaning and defaults for both parameters. It doesn't mention format constraints like date pattern, but the essential semantics are clear.
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 directly states the action: 'Get logged exercises for a specific date.' It clearly specifies the resource (exercises) and scope (specific date). It also distinguishes itself from sibling tools like mfp_get_diary or mfp_get_measurements by focusing on exercise logs.
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?
Usage context is implied by the description: use this when you need logged exercises for a date. However, there is no explicit guidance on when to use this over alternatives, nor any exclusions. Since it is a simple read tool, the implied context is sufficient for a basic score but not outstanding.
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 non-destructive behavior. The description adds meaningful context beyond annotations by detailing the specific contents of the response (calories, macros, fiber, sugar, vitamins, serving sizes) and the return type. This gives the agent an accurate picture of what to expect.
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 and front-loaded with the core purpose, then expands to output details, arguments, and return value. Every sentence earns its place, and the formatting with sections makes it easy to scan. No redundancy or 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 read-only lookup tool with strong annotations and thorough schema documentation, the description is nearly complete. It explains what data is returned and how to identify the food item. It lacks error handling or edge-case behavior (e.g., invalid MFP ID), but this is minor given the tool's simplicity.
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 schema already provides complete descriptions for both parameters, including the enum for response_format and the meaning of mfp_id. The description's Args section essentially repeats this information without adding new semantics. Since schema coverage is strong, the baseline of 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 clearly states the tool's function: 'Get detailed nutritional information for a specific food item by its MFP ID.' It specifies the exact resource (food item details), the verb (Get), and the identifying input (MFP ID), distinguishing it from sibling tools like mfp_search_food or mfp_get_diary.
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, noting the MFP ID comes 'from search results' and that the output is a full nutrition breakdown. It doesn't explicitly mention alternatives or exclusions, but the workflow implication (search first, then get details) is clear.
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 mark this as read-only, idempotent, and non-destructive. The description adds valuable context: it clarifies the return is always in millilitres regardless of account unit settings, citing the underlying endpoint and library, which is a helpful 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?
Four focused sentences: purpose, unit clarification, args, returns. No redundant filler, and the unit note is essential.
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 tool is simple (one optional param, output schema exists). The description covers purpose, parameter, return format, and a key unit gotcha. No significant 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 input schema has one nested parameter, but description coverage is marked 0%. The description compensates by explicitly documenting the date parameter with format YYYY-MM-DD and default behavior, matching the schema's own description but reinforcing it.
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 'Get water intake for a specific date, in millilitres,' using a specific verb and resource that clearly distinguishes it from mfp_set_water and other getter tools.
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?
No explicit comparison to alternatives or exclusion criteria is provided. The phrase 'for a specific date' implies usage context, but it doesn't mention when to prefer this over mfp_get_diary or other tools.
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=true and destructiveHint=false, so the read-only nature is covered. The description adds useful behavioral context beyond annotations: the 'newest first' ordering, the unreliability of private foods in search_food, and the return fields (id, description, brand, calories). This enhances transparency without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear purpose statement, a brief contextual note, and a compact Args/Returns format. Every sentence contributes essential information, and the structure makes it easy to scan.
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 covers the tool's purpose, ordering, use case, and return format, which is adequate for a relatively simple read-only list operation with strong annotations. It lacks details on pagination or exact output formatting, but the limit parameter and return description cover the essentials. Overall, it is complete enough for correct selection and 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 schema description coverage is 0%, so the description carries the burden of explaining parameters. It merely lists 'search, limit, response_format' without elaborating on their meaning or constraints. Though the schema itself contains descriptions, the description does not add semantic value beyond the parameter names, failing to compensate for the low coverage.
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 'List' and clearly identifies the resource: 'the user's own custom foods,' with an explicit ordering constraint ('newest first'). It distinguishes itself from the sibling tool mfp_search_food by noting that private custom foods do not reliably surface there, making the purpose unmistakable.
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?
The description provides explicit guidance on when to use this tool: 'Private custom foods do not reliably surface in mfp_search_food, so this is the way to find the id of something previously created.' It names the alternative (mfp_search_food) and the specific use case (finding IDs of previously created custom foods), effectively communicating when and why this tool should be chosen.
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 mark the tool as read-only and non-destructive. The description goes further by detailing the return structure (Breakfast, Lunch, Dinner, Snacks with nutrition breakdown), inclusion of daily totals/goals, and support for 'markdown' or 'json' output. It also notes the default date behavior, adding value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections and front-loads the main purpose. However, there is some redundancy: the first paragraph already lists meals/nutrition and daily totals, and the Returns section repeats a summary. It remains reasonably concise, but a tighter wording would earn a 5.
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 report tool, the description covers the essential return content, parameters, and output options. It does not discuss edge cases like empty diaries or errors, but given the simple nature and rich annotations, the provided information is sufficient 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's measured coverage is 0% at the top level (the 'params' wrapper lacks a description), but the tool description explicitly documents both parameters: date (with format and default) and response_format (with allowed values). This fully compensates for the schema gap and gives agents actionable meaning for 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 states 'Get the food diary for a specific date including all meals and their nutritional information.' This clearly identifies the verb (get), the resource (food diary), and the scope (date, meals, nutrition). It also distinguishes itself from sibling tools like mfp_get_measurements or mfp_get_water by focusing specifically on diary contents.
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 by stating the tool retrieves a diary for a given date and defaults to today if no date is given. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous. This qualifies as clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context by stating it returns historical data with dates and values, and it clarifies output format options ('markdown'/'json'). This exceeds the minimum but doesn't fully describe pagination or rate limits, though they are likely not relevant.
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, front-loaded with purpose, then organized into an Args section and Returns statement. Every sentence provides useful information without redundancy.
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 moderate complexity (one nested input object), the description covers all necessary aspects: what it does, what parameters to pass, defaults, and the return type. With output schema present and strong annotations, nothing important 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?
The schema description coverage is 0%, so the description must fully compensate. It does, listing each parameter with its type, default values, and allowed values (e.g., response_format as 'markdown' or 'json'). This is complete and actionable.
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 ('Get'), resource ('body measurements'), and scope ('over a date range'), with examples like weight and body fat. This clearly distinguishes it from sibling tools such as mfp_get_diary or mfp_get_water.
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 a clear use case ('Useful for tracking weight loss progress and body composition changes') but does not explicitly compare with alternatives or state when not to use. It is implied rather than explicit, so it falls short of a 4.
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?
No annotations are provided, so the description carries the full burden. It explains browser scanning behavior, the 'auto' mode, and the Firefox exception, but does not disclose where cookies are saved, whether existing cookies are overwritten, or any side effects. These gaps are noticeable for a tool that 'saves' cookies.
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 summary, usage condition, and detailed args. It is slightly longer than strictly necessary but every sentence adds value, including the 'Firefox is not Chromium' note. Front-loaded with the main purpose.
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 one-parameter tool with no required parameters and an output schema, the description covers the use case, prerequisites, parameter options, and return behavior. The 'Returns: Success message or error description' line provides adequate output 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 schema provides only a default value with no description, while the tool description fully documents every browser option: 'auto' scans all Chromium browsers, specific names force a browser, and 'firefox' uses browser_cookie3. This completely compensates for the 0% schema coverage.
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: 'Extract and save session cookies from your web browser.' It clearly distinguishes itself from sibling tools, which are all MFP data operations, by focusing on browser cookie extraction and session refresh.
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 states when to use: 'Use this tool when authentication fails and you need to refresh your MyFitnessPal session.' It also provides a prerequisite: 'You must be logged into myfitnesspal.com in the target browser.' This is clear and actionable.
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 adds substantial context beyond annotations: it discloses the cookie-authenticated web endpoint (no browser needed), the nuanced net-carbs behavior tied to country_code, the fact that MFP has no update endpoint, and that it returns the food id. This is exactly the kind of behavioral detail that helps an agent avoid errors. No contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every paragraph adds critical information: purpose, nutrition coverage, carb semantics, and update limitation. It is structured with clear paragraphs and an Args/Returns section. Slightly verbose, but each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the nutrition model and the critical country_code behavior, the description covers all essential context: what it creates, how it authenticates, what it returns, and how it relates to other tools. The output schema is present, so return-value details are not needed, and the description still clarifies the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has rich per-parameter descriptions, the tool description adds concrete behavioral detail not in the schema: the verified example of how carbs/fiber store under different country_code values, and the warning 'Never pre-add fiber.' This goes beyond merely listing parameter names, earning an above-baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the action ('Create a private custom food') with a specific resource ('MyFitnessPal account'). It distinguishes from sibling tools like mfp_search_food (searching existing foods) and mfp_delete_custom_food (deleting). The mention of 'private' and 'custom' further differentiates it from diary-logging tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains a key usage pattern: the returned id is accepted by mfp_add_food_to_diary, and because MFP has no update endpoint, corrections require creating a new food and deleting the old one. It does not explicitly state when to avoid using this tool (e.g., if a food already exists), but the context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it's not read-only, not destructive, not idempotent. The description adds useful context: auto-generated uppercase UUIDv4 matching iOS behavior, and the relationship between created id and subsequent update/delete operations. It doesn't contradict 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, front-loaded with the main purpose, and uses clean Args/Returns sections. Every sentence adds value without 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?
The description covers the essential workflow, return value structure, and id handling. Given the rich nested input schema and annotations, it's sufficiently complete for a create tool. It doesn't address error scenarios, but not necessary for this complexity.
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 only has 'params' with no description (0% coverage). The description compensates by listing the nested fields (fast_started, fast_ended, id?, response_format). The nested schema provides detailed semantics for each field, so the description doesn't need to repeat them.
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+resource: 'Log a completed intermittent fasting window in MyFitnessPal.' and further clarifies it 'Creates a new entry'. It clearly distinguishes from siblings like mfp_update_fast and mfp_delete_fast by focusing on creation.
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?
The description explicitly explains that the returned id is accepted by mfp_update_fast and mfp_delete_fast, telling the agent when to use those alternatives for modification. It also implies 'use this to create new entries' clearly.
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 adds useful context: the cups-to-milliliters conversion, the optional date defaulting to today, and the return confirmation. It does not explicitly state whether setting overwrites existing values, but 'set' strongly implies replacement, and there is 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 well-organized with a short intro, an Args block, and a Returns line. Every sentence adds value—unit conversion, default behavior, and return type—with no redundancy or fluff.
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 setter tool, the description covers all essential aspects: what it does, parameter semantics, unit conversion, date default, and the confirmation return. An output schema exists, so the return description is a helpful addition rather than a necessity.
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 Args section fully documents both parameters: cups as a float with an example, and date as an optional YYYY-MM-DD string with a default. This compensates for the opaque top-level params schema and adds practical usage detail.
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 specific verbs 'Log' and 'Sets' with a clear resource ('water intake') for a specific date. It also includes the unit and distinguishes itself from sibling read tools like mfp_get_water.
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 clearly states the action ('Log water intake') and the date default behavior, implying when to use it. However, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the PATCH full-replacement behavior, the limitation that fasts cannot be listed, and the id sourcing constraint, all of which go beyond the annotations' idempotentHint and destructiveHint. This adds valuable context about the underlying API.
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 organized into concise paragraphs with an Args/Returns block. It front-loads the main purpose and uses bullets-like structure. The Args line mildly duplicates schema but is not excessive. Overall efficient.
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 small parameter count, rich schema, and annotations, the description covers purpose, usage constraints, id sourcing, and return value. It is complete enough for an agent to invoke correctly without needing additional 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 schema already provides descriptions for id, fast_started, fast_ended, and response_format. The description adds critical cross-parameter semantics: both time fields must be supplied even if only one changes, and id must come from a prior log call. While it doesn't repeat schema details, the PATCH behavior is essential 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 'Update an existing fasting entry's start and end times', a specific verb+resource statement. It clearly distinguishes from siblings like mfp_log_fast (create) and mfp_delete_fast (delete) by focusing on updating times.
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 that both time fields must be supplied due to PATCH full replacement, and explains that the id cannot be discovered via the MCP since no read endpoint exists; it must come from a prior mfp_log_fast call or the app. This is clear contextual guidance, though it doesn't explicitly name alternatives for creation/deletion.
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 destructiveHint=true, and the description adds critical context: the distinction between the UUID returned by mfp_add_food_to_diary and the food_entry_id from the diary page, the default max_matches=1 for safety, and the return format. This goes well beyond the annotation.
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 clear headings (Two modes, Args, Returns). It is appropriately sized for the tool's complexity, with every sentence contributing either to mode explanation, parameter guidance, or return behavior. No wasted words.
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 destructive nature and two-mode design, the description fully covers usage, parameters, exceptions (NOT a food_entry_id), and return values. The output schema exists, so the brief 'JSON describing each entry that was removed' suffices. No significant gaps remain.
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?
While the schema already has descriptions for each parameter, the tool description adds crucial semantic nuance: it clarifies that entry_id is specifically the UUID from mfp_add_food_to_diary (not the diary page ID), explains the relationship between name_contains and meal, and emphasizes max_matches as a safety cap. This enriches the schema's meaning.
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 'Remove (delete) one or more food entries from your diary.' This is a specific verb and resource, and it distinguishes the two modes (by entry_id vs by name_contains), making it unambiguous among sibling tools.
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?
The description provides explicit guidance on when to use each mode: 'Use this when you already know the ID' for entry_id, and describes the fuzzy matching process with optional meal restriction and max_matches safety cap. This gives clear context for selecting the appropriate approach.
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-python MCP server](https://glama.ai/mcp/servers/AdamWalt/myfitnesspal-mcp-python/badges/card.svg)](https://glama.ai/mcp/servers/AdamWalt/myfitnesspal-mcp-python)

Score Badge

Copy to your README.md:

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

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/AdamWalt/myfitnesspal-mcp-python'

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