Loading ToolBench
MCP server for the FatSecret nutrition and food-logging API — search foods, log meals, and analyse nutrition with any LLM that supports Model Context Protocol.
FatSecret MCP has well-structured tool definitions with complete schemas and descriptions for all 12 tools. Naming follows verb_noun convention (search_foods, get_food, add_food_entry, etc.). Descriptions are substantive (100-250 chars typical), explaining WHAT the tool does and WHEN to use it. Input schemas are properly typed with enums for constrained fields (food_type, meal, sort_by). However, output schemas are not documented, LLMs cannot see what fields to expect from responses. Parameter descriptions are good but lack explicit format/range guidance (e.g., 'YYYY-MM-DD' format stated in descriptions but not in schema). Error handling is basic, no recovery guidance or actionable error messages visible in tool definitions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE). Composition is sound, tools chain logically (search_foods → get_food → add_food_entry) and return IDs needed for downstream calls.
Add a food entry to the user's food diary. Use search_foods to find food_id and get_food to find the correct serving_id. Requires OAuth 1.0 user credentials AND Diary Read/Write API access (contact FatSecret support to enable).
Delete a food diary entry by its ID. Use get_food_entries to find the food_entry_id first. Requires Diary Read/Write API access.
Delete a body weight entry for a specific date. Requires Diary Read/Write API access.
Edit an existing food diary entry (change serving size, meal, or number of units). Use get_food_entries to find the food_entry_id. Requires Diary Read/Write API access.
Get a summary of total daily nutrition (calories, protein, carbohydrates, fat, and more) for a specific date by aggregating all diary entries. Requires OAuth 1.0 user credentials.
Output schemas not documented. LLMs cannot see what fields (calories, protein, carbs, fat, etc.) are returned by search_foods, get_food, get_food_entries, or other tools. This forces LLMs to guess at response structure and risks hallucinated field names in downstream reasoning.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels declared in metadata. delete_food_entry, delete_weight_entry, and add_food_entry should carry destructive/write hints so agents know which calls are irreversible.
Error handling lacks recovery guidance. Tool definitions do not specify what errors are retryable, user-fixable, or fatal. No actionable error messages visible (e.g., 'User not found. Try search_users() first'). Agents cannot self-correct on failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Get detailed nutrition information for a specific food by its FatSecret food ID. Returns all serving sizes and complete macronutrient + micronutrient data (calories, protein, carbs, fat, fiber, sodium, vitamins, etc.).
Get food diary entries for a specific date (or today by default). Returns all logged meals with nutrition totals. Requires OAuth 1.0 user credentials (FATSECRET_ACCESS_TOKEN + FATSECRET_ACCESS_TOKEN_SECRET).
Get daily nutrition totals (calories, protein, carbs, fat) for every day in a given month that has diary entries. Useful for tracking trends and weekly/monthly analysis. Requires OAuth 1.0 user credentials.
Get body weight entries for a specific date. Returns weight in kg and BMI if available. Requires OAuth 1.0 user credentials.
Search the FatSecret food database by name or keyword. Returns a paginated list of foods with basic nutrition info (calories, protein, carbs, fat) per serving. Use this to find food IDs for use with get_food.
Search FatSecret's recipe database. Returns recipes with nutrition info, ingredients, and images. Supports filtering by calorie range, prep time, and sorting options.
Log or update a body weight entry for a specific date. Requires Diary Read/Write API access.
Parameter descriptions lack explicit format/range guidance. 'date' parameters state 'YYYY-MM-DD' in description text but not in JSON Schema format field. 'max_results' lacks explicit min/max bounds in schema (only in description). LLMs cannot parse constraints from text alone.
Credentials (FATSECRET_CLIENT_ID, FATSECRET_SECRET, FATSECRET_ACCESS_TOKEN, FATSECRET_ACCESS_TOKEN_SECRET) are injected server-side via environment variables, correct. However, tool descriptions mention 'Requires OAuth 1.0 user credentials' without clarifying that tokens are NOT parameters. This could mislead agents into attempting to pass credentials as arguments.