What can you do with this server?

The server provides unofficial private API access to Lose It! for managing nutrition and weight. Capabilities include: * Search food: Find food items by name (search_food). * Describe food: Get nutrition and serving details for a food ID (describe_food). * Read diary: View a day's entries with calories, macros, and totals (get_diary). * Log database food: Add a food to a meal with portion control; dry-run supported (log_food). * Log custom food: Record entries with arbitrary calories/macros; dry-run supported (log_custom_food). * Record weight: Log a weigh-in; dry-run supported (log_weight). * View weight history: Retrieve weigh-ins over a range (get_weight_history). * Delete entries: Remove a diary entry, with local backup (delete_entry). * Check account: Display authenticated user (whoami).

How do I use loseit-mcp?

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., "@loseit-mcp search for Greek yogurt" 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.

loseit-mcp

by cabird

Overview Schema Related Servers Score Discussions

Python

Remote

loseit-mcp

An MCP server and CLI for logging food to Lose It!.

⚠️ Unofficial. Lose It! publishes no public API. This talks to the private GWT-RPC endpoint used by the Lose It! web app, so it can break whenever they ship a new web build.

Tools

Tool	Description
`search_food`	Search the food database; returns `food_id`s
`describe_food`	Full nutrition and serving detail for one food
`get_diary`	A day's entries with calories and macros, plus totals
`log_food`	Log a database food to a meal
`log_custom_food`	Log arbitrary calories/macros with no database match
`log_weight`	Record a weigh-in
`get_weight_history`	Read weigh-ins over a range, with min/max/change
`delete_entry`	Delete a diary entry
`whoami`	Show the authenticated account

log_custom_food exists because updateFoodLogEntry carries the food's name, brand, and nutrient map inline — so an entry can describe a food the database has never heard of. Use it for restaurant meals, homemade dishes, or any portion where forcing a database match would distort the numbers.

Related MCP server: nutrition-mcp

Setup

uv sync
cp .env.example .env   # then fill in your credentials

Configuration

Settings resolve in priority order: CLI flags → environment → .env → JSON config file → defaults.

Variable	Required	Description
`LOSEIT_EMAIL`	yes*	Lose It! account email
`LOSEIT_PASSWORD`	yes*	Lose It! account password
`LOSEIT_TOKEN`	no	A `liauth` JWT, used instead of email/password
`LOSEIT_HOURS_FROM_GMT`	no	UTC offset in whole hours; auto-detected
`LOSEIT_STRONG_NAME`	no	GWT permutation, if Lose It ships a new build
`LOSEIT_POLICY_HASH`	no	GWT policy hash, if Lose It ships a new build

* Not required if LOSEIT_TOKEN is set.

.env is gitignored. The session token is cached at ~/.config/loseit-mcp/session.json with owner-only permissions and refreshes automatically when it expires.

Running the server

loseit-mcp serve                                  # stdio (default)
loseit-mcp serve --transport streamable-http --port 8000

{
  "mcpServers": {
    "loseit": {
      "command": "uv",
      "args": ["run", "loseit-mcp", "serve"],
      "cwd": "/absolute/path/to/loseit-mcp"
    }
  }
}

To host one server for multiple accounts, see DEPLOYMENT.md.

CLI

The same operations are available directly, which is the easiest way to test:

loseit-mcp search "greek yogurt" -n 5
loseit-mcp describe <food_id>
loseit-mcp diary 2026-07-25
loseit-mcp log <food_id> -m lunch -a 120 -u g
loseit-mcp log-custom "Caesar Salad" 620 -m lunch -b "Gastrohub" -p 46 -c 18 -f 40
loseit-mcp weigh 199.2
loseit-mcp weights -n 14
loseit-mcp delete <entry_id> -d 2026-07-25

Add --dry-run to either log command to preview the math without writing, and --json for machine-readable output.

Two more, for hosted deployments:

loseit-mcp gen-secret                      # a secret for LOSEIT_URL_SECRET
loseit-mcp enroll https://<host>           # get a credential URL for a client

A hosted deployment also serves a self-service enrollment page at /: someone enters their Lose It! email and password and gets their own MCP URL back, ready to paste into Claude, ChatGPT, or any other MCP client. Credentials are checked against Lose It before a URL is issued, so a typo fails immediately instead of producing a link that silently doesn't work.

The page is a single self-contained document under a strict CSP — no external scripts, styles, or fonts — so nothing but Lose It ever sees the credentials. Nothing is stored: the password is used once, in memory, and then encrypted into the URL itself, which is why there is no database and no account system.

Notes

Deleting writes a recoverable copy to local trash before the wire call.
When Lose It changes their private API, tools return an explanation of what broke and what the operator needs to refresh, rather than a decoder traceback — see errors.py.
Hosted deployments rate-limit per client address and per credential, since an address alone is a weak identity behind a NAT pool. Enrollment adds a third limit, per email address, so verifying credentials can't be used to guess them.
/healthz reports the running version and commit, so you can tell what is actually deployed without reading logs.
Weights carry no unit over the wire; the number is interpreted in whatever unit the account displays (lb or kg).
saturated_fat_g is not recorded. The upstream SDK's payload builder filters that nutrient ordinal out, so log_custom_food reports it in an ignored_nutrients field rather than claiming to have logged it. Every other macro goes through.
Weight history is fetched in windows and bisected further when a response is too large for the SDK decoder — an unchunked year-long query would otherwise silently return "no weigh-ins".
Relative dates (today / yesterday) resolve in the account's timezone, not the host's, so a server in another region doesn't log to the wrong day.
Fractional portions of database foods can display a misleading unit (half a banana rendering as "1/4 Each") because the server's canonical serving count differs from the food's native unit. Calories stay correct, but log-custom is the more predictable route for odd portions.

Architecture

The GWT-RPC wire format is handled by the phitoduck/lose-it SDK. This project adds email/password authentication (the SDK expects you to supply a JWT yourself, and its browser-cookie import does not support Windows), the custom-food logging path, weight recording via saveRecordedWeight (captured from the web app's weigh-in widget), and the MCP server and CLI layers.

License

0BSD — the BSD Zero Clause License. Use it, change it, ship it, sell it. No attribution, no notice, no conditions of any kind.

This is deliberate. If FitNow (the makers of Lose It!) want any part of this, they should take it and treat it as their own — no permission needed, nothing to negotiate, no obligation to credit me. The same goes for anyone else.

Two things a license cannot do, stated plainly:

Trademark is separate. "Lose It!" is a registered trademark of FitNow, Inc. This project is unofficial and unaffiliated; the license grants no rights in their marks.
Dependencies keep their own terms. They are all permissive (MIT, BSD-3, Apache-2.0), but the lose-it SDK is MIT and asks that its copyright notice be preserved. Anyone vendoring this code should either keep that notice or replace the dependency.

Available Tools

8 tools

delete_entryA

Delete a diary entry. Get the entry_id from get_diary for the same day. A recoverable copy is written to local trash before deleting.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	The day the entry is on: 'YYYY-MM-DD', 'today', 'yesterday'.
`entry_id`	Yes	`entry_id` from get_diary.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

Discloses that a recoverable copy is written to local trash before deletion, revealing key behavioral trait not evident from annotations (none provided). This adds significant value for an AI agent.

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?

Two sentences with no waste. Action verb front-loaded. Every 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 only 2 parameters and presence of output schema, description sufficiently covers core behavior and undoability. No gaps for this delete action.

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?

Schema coverage is 100%, so baseline is 3. Description adds value by specifying that entry_id comes from get_diary, which clarifies parameter usage beyond schema fields.

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 'Delete a diary entry' with a specific verb and resource. It distinguishes from siblings like get_diary (retrieval) and log_food (addition).

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?

Provides explicit instruction to obtain entry_id from get_diary, guiding correct usage. Does not explicitly state when not to use or provide alternatives, but context of deletion is straightforward.

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

describe_foodA

Get full nutrition detail and serving information for one food, identified by the food_id returned from search_food.

ParametersJSON Schema

Name	Required	Description	Default
`food_id`	Yes	32-character hex food ID.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states high-level behavior (get nutrition info) but does not disclose identity, error handling, or safety profile. However, 'describe' implies a read operation, and the output schema likely covers details.

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, starts with the action verb 'Get', includes the key qualifier 'for one food', and specifies how to obtain the parameter. No fluff.

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 that an output schema exists (expected to detail nutrition info) and the input is a single well-described parameter, the description provides sufficient information for an agent to use the tool correctly.

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?

Schema coverage is 100%, but the description adds valuable context: the food_id is the one returned by search_food. This goes beyond the schema's static description of '32-character hex food ID' by tying it to a sibling tool's output.

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 retrieves full nutrition and serving info for one food using a food_id from search_food. It specifies the source of the parameter and distinguishes it from sibling search_food (which returns a list).

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?

Explicitly states that the food_id comes from search_food, indicating the correct workflow. It lacks explicit when-not-to-use or alternative instructions, but the context is clear enough.

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

get_diaryA

Read the food diary for a day: every logged entry with calories and macros, plus the day's totals. Each entry carries an entry_id for delete_entry.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Day to read: 'YYYY-MM-DD', 'today', or 'yesterday'.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Clearly indicates it is a read operation (non-destructive) and mentions the entry_id for deletion. Lacks details on authentication or rate limits but adequate for a read tool.

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?

Two concise sentences that front-load the key information and add a useful detail about entry_id. No wasted words.

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 that an output schema exists, the description sufficiently explains the return values (entries, totals, entry_id). Covers all necessary context for agent decision.

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 100% with good parameter description ('YYYY-MM-DD', 'today', 'yesterday'). Description adds no extra parameter info beyond schema, so baseline 3 is appropriate.

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 it reads the food diary for a day and specifies the returned data (entries with calories/macros, totals) and the entry_id for use with delete_entry. Distinct from sibling tools like log_food or delete_entry.

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?

Implies usage for reading diary entries but does not explicitly state when to use versus alternatives or when not to use. Sibling names hint at context but no direct guidance.

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

log_custom_foodA

Log a food by its exact nutrition values, without needing a match in the food database. Use this for restaurant meals, homemade dishes, or anything where you know the calories and macros but search_food has no good match. Values are per serving.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Day to log to: 'YYYY-MM-DD', 'today', or 'yesterday'.
`meal`	No	One of: breakfast, lunch, dinner, snacks.	snacks
`name`	Yes	Food name as it should appear in the diary.
`brand`	No	Brand or restaurant, e.g. 'Microsoft Gastrohub 75'.
`fat_g`	No	Total fat in grams.
`carb_g`	No	Carbohydrate in grams.
`dry_run`	No	Preview without writing.
`fiber_g`	No	Fiber in grams.
`sugar_g`	No	Sugar in grams.
`calories`	Yes	Calories per serving.
`servings`	No	How many of this serving to log.
`protein_g`	No	Protein in grams.
`sodium_mg`	No	Sodium in milligrams.
`cholesterol_mg`	No	Cholesterol in milligrams.
`saturated_fat_g`	No	Saturated fat in grams.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior4/5

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

Despite no annotations, the description clearly indicates a write operation ('log') and adds context that values are 'per serving', which is crucial for interpreting the nutrition parameters. It could mention that entries are added to the diary, but the verb 'log' strongly implies this. No contradictions with annotations.

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?

Two concise sentences achieve everything: definition, usage guidance, and per-serving note. No fluff or redundancy. Perfectly front-loaded with essential information.

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?

Given 15 parameters, 100% schema coverage, and an output schema (not shown but present), the description covers core behavior, usage scenarios, and per-serving semantics. It does not detail the output format, but the output schema handles that. Slightly lacking mention of the diary context (e.g., 'logs to the user's diary'), but the meal and date parameters imply it.

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?

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that all nutrition values are per serving, which directly impacts how the `servings` parameter is used. This extra context goes beyond the individual parameter descriptions.

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 'log' and resource 'custom food', and differentiates from sibling tools like search_food by explicitly noting 'without needing a match in the food database'. It also lists specific use cases (restaurant meals, homemade dishes), making the purpose unmistakable.

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use this tool: 'Use this for restaurant meals, homemade dishes, or anything where you know the calories and macros but search_food has no good match.' This clearly separates it from alternatives and implies not to use it when a database match is available.

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

log_foodB

Log a food to a meal in the diary. Specify the portion EITHER as serving_amount + serving_unit (e.g. 120 and 'g') OR as servings (a multiplier of the food's default serving). Set dry_run to preview.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Day to log to: 'YYYY-MM-DD', 'today', or 'yesterday'.
`meal`	No	One of: breakfast, lunch, dinner, snacks.	snacks
`dry_run`	No	Preview the result without writing to the diary.
`food_id`	Yes	32-character hex food ID from search_food.
`servings`	No	Multiplier of the food's default serving.
`serving_unit`	No	Unit for `serving_amount`, e.g. 'g', 'mL', 'cup', 'oz'.
`serving_amount`	No	Quantity in `serving_unit`, e.g. 120.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

Without annotations, the description carries full burden but only mentions dry_run for preview. It omits behavioral traits like whether logging overwrites existing entries, idempotency, or required permissions for a mutation tool.

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?

Two short sentences, front-loaded with the main action, efficient and focused.

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?

With an output schema present, return values are covered. However, the description lacks context on required parameters, error handling, or state changes, making it moderately complete for a logging tool.

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 100%, so baseline is 3. The description adds value by clarifying the two portion methods (mutually exclusive) and dry_run usage, but does not provide significant extra detail beyond schema descriptions.

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 states 'Log a food to a meal in the diary' with a clear verb, resource, and destination. It distinguishes from siblings like search_food and describe_food.

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 to use this tool versus alternatives like log_custom_food. The description only gives port specification options but lacks context or exclusions.

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

log_weightA

Record a weigh-in for a day. The unit follows the account's display setting (lb or kg).

ParametersJSON Schema

Name	Required	Description
`date`	No	Day to record: 'YYYY-MM-DD', 'today', or 'yesterday'.
`weight`	Yes	Body weight in the account's unit.
`dry_run`	No	Preview without writing.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/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 mentions the unit follows display settings but does not disclose whether the tool overwrites existing entries, requires authentication, or other behavioral traits beyond the schema.

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 two sentences, no wasted words, and front-loaded with the action. Every sentence adds value.

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?

Given the tool's simplicity and full schema coverage, the description provides adequate context about the action and unit. However, it lacks information on whether logging replaces or appends to existing entries, which would be useful for a journaling context.

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?

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that the unit follows the account's display setting ('lb or kg'), which goes beyond the schema's 'in the account's unit'.

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 ('Record') and resource ('weigh-in'), and specifies that it's for a day. It distinguishes from siblings like log_food, which is for food logging.

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 the usage context (recording weight for a day) but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.

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

search_foodA

Search the Lose It! food database. Returns candidate foods with a food_id to pass to log_food or describe_food.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results to return.
`query`	Yes	Food name to search for, e.g. 'greek yogurt'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It states it returns candidate foods, but omits details about read-only nature, pagination, sorting, or any side effects. This is minimal for a search tool.

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 two sentences, no extraneous words, and front-loaded with the primary action and output. Highly concise and structured.

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?

The description covers the core purpose and output schema usage, but lacks guidance on when to use this tool over siblings and behavioral details. For a simple tool, it is partially complete but leaves gaps.

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 100%, so the schema already documents both parameters. The description adds minimal value beyond the schema, only providing an example for query ('greek yogurt'). The limit parameter is adequately described in 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 searches the Lose It! food database and returns candidate foods with a food_id, which can be used with log_food or describe_food. It distinguishes the tool by specifying its output and downstream usage.

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 usage by mentioning the returned food_id is for log_food or describe_food, but it does not explicitly state when to use this tool versus alternatives like describe_food, nor does it provide when-not or exclusion conditions.

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

whoamiA

Show which Lose It! account this server is authenticated as.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are present, so the description must convey behavior. 'Show' implies read-only, which is adequate, but no details on exact output or side effects. For a simple identity check, this is minimally sufficient.

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?

A single, front-loaded sentence with no wasted words. Perfectly concise for the tool's simplicity.

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?

Given zero parameters and an output schema, the description covers the essential behavior. Could optionally mention what identity information is revealed, but it's not required.

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?

No parameters exist, and schema coverage is 100%. The description adds no parameter information, but none is needed. Baseline 4 applies per rules.

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 shows which account is authenticated, distinguishing it from sibling tools that manage diary entries, food logs, or weight.

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 purpose is straightforward, making usage context clear. However, no explicit guidance on when to use this versus alternatives is provided, though sibling tools suggest distinct functions.

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.

8 tool updatesv0.1.0Jul 29, 2026
- First observeddelete_entry
- First observeddescribe_food
- First observedget_diary
- First observedlog_custom_food
- First observedlog_food
- First observedlog_weight
- First observedsearch_food
- First observedwhoami

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: diary reading, food searching, nutrition detailing, two types of food logging, entry deletion, weight logging, and account info. No overlap that would confuse an agent.

Naming Consistency4/5

Tools mostly follow a verb_noun pattern (get_diary, search_food, log_food, delete_entry, log_weight). The exception is 'whoami', which is a standard command but doesn't fit the verb_noun convention, causing minor inconsistency.

Tool Count5/5

With 8 tools, the server is well-scoped for a food and weight tracking service. Each tool earns its place, covering diary, food database, logging, weight, and account queries.

Completeness4/5

Core workflows are covered: diary reading, food search and description, logging (both database and custom), deletion, weight logging, and account info. Missing update/edit functionality for diary entries, but agents can delete and re-log as a workaround.

Maintenance

ActivitySlowing

ResponsivenessUnresponsive

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

Open Food Facts Mcp
io.github.varvararatta
Unlock the power of food transparency with our Open Food Facts MCP server. Easily look up any food
Open Data Research & Data
2
acme-todo
com.ritzademo
An MCP server for a simple todo list
Developer Tools App Automation
2
mcp AOAuth
com.mux
The official MCP Server for the Mux API
Multimedia Processing Entertainment & Media API Testing
22168
mcpOAuth
com.zomato
An MCP server that exposes functionalities to use Zomato's services.
Search Travel & Transportation E-commerce & Retail
2131

Related MCP Servers

fatsecret-mcp-server
Health & Wellness Search
Yurzs
A
license
A
quality
D
maintenance
MCP server for managing food diary, nutrition tracking, meal planning, and weight logging via the FatSecret Platform API.
Updated 4 months ago (2026-05-16 10:03 UTC)
15
MIT
nutrition-mcp
Health & Wellness Open Data Databases
asachs01
A
license
Not graded
quality
D
maintenance
MCP server for USDA nutrition data lookup, meal logging, and daily macro tracking.
Updated 7 months ago (2026-02-08 23:17 UTC)
20
MIT
loseit
Fitness Tracking Databases
the-mace
A
license
Not graded
quality
B
maintenance
MCP server that reads local SQLite database populated by a Playwright scraper to provide daily summary, food log, weight history, and water log from LoseIt.
Updated 5 days ago (2026-08-31 17:06 UTC)
MIT
Macro Engine
rockitdev
A
license
Not graded
quality
B
maintenance
Tracks macros and logs meals via plain language by exposing a local USDA food database as an MCP server.
Updated 2 months ago (2026-07-17 23:46 UTC)
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/cabird/loseit-mcp'

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