What can you do with this server?

This server is an AI-powered personalized nutrition and meal planning assistant. Here's what you can do with it: * Look up food nutrients: Query macros (calories, protein, carbs, fat, fiber, sugar) for any food item using a cached API Ninjas lookup or internal catalog. * Compute personalized daily targets: Calculate daily calorie and macro targets from your profile (weight, height, age, gender, activity level, goal) using the Mifflin-St Jeor BMR → TDEE → goal adjustment formula, with optional weather-based adjustments. * Generate a 7-day meal plan: Create a full week of varied meals tailored to your profile, dietary preferences (e.g., vegetarian, vegan), allergies, and calorie/macro targets — with best-effort allergen exclusion. * Log daily food intake: Record foods eaten on a given date and track running nutritional totals. * Adjust and catch up on daily calories: Compare logged intake against your target; if under, receive catch-up food suggestions or roll the shortfall into the next day. * Get current weather conditions: Fetch temperature and humidity for a city to adjust calorie and hydration recommendations. * Offline mode: Falls back to a bundled food catalog and cache when external API keys are unavailable.

Which integrations are available for this server?

Integrates with OpenAI's API to propose concrete, varied meals for personalized 7-day meal plans based on user profile and goals.

How do I use nutrition_db?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nutrition_db I need a 7-day meal plan for weight loss" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

nutrition_db

by harmehak0173

Overview Schema Related Servers Score Discussions

Python

Hybrid

🥗 MCP Nutrition - AI Meal Planner

Generate a personalized 7-day meal plan from your profile and goal, get daily calorie catch-up when you fall short, and track your progress over time. It runs as a FastAPI web app and, because the same engine is exposed over the Model Context Protocol (MCP), also as AI tools, resources, and prompts any MCP client (Claude Desktop, etc.) can use.

The intelligence is a deliberate blend:

🤖 OpenAI proposes concrete, varied meals for each day.
🥦 API Ninjas looks up macros for each food when your key returns them. Heads-up: the free API Ninjas tier gates calories/protein, so in practice many values fall back to the bundled ~29-food catalog or an Atwater estimate (see Data & limits).
🌤️ OpenWeather nudges calories/hydration for the day's conditions.
🧮 Deterministic Python computes the targets, keeps the LLM out of the arithmetic, reconciles each day to the calorie goal, and runs the catch-up math - the parts that are guaranteed and unit-tested.

Runs offline too: with no API keys, it falls back to a bundled food catalog + cache, so git clone && run works immediately.

Quickstart

# 1. Install (uv recommended)
uv sync --extra dev

# 2. (optional) add API keys for live LLM meals + real macros
cp .env.example .env      # then edit .env

# 3. Run the web app
uv run uvicorn app.main:app --reload
# open http://127.0.0.1:8000

Prefer pip? python -m venv .venv && . .venv/Scripts/activate && pip install -e ".[dev]".

Environment (all optional)

Key	Enables	Without it
`OPENAI_API_KEY`	LLM-generated meals	meals come from the bundled catalog
`API_NINJAS_KEY`	real macro numbers	macros come from cache / catalog
`OPENWEATHER_API_KEY`	weather-based adjustment	adjustment is skipped

Related MCP server: Calorie Tracker MCP Server

Run it as an MCP server

The planner is also a stdio MCP server named nutrition_db:

uv run nutrition-mcp        # or:  python -m mcp_server

{
  "mcpServers": {
    "nutrition_db": {
      "command": "uv",
      "args": ["run", "nutrition-mcp"],
      "cwd": "/absolute/path/to/MCP Nutrition"
    }
  }
}

It exposes all three MCP primitives, not just tools:

Tools: get_food_nutrients, get_current_conditions, compute_targets, generate_weekly_meal_plan, log_daily_intake, adjust_daily_calories.
Resources (read-only context): nutrition://catalog, nutrition://profile, nutrition://targets, nutrition://log/today, nutrition://history.
Prompts (guided flows): plan_my_week, log_my_meal, what_should_i_eat_now.

How it works

flowchart LR
    UI["Web UI (form)"] -->|HTTP| API["FastAPI · app/"]
    MCP["MCP client<br/>(Claude Desktop)"] -->|tools · resources · prompts| SRV["nutrition_db · mcp_server/"]
    API --> CORE
    SRV --> CORE
    subgraph CORE["core/ engine - single source of truth"]
        direction LR
        T["targets<br/>(BMR→TDEE→goal)"] --> P["planner"]
        P --> R["reconcile ±10%"]
        ADJ["catch-up adjuster"]
        H["history"]
    end
    P -->|propose foods| OA["OpenAI"]
    P -->|ground macros| AN["API Ninjas"]
    T -->|weather adjust| OW["OpenWeather"]

core/ is the single source of truth; the web app and the MCP server are thin layers over it. See docs/DECISIONS.md for the design tradeoffs and roadmap.

Plan generation (core/planner.py), per day: OpenAI proposes foods → API Ninjas returns real macros (cached) → deterministic code scales portions to hit the calorie target (±10%). A rolling "avoid recently-used items" list keeps the week varied. No OpenAI key? The bundled catalog builds the day instead.

Calorie catch-up (core/adjuster.py): compares logged intake to target. If you're under, it suggests catch-up foods for the meals you have left today, or rolls a capped portion of the shortfall into tomorrow. (This is the opposite of naively lowering the goal when you under-eat.)

Targets (core/targets.py): Mifflin-St Jeor BMR → activity TDEE → goal adjustment (-500 weight loss / +300 muscle gain) → macro split.

Project layout

core/         deterministic engine + service facade + API/LLM clients (the brains)
mcp_server/   nutrition_db MCP server (tools + resources + prompts over core/)
app/          FastAPI backend + minimal web UI (form, plan, catch-up, progress chart)
data/         food_catalog.json (fallback), nutrition_cache.json, state.json (runtime)
evals/        plan-quality eval harness + SCORECARD.md (python -m evals)
docs/         DECISIONS.md (design tradeoffs & roadmap)
tests/        pytest suite (targets, planner, adjuster, allergens, service, evals)

Testing & evals

uv run pytest -q          # 34 tests
uv run ruff check .
uv run python -m evals    # regenerate evals/SCORECARD.md

Tests run the real engine in offline mode (deterministic via the catalog) and use small fakes to exercise the LLM path without a network call.

Plan-quality evals (evals/, scorecard: evals/SCORECARD.md) score generated plans across a golden set of profiles (goals × diets × allergies) on calorie adherence, 100% allergen safety, protein adequacy, diet compliance, and variety. CI gates the non-negotiables - measuring a non-deterministic LLM system, not just unit-testing pure functions.

Data & limits

Be clear-eyed about what this does and doesn't guarantee:

Macro source. Authoritative macros come from API Ninjas only when your key returns them. On the free tier calories/protein are premium-gated, so values fall back to the curated ~29-food catalog (data/food_catalog.json) or an Atwater (4/4/9) estimate. The bundled catalog is what makes offline mode work.
"On target" means calories. Days are reconciled to the calorie target (±10%); protein/carb/fat are shown as guidance and a day is flagged when protein runs low, but macros aren't enforced.
Allergens. Typed allergies are expanded to ingredient keywords (core/allergens.py) and excluded from catalog, LLM-proposed, and catch-up foods - but it's best-effort keyword matching, not a medical guarantee. Verify ingredients yourself.
Not medical advice. Estimates only; not for pregnancy, medical conditions, or disordered eating. Single-user, local state; no accounts or sync.

Provenance

This started as an MCP nutrition benchmark server and grew into a standalone product. All code here is original work by harmehak0173; it has no dependency on the original benchmark framework.

License

Available Tools

6 tools

adjust_daily_caloriesB

Compare a day's logged intake to target; if under, suggest catch-up foods / roll shortfall into tomorrow.

ParametersJSON Schema

Name	Required	Description
`date`	No	YYYY-MM-DD (default today)
`profile`	No
`remaining_meals`	No	meals left today (default 0)

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description partially discloses behavior: it indicates comparison, suggestion, and rollover of shortfall. However, it does not specify side effects (e.g., whether it modifies targets), read/write nature, or required permissions.

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, efficient sentence that front-loads the core action, with no superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description lacks essential details for an agent: it does not specify input constraints, return values, or side effects. The nested profile object adds complexity not addressed.

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 coverage is 67% (2 of 3 top-level params have descriptions). The description adds no additional parameter meaning beyond what is in the schema; it does not explain how parameters like profile or remaining_meals are used.

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 'Compare' and the resources 'logged intake' and 'target', and distinguishes itself from siblings like compute_targets or log_daily_intake by focusing on adjustment based on comparison.

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 explicit when-to-use or when-not-to-use guidance is provided. The description implies usage after logging intake, but does not mention alternatives or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_targetsB

Compute daily calorie + macro targets from a profile (Mifflin-St Jeor BMR -> TDEE -> goal).

ParametersJSON Schema

Name	Required	Description	Default
`profile`	Yes

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the core algorithm (Mifflin-St Jeor BMR, TDEE, goal adjustment), which is a key behavioral trait. However, it does not mention side effects (e.g., data persistence), authentication needs, rate limits, or edge cases.

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 a single sentence that is well-structured and front-loaded with the action. It is concise with no wasted words, but it could include more detail without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex nested input and no output schema, the description is incomplete. It does not specify the output format (e.g., calories, macro grams or percentages) or explain how each profile field is used. The lack of cross-reference to sibling tools further limits completeness.

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 only says 'from a profile' without explaining individual fields like age, height_cm, weight_kg, gender, activity_level, or goal. It does not clarify how these parameters influence the computation, so the description adds minimal value beyond the schema 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 the tool's verb (compute) and resource (daily calorie + macro targets), specifies the exact formula chain (Mifflin-St Jeor BMR -> TDEE -> goal), and distinguishes it from sibling tools that handle adjustments, planning, or logging.

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 like adjust_daily_calories. The description does not mention any prerequisites, exclusions, or contextual advice for selecting this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_weekly_meal_planB

Generate a 7-day meal plan of concrete foods (LLM-proposed, API-Ninjas-grounded, reconciled to targets).

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Number of days (default 7)
`profile`	Yes

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It gives some insight into the generation process but does not disclose output handling, side effects, or limitations (e.g., API costs, latency). Adequate but minimal.

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?

Single sentence, front-loaded with key action and constraints. Could be slightly more structured but no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (nested profile object, multiple parameters) and lack of output schema, the description is too brief. Does not explain what the output looks like, error conditions, or how targets are specified. Incomplete for a new user.

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 50% (some parameters have descriptions in schema). The tool description adds no additional parameter semantics. Baseline 3 is appropriate as the schema partially explains parameters.

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?

Description clearly states the tool generates a 7-day meal plan and mentions the approach (LLM-proposed, API-Ninjas-grounded, reconciled to targets). However, it does not explicitly differentiate from sibling tools like compute_targets or adjust_daily_calories.

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 on when to use this tool vs alternatives, no prerequisites or exclusions provided. The description lacks context about what inputs are needed or what steps precede it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_current_conditionsA

Fetch current temperature and humidity for a city via OpenWeather.

ParametersJSON Schema

Name	Required	Description	Default
`city`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Lacks annotations and does not disclose behavioral details such as rate limits, error handling, or data freshness beyond stating it fetches via OpenWeather.

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 sentence, front-loaded, no unnecessary words, appropriately sized for a simple tool.

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?

Covers the basic operation but lacks details on output format (e.g., temperature units) and does not compensate for absent output schema or annotations.

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 has no description for the city parameter; the description adds that it fetches for a city, providing basic meaning but no format or constraints.

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?

Clearly states the tool fetches current temperature and humidity for a city via OpenWeather, distinguishing it from sibling tools which are nutrition-related.

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?

Does not explicitly state when to use vs alternatives, but the tool's purpose is implied given the distinct domain from sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_food_nutrientsA

Look up macros (calories/protein/carbs/fat/fiber/sugar) for a food query via API Ninjas (cached).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	e.g. '1 medium banana'

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It mentions caching and external API (API Ninjas), which gives some transparency. However, it lacks details on side effects, rate limits, or 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 a single, concise sentence with no unnecessary words. It efficiently conveys the tool's purpose and key 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 simple tool with one parameter and no output schema, the description covers purpose, parameter hint, and caching behavior. It could mention the return format explicitly, but the list of macros provides adequate context.

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 has high coverage (100%) with a clear example in the description. The description adds 'food query' context but does not significantly enhance understanding 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 clearly states the tool looks up macros for a food query, specifying the exact nutrients (calories/protein/carbs/fat/fiber/sugar) and the data source (API Ninjas with caching). This distinguishes it from sibling tools like adjust_daily_calories or compute_targets.

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 use when needing nutritional data for a food query, but it does not explicitly state when to use or avoid this tool, nor does it mention alternatives or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

log_daily_intakeC

Record foods eaten on a date (default today) and return running totals.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	YYYY-MM-DD (default today)
`foods`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states 'return running totals' but does not specify what totals (calories, macronutrients) or the format. It does not disclose if it overwrites existing entries for the same date or any side effects.

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 a single sentence with 13 words, concise and front-loaded. However, it could be slightly more informative without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is incomplete. It does not explain the return format, error cases, or behavior when logging for an already populated date. For a logging tool, more details are needed.

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 only 50% (date has description). The tool description adds no additional meaning beyond the schema for the 'foods' parameter, which lacks a description. It does not 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 clearly states the verb 'Record' and the resource 'foods eaten on a date', and mentions returning running totals. It distinguishes itself from sibling tools like 'adjust_daily_calories' and 'get_food_nutrients' which have different purposes.

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 explicit guidance on when or when not to use this tool. No mention of alternatives or prerequisites. The description implies usage for logging foods, but lacks context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jul 7, 2026
- First observedadjust_daily_calories
- First observedcompute_targets
- First observedgenerate_weekly_meal_plan
- First observedget_current_conditions
- First observedget_food_nutrients
- First observedlog_daily_intake

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose, from computing targets to logging intake and generating meal plans. The weather tool is unrelated but still unique.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to understand.

Tool Count5/5

With 6 tools, the server is well-scoped for nutrition tracking without being overwhelming or underwhelming.

Completeness4/5

Core workflows are covered (targets, food lookup, logging, planning), but missing update/delete for logs and the weather tool is extraneous.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

pantry-aideOAuth
com.pantryaide
AI meal plans that fill your Kroger/Instacart cart - pantry-aware lists, all from chat.
E-commerce & Retail Health & Wellness
2
Food Logger MCP
ai.sig.foodlog
Food logging, nutrition summaries, and meal photo calorie and macro estimates.
Health & Wellness Image & Video Processing
2
ForkMate AOAuth
ai.forkmate
Log what you ate by talking to your AI assistant — calories and macros, completely free.
Fitness Tracking Health & Wellness
123
sphere
io.getsphere
Log meals, check calories and macros, set up a nutrition plan, and search foods.
Health & Wellness Fitness Tracking
1

Related MCP Servers

Diet / Meal Log MCP Server
Health & Wellness Note Taking App Automation
inai17ibar
F
license
Not graded
quality
B
maintenance
Enables users to log meals, track daily and weekly calorie intake, and manage diet records. Supports both local and network modes for flexible meal logging across devices.
Updated a month ago (2026-07-26 07:13 UTC)
-
Calorie Tracker MCP Server
Health & Wellness Fitness Tracking
thitiph0n
F
license
Not graded
quality
F
maintenance
Tracks daily calorie intake with accurate BMR/TDEE calculations, food logging, and profile management via Cloudflare Workers and D1 database.
Updated a year ago (2025-10-05 14:11 UTC)
4
-
Gamito
Health & Wellness
nerkyzas157
F
license
B
quality
B
maintenance
Enables AI agents to generate budget-disciplined, allergy-safe weekly meal plans, shopping lists, and meal swaps using a fully local deterministic engine.
Updated 3 months ago (2026-06-14 14:57 UTC)
20
-
yes_chef_mcp
Health & Wellness Search
ltmorro
F
license
Not graded
quality
D
maintenance
Enables AI assistants to search recipes, compose nutritionally balanced meals, optimize weekly meal plans based on macro targets for family members, and generate consolidated grocery lists from a personal recipe database.
Updated 5 months ago (2026-04-05 23:31 UTC)
-

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/harmehak0173/mcp-nutrition'

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