# Reported issues for cronometer-api-mcp

Pod holds 14 of 14 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [cronometer-api-mcp](/mcp/cronometer-api-mcp).

## Most discussed

### Looking for Endpoints for Note Creation

Has anyone encountered the endpoints for Note creation and Note photo upload while analyzing the Android application?

Cronometer's Android app already supports exactly what I need (timestamp + text + one image) to post new Notes, so I'm hopeful.

I'm interested in contributing/testing an implementation to post a timestamped Note with an optional image if any of you already know the relevant endpoints.

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/44) · 2026-08-16 · closed · external user · 1 comment

### Bug: Server fails to start with mcp 2.0.0, ModuleNotFoundError: No module named 'mcp.server.fastmcp'

Hey thank you so much for building this!!

Just wanted to flag that I hit a crash on a fresh install today (Claude Desktop, macOS, `uvx cronometer-api-mcp`). It showed up on my end as the server just disconnecting, and the logs had this:

Traceback (most recent call last):
```
File "/Users/…/.cache/uv/archive-v0/…/bin/cronometer-api-mcp", line 6, in <module>
from cronometer_api_mcp.server import main
File "/Users/…/site-packages/cronometer_api_mcp/server.py", line 7, in <module>
from mcp.server.

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/37) · 2026-08-09 · closed · external user · 0 comments

### Docker image exposes /mcp unauthenticated — OAuth middleware is never in the request path

## Summary

The published container serves a fully functional, completely unauthenticated MCP
endpoint. Anyone who can reach the port gets read *and write* access to the
configured Cronometer account, including `add_food_entry`, `remove_food_entry`,
`mark_day_complete`, and `add_custom_food`.

This affects the README's own remote-deployment path, and setting the documented
OAuth variables does not change it.

## Reproduce

Image as shipped, only credentials set:

```bash
docker run -d -p 8080:80

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/19) · 2026-07-26 · closed · external user · 1 comment

### Feature: Include saturated fat and key micronutrients in get_daily_nutrition / get_food_log summary

I'm trying to capture and track saturated fat, however the MCP summary endpoints don't surface it.

Current behavior

get_daily_nutrition and get_food_log summary return only: calories, protein, carbs, fat, fiber, and alcohol.

Requested behavior

Include additional tracked nutrients in the daily summary, at minimum:
- Saturated fat (nutrient ID 606)
- Omega-3 (ID 10001) and Omega-6 (ID 10002)
- Cholesterol (ID 601)
- Trans fat (ID 605)

Ideally configurable or returning all tracked nutrients, s

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/13) · 2026-06-01 · closed · outside contributor · 3 comments

### Feature: Push custom recipes

What a brilliant repo. Thank you so much for this.

I am looking for functionality to push a text list of ingredients as a custom recipe similar to the app's "Import Recipe" feature. If this repo could do that, it would open the door to lots of programmable methods for me. Got a Patreon? 😄

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/7) · 2026-04-29 · closed · external user · 2 comments

### add_serving fails for CRDB/NCCDB foods when called with measure_id=0

## Summary

`CronometerClient.add_serving(food_id=..., measure_id=0 or None, grams=...)` works for user-created custom foods but is rejected by the backend for any food sourced from Cronometer's databases (CRDB, NCCDB, FDC-branded). The error returned is misleading and points the caller in the wrong direction.

## Reproduction

```python
from cronometer_api_mcp.client import CronometerClient
c = CronometerClient()

# Search for any CRDB/NCCDB-sourced food, e.g. Kaiku ÑAM Choco
foods = c.search_f

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/4) · 2026-04-25 · closed · outside contributor · 1 comment

### CronometerClient hits /api/v2/login rate limit on short-lived MCP/CLI invocations

## Summary

Every fresh `CronometerClient()` calls `/api/v2/login` from scratch because the token only lives in process memory. Anything that creates a handful of clients back to back -- the MCP server when invoked per request, one-off CLI scripts, automated jobs -- triggers Cronometer's per-account login throttle and gets locked out for ~15-30 minutes.

## Reproduction

```python
# Run this 6-8 times in separate processes within a couple of minutes:
from cronometer_api_mcp.client import Cronome

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/3) · 2026-04-25 · closed · outside contributor · 0 comments

### Feature: Support arbitrary units of measurement (not just grams) in add_food_entry

## Summary

The current `add_food_entry` tool accepts a `grams` parameter that passes directly through to the Cronometer mobile API's `grams` field. While this matches the underlying API, it places an unreasonable burden on callers — human or LLM — to know gram weights off the top of their head.

Nobody logs "I ate 136g of chicken breast." They think "I ate 5 oz of chicken" or "2 large eggs." Forcing gram-only input shifts the conversion burden to every tool caller, creating friction exactly whe

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/2) · 2026-04-22 · closed · external user · 1 comment

## Most recent

### _request()'s re-auth retry re-sends the original payload dict, so payloads with stale pre-auth state fail twice instead of recovering

## Summary

When `_request()` gets a `FAIL` response it invalidates the session, re-logs-in, and retries — but the retry re-sends the **same payload object** that was built before re-auth:

```python
self._invalidate_session()
self.login()
return self._request(endpoint, payload, _retried=True)   # same dict, only payload["auth"] is refreshed
```

Only `payload["auth"]` is rewritten on the retry path. Anything else in the payload derived from auth-time state — e.g. `serving.userId` in `add_servin

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/31) · 2026-07-31 · closed · external user · 0 comments

### add_serving() builds its payload (including userId) before _ensure_auth(), so the first write on a cold client fails with 'JSONObject["userId"] is not a int'

## Summary

`add_serving()` constructs the serving dict with `"userId": self._user_id` **before** calling `self._request()`, and `_request()` only runs `_ensure_auth()` after receiving the payload:

```python
serving = {
    ...
    "userId": self._user_id,   # None on a client that hasn't logged in yet
    ...
}
payload = {"serving": serving, "config": {"call_version": 2}}
data = self._request("/api/v2/add_serving", payload)   # _ensure_auth() happens in here
```

On a freshly started server wh

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/30) · 2026-07-31 · closed · external user · 0 comments

### Published image can't complete a session with current MCP clients (protocol version 2025-11-25)

`ghcr.io/rwestergren/cronometer-api-mcp:0.1.10` connects and then serves no tools to clients that negotiate MCP `2025-11-25` — claude.ai among them.

## Symptom

`initialize` succeeds and returns a session id, so the connection looks healthy. Every subsequent call fails:

```json
{"jsonrpc":"2.0","error":{"code":-32000,"message":"Bad Request: Unsupported protocol version (supported versions: 2025-06-18, 2025-03-26, 2024-11-05, 2024-10-07)"},"id":null}
```

In claude.ai this appears as a connecto

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/25) · 2026-07-27 · closed · external user · 0 comments

### Diary entries are stamped with the server process's local time — containerized deploys log everything at UTC

`add_food_entry` derives an entry's wall-clock time, its meal group, and its date from naive `datetime.now()` / `date.today()`, which read the **server process's** timezone rather than the user's. Local `uvx` runs are correct because the workstation supplies a timezone; the containerized path documented under **Transport** has none, so a remote deployment logs everything at UTC.

This also quietly breaks a documented contract. The README states:

> All date parameters use `YYYY-MM-DD` format and

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/24) · 2026-07-27 · closed · external user · 0 comments

### /authorize and /token perform no authentication — two anonymous requests yield the bearer token

## Summary

Where the OAuth middleware *is* in the request path (Dokku/Heroku per the README, or a
container entrypoint override), the flow that issues the bearer token authenticates
nobody. Two unauthenticated HTTP requests are enough to obtain `MCP_AUTH_TOKEN` and gain
full read/write access to the Cronometer account.

I understand from the `OAuthAuthorizationMiddleware` docstring that this is a
deliberately minimal single-user shim ("the 'authorization' is just confirming you're the
server ow

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/20) · 2026-07-26 · closed · external user · 0 comments

### Handle `result: "FAIL"` as an authentication failure and retry login

## Summary

Cronometer may return an expired-session error inside an HTTP 200 response as:

```json
{"result":"FAIL","error":"Authentication Failed"}
```

In `CronometerClient._request()`, the response-body check currently only recognizes `result == "FAILURE"`. As a result, a stale cached token is not invalidated and the request is not retried after logging in again.

## Affected version

- `cronometer-api-mcp` 0.1.8
- Reproduced with the stdio server launched through `uvx cronometer-api-mcp` on

[Read the thread](https://github.com/rwestergren/cronometer-api-mcp/issues/18) · 2026-07-23 · closed · external user · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/rwestergren/cronometer-api-mcp/issues).