How do I use fitatu-wrapper?

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., "@fitatu-wrapper show today's nutrition summary" 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.

fitatu-wrapper

by Kymylyy

Overview Schema Related Servers Score Discussions

Python

Remote

Fitatu Wrapper

CLI and MCP wrapper for Fitatu.

Scope

This repository currently targets v1 of a product-only wrapper.

Included:

programmatic login
session refresh
product search
product details
day read
daily nutrition summary
add product
delete entry

Not included in v1:

recipes
water
Own / Favorites / Fridge
editing existing entries

Related MCP server: Yazio MCP

Install

python3 -m pip install -e .
cp .env.example .env

Run

fitatu --help

Start the MCP server over stdio with:

fitatu-mcp

The CLI entrypoint is fitatu.

Implemented commands:

fitatu login --email ... --password ...
fitatu whoami
fitatu logout
fitatu search-food --date YYYY-MM-DD --meal breakfast --query banana
fitatu get-product --product-id 105392008
fitatu read-day --date YYYY-MM-DD
fitatu read-day-summary --date YYYY-MM-DD
fitatu read-days --from-date YYYY-MM-DD --to-date YYYY-MM-DD
fitatu read-day-summaries --from-date YYYY-MM-DD --to-date YYYY-MM-DD
fitatu add-product --date YYYY-MM-DD --meal breakfast --product-id ... --measure-id ... --quantity ...
fitatu delete-entry --date YYYY-MM-DD --entry-id ...

All CLI output is JSON. Read-oriented commands also support --out PATH for writing snapshots directly to disk.

The MCP entrypoint is fitatu-mcp.

Implemented tools:

fitatu_login
fitatu_whoami
fitatu_logout
fitatu_search_food
fitatu_get_product
fitatu_read_day
fitatu_read_day_summary
fitatu_add_product
fitatu_delete_entry

The server uses FastMCP over stdio.

Automation Examples

Range exports for a dashboard:

fitatu read-days --from-date 2026-03-01 --to-date 2026-03-07 --out data/fitatu-days.json
fitatu read-day-summaries --from-date 2026-03-01 --to-date 2026-03-31 --out data/fitatu-summaries.json

Example cronjobs:

# macOS / BSD `date`
5 6 * * * cd /absolute/path/to/fitatu-wrapper && /absolute/path/to/.venv/bin/fitatu read-day --date $(date +\%F) --out data/today.json
10 6 * * * cd /absolute/path/to/fitatu-wrapper && /absolute/path/to/.venv/bin/fitatu read-day-summaries --from-date $(date -v-6d +\%F) --to-date $(date +\%F) --out data/weekly-summaries.json

Linux / GNU date variant:

10 6 * * * cd /absolute/path/to/fitatu-wrapper && /absolute/path/to/.venv/bin/fitatu read-day-summaries --from-date $(date -d '6 days ago' +\%F) --to-date $(date +\%F) --out data/weekly-summaries.json

For dashboard ingestion, prefer the CLI over MCP and persist JSON snapshots locally.

Configuration

Copy .env.example to .env for local development. The runtime loads .env automatically.

Important rules:

never commit a real .env
never put real credentials or tokens into .env.example
treat .env.example as documentation, not as a secrets file

Supported environment variables:

FITATU_API_BASE_URL
FITATU_SESSION_PATH
FITATU_USERNAME
FITATU_PASSWORD
FITATU_API_KEY
FITATU_API_SECRET
FITATU_LOGIN_API_CLUSTER
FITATU_APP_LOCATION_COUNTRY
FITATU_APP_UUID
FITATU_APP_VERSION
FITATU_APP_LOCALE
FITATU_APP_SEARCHLOCALE
FITATU_APP_STORAGELOCALE
FITATU_APP_TIMEZONE
FITATU_APP_OS

The default path is now browserless and zero-bootstrap:

fitatu login --email ... --password ... can work with only credentials
the client fetches the public Fitatu login page and web bundle
it extracts the public web-app config needed for the first login request
after login, the session file stores the user tokens and user-scoped headers for normal reuse

This means:

browser automation is not required for normal CLI or MCP use
manual FITATU_API_* / FITATU_APP_* values are not required for first login
those header env vars are now advanced debug or override inputs, not mandatory setup

The repository does not include real values for any of these fields. Populate them from your own local setup only.

Live Smoke

The repo includes opt-in live smoke tests for zero-bootstrap browserless operation.

By default they are skipped. To run them:

FITATU_RUN_LIVE=1 python3 -m pytest -m live tests/test_live_smoke.py

Required live-smoke inputs:

FITATU_USERNAME
FITATU_PASSWORD
FITATU_LIVE_DATE
optionally FITATU_LIVE_MEAL and FITATU_LIVE_QUERY

Optional write smoke inputs:

FITATU_LIVE_PRODUCT_ID
FITATU_LIVE_MEASURE_ID
FITATU_LIVE_QUANTITY

The live smoke tests unset all manual FITATU_API_* and FITATU_APP_* env vars before building the client config. They then perform programmatic login and run the v1 read and write flows. That proves the browserless path works without manual bootstrap configuration.

Development

The project uses:

Python 3.12+
typer for the CLI
pydantic for public models
mcp for the MCP server
pytest for tests
ruff for linting

Checks:

ruff check .
python3 -m pytest

If you are changing CLI or MCP behavior, update this README in the same change.

Available Tools

9 tools

fitatu_add_productD

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes
`meal`	Yes
`quantity`	Yes
`measure_id`	Yes
`product_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

fitatu_delete_entryD

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes
`entry_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

fitatu_get_productD

ParametersJSON Schema

Name	Required	Description	Default
`product_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

fitatu_loginD

ParametersJSON Schema

Name	Required	Description	Default
`email`	Yes
`password`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

fitatu_logoutD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

fitatu_read_dayD

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

fitatu_read_day_summaryD

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

fitatu_search_foodD

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes
`meal`	Yes
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

fitatu_whoamiD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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.

9 tool updatesv0.1.0Aug 6, 2026
- First observedfitatu_add_product
- First observedfitatu_delete_entry
- First observedfitatu_get_product
- First observedfitatu_login
- First observedfitatu_logout
- First observedfitatu_read_day
- First observedfitatu_read_day_summary
- First observedfitatu_search_food
- First observedfitatu_whoami

Install Server

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

TDQS

C2.1/5.0

Disambiguation5/5

Each tool targets a distinct function: authentication (login/whoami/logout), food lookup (search_food/get_product), and daily log management (read_day/read_day_summary/add_product/delete_entry). The two read tools differentiate by level of detail, and add/delete are clearly opposed.

Naming Consistency5/5

All tools follow a consistent 'fitatu_verb_noun' pattern with snake_case throughout. 'whoami' is a minor deviation but is a standard command name that fits the style.

Tool Count5/5

9 tools is well within the ideal 3-15 range. Each tool addresses a core aspect of the Fitatu workflow without redundancy.

Completeness4/5

The surface covers authentication, food database search, and daily entry management comprehensively. Missing an explicit update operation for entries is a minor gap, but add/delete and multiple read modes handle most practical use cases.

Maintenance

ActivityMaintained

ResponsivenessSyncing

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

sphere
io.getsphere
Log meals, check calories and macros, set up a nutrition plan, and search foods.
Health & Wellness Fitness Tracking
1
Edamam A
io.github.pipeworx-io
Edamam MCP — wraps three Edamam APIs in one pack:
Health & Wellness Search
342
nutrition A
io.github.pipeworx-io
Nutrition MCP — wraps Open Food Facts API (free, no auth)
Open Data Health & Wellness Research & Data
2
wger A
io.github.pipeworx-io
Wger MCP — wraps wger Workout Manager REST API (free, no auth for read)
Health & Wellness Fitness Tracking
352

Related MCP Servers

yazio-mcp
Health & Wellness Search
fliptheweb
A
license
A
quality
B
maintenance
MCP server for managing Yazio user & nutrition data (unofficial)
Updated 25 days ago (2026-08-13 06:23 UTC)
15
313
59
MIT
Yazio MCP
Health & Wellness Fitness Tracking
Psilolouben
A
license
Not graded
quality
B
maintenance
Enables querying Yazio food logs including meals, daily summaries, and nutrition totals through MCP tools.
Updated 2 months ago (2026-07-16 11:01 UTC)
MIT
Fitatu Nutrition MCP Server
Health & Wellness Fitness Tracking
karolswitala
F
license
Not graded
quality
D
maintenance
Syncs and retrieves daily nutrition data (meals and macros) from Fitatu via MCP tools, with SQLite caching and HTTP Streamable transport.
Updated a month ago (2026-07-26 18:38 UTC)
1
-
Fitatu MCP Unofficial
Health & Wellness Search
AndekQR
A
license
Not graded
quality
A
maintenance
Unofficial MCP server that exposes Fitatu account operations as tools for inspecting and updating your meal plan.
Updated 14 days ago (2026-08-23 14:05 UTC)
4
MIT

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/Kymylyy/fitatu-wrapper'

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

Fitatu Wrapper

Scope

Install

Run

Automation Examples

Configuration

Zero-Bootstrap Login

Live Smoke

Development

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API