Fitatu MCP Unofficial
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | HTTP server port. | 3000 |
| NODE_ENV | No | development, production, or test. | development |
| LOG_LEVEL | No | silent, error, warn, info, or debug. | info |
| SERVER_NAME | No | MCP server name. | fitatu-mcp |
| FITATU_EMAIL | Yes | Fitatu account email address. | |
| SERVER_VERSION | No | MCP server version. | 3.0.1 |
| FITATU_PASSWORD | Yes | Fitatu account password. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_current_userA | Fetches the currently authenticated Fitatu user profile. |
| get_body_measurementA | Gets the authenticated Fitatu user's body measurement for an optional calendar date. When date is omitted, returns the most recent measurement across weight, circumference, and body-fat history. |
| save_body_measurementA | Partially updates the authenticated Fitatu user's body measurement for an explicit date. Omitted values remain unchanged, and existing values cannot be cleared with this tool. |
| get_user_settingsA | Gets the authenticated Fitatu user's date-resolved energy, calculated, and water settings. When date is omitted, today is resolved in the user's Fitatu timezone. |
| update_user_settingsA | Partially updates the authenticated Fitatu user's supported settings. Accepts a complete manual energy target, switches energy calculation back to Fitatu automatic mode, changes the water serving size, or combines energy and water in one update. Omitted supported settings and all unsupported settings are preserved. |
| get_day_plan_itemsA | Fetches Fitatu meals and concrete day-plan entries. Copy the exact mealKey with itemId to update_meal_item, move_meal_item, or remove_meal_items; productId and raw recipeId identify food definitions, not removable entries. Defaults to today's local date. |
| get_diet_summaryA | Fetches the authenticated Fitatu user's nutrition and energy summary for an inclusive date range. |
| search_foodA | Searches Fitatu catalogs for products and recipes. The server does not infer brand or retailer aliases; provide alternative phrases together in queries when needed. Each query returns separate userItems and publicItems lists in Fitatu's order; the server does not merge or deduplicate candidates across those sources. Set includeDetails=true only when an alternative or missing measure is needed. A candidate has exactly one definition id: productId means use the PRODUCT meal-item variant; raw recipeId means use the RECIPE variant. Copy that id with a listed measureId. Do not send foodType. |
| search_food_by_barcodesA | Searches Fitatu's public food catalog for up to 10 GTIN barcodes in parallel. Returns one minimal result group per input barcode in input order, including duplicates. Copy a selected productId and measureId to add_meal_items. This tool only searches and never adds food. |
| add_meal_itemsA | Validates, submits, and confirms products, recipes, or fallback one-off custom items in a Fitatu meal. Prefer a catalog product or recipe: search with search_food or search_recipes first, then provide productId and measureId for a product or raw recipeId and measureId for a recipe. Custom items are not preferred; use name and nutrition values only when no suitable catalog match exists. The id field selects the variant. Deleted recipes and mismatched measures are rejected before synchronization. Returns { status: 'confirmed', date, mealKey, addedItems: [{ inputIndex, itemId }] }; each itemId is persisted and ready for later meal-item mutations. |
| update_meal_itemA | Updates and confirms one existing Fitatu meal item selected by its exact date, mealKey, and itemId. PRODUCT and RECIPE quantity or measure changes require a measure belonging to that food definition. For CUSTOM_ITEM entries, only the name, calories, protein, fat, carbohydrates, or eaten flag can be updated; their technical measure fields are immutable. Returns { status: 'confirmed', date, mealKey, itemId } after every requested field is observed in the persisted day plan. |
| replace_meal_itemA | Replaces and confirms one existing Fitatu meal item. Select the existing entry by its exact date, mealKey, and itemId, then provide replacement using the same strict PRODUCT, RECIPE, or fallback CUSTOM_ITEM payload accepted by add_meal_items. If replacement.eaten is omitted, the existing eaten state is preserved. Replacing a PRODUCT or RECIPE with the same catalog definition is rejected; use update_meal_item for quantity, measure, or eaten changes. Returns { status: 'confirmed', date, mealKey, previousItemId, itemId }; use the returned itemId for later mutations. The new item remains in the same meal, but item order is not part of the contract. |
| remove_meal_itemsA | Atomically removes and confirms exact Fitatu day-plan entries of any food type. Copy each mealKey and itemId pair from get_day_plan_items; do not pass productId or recipeId. If any requested active item is missing from its declared meal context, nothing is synchronized. Returns { status: 'confirmed', date, removedItems: [{ inputIndex, mealKey, itemId }] } after every selected item is absent from the persisted active day plan. |
| move_meal_itemA | Moves and confirms one existing Fitatu meal item selected by its exact source date, mealKey, and itemId. Provide a destination date, mealKey, or both that differs from the source. Fitatu creates a new item id during a valid move. Returns { status: 'confirmed', fromDate, fromMealKey, previousItemId, toDate, toMealKey, itemId }; use the returned itemId for later mutations. |
| create_recipeA | Creates and confirms a Fitatu recipe from validated products selected with search_food. A non-empty name, at least one ingredient, and a positive whole number of servings are required. Pass preparation instructions as steps with one step per array item so Fitatu displays separate step fields. Ingredient quantities must be positive finite numbers. For custom tags use RECIPE_TAG_USERS_TYPE. Recipes are private unless shared=true. Returns { status, recipeId, details, warnings }; details.measures contains measureId values accepted by add_meal_items, recipeId is canonical, and repeating the same request creates another recipe. |
| get_recipeA | Gets canonical per-serving details and add_meal_items measures for a raw recipeId returned by a recipe-aware MCP tool. Soft-deleted recipes remain readable with deleted=true and editable=false. Raw productId and recipeId spaces may overlap, so the recipeId field determines how the supplied value is interpreted. Returns canonical recipe details { recipeId, name, servings, shared, editable, deleted, mealSchema, tags, ingredients, nutritionPerServing, measures, ...optionalFields }. |
| search_recipesA | Searches active recipes by a trimmed, case-insensitive name substring and returns raw recipeId values. Set includeDetails=true to include additional recipe information and available measures. These details can be useful when adding a selected recipe to a day plan. Empty or whitespace-only query lists recipes. scope=all combines catalogs and returns partial results with warnings when one catalog or individual recipe details are unavailable. Returns { query, scope, page, limit, count, items, warnings }. |
| update_recipeA | Partially updates and confirms an owned active recipe identified by a raw recipeId. The same create limits apply. Pass preparation instructions as steps with one step per array item so Fitatu displays separate step fields. Omitted fields, including steps and mealSchema, are preserved; null clears nullable time fields, and [] clears lists. Raw public mealSchema values returned by get_recipe are not necessarily accepted mutation inputs. Tag categories must be RECIPE_TAG_USERS_TYPE or already present on this recipe. Fitatu may replace the identity; always use the returned recipeId. Returns { status, previousRecipeId, recipeId, identityChanged, details, warnings }; details.measures contains measureId values accepted by add_meal_items. |
| delete_recipeA | Soft-deletes and confirms deletion of an owned active recipe definition identified by a raw recipeId after exact-name confirmation. It disappears from recipe searches, but existing day-plan entries remain historical snapshots and must be removed separately with remove_meal_items mealKey and itemId targets. Returns { status, recipeId, name, deleted }. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 19 tools
Each tool targets a distinct resource and action: meal items (add, update, remove, move, replace), food search (text and barcode), recipe lifecycle (create, get, search, update, delete), body measurements (get/save), and user settings (get/update). Even similar tools like search_food and search_food_by_barcodes differ clearly by input type. No two tools appear to do the same thing.
All tools follow a consistent verb_noun pattern (e.g., get_day_plan_items, add_meal_items, create_recipe, delete_recipe). Names are clear and predictable, with no mixing of camelCase or inconsistent verb styles. The pattern allows an agent to infer functionality from names alone.
With 19 tools, the server is above the typical 3-15 well-scoped range, entering the 'heavy' category. However, each tool serves a distinct purpose across multiple domains (meal management, recipes, body measurements, user settings), so the count is justified but still on the higher side for optimal agent usability.
The tool surface covers CRUD for recipes, full meal item lifecycle (add, update, replace, move, remove), food and barcode search, body measurement retrieval/saving, and user settings. Minor gaps include lack of a dedicated tool to list body measurements over time (only most recent or specific date) and no bulk operations for day plans, but these are workable for agents.