MyFitnessPal MCP Server

Overview Schema Source Related Servers Discussions Admin

mfp_create_custom_food

Create a private custom food with complete nutritional data in your MyFitnessPal account. Returns the new food's ID for use in food diary entries.

Instructions

Create a private custom food in the user's MyFitnessPal account.

Fills the full nutrition panel MFP supports (macros, fats breakdown,
cholesterol, sodium, potassium, fiber, sugars, and the four %DV micros).
Uses the cookie-authenticated web endpoint, so no browser needs to be
running. Returns the new food's id, which mfp_add_food_to_diary accepts.

CARBS ARE NET (with the default country_code="NL"): pass net carbs in
`carbs`; MFP stores net_carbs as given and reports total = carbs + fiber.
Never pre-add fiber. Verified: carbs=42/fiber=8 stores 50/42 under "NL" but
42/34 with country_code omitted, so the field is load-bearing, not cosmetic.

MFP has no update endpoint. To correct a food, create the corrected version
then mfp_delete_custom_food the old one.

Args:
    params: CreateCustomFoodInput (description, brand_name, serving_amount,
        serving_unit, calories + optional nutrients, public, response_format)

Returns:
    str: The created food's id, description and HTTP status

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "params": "<params>"
    },
    "name": "mfp_create_custom_food"
  }
}

Input Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Aug 13, 2026

TDQS

A4.6/5.0

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.