Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bodylog log my lunch: chicken salad sandwich and a black coffee"
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.
A workout and food log for personal agents. You tell your agent your sets and your meals in chat, the way you would say them out loud. It stores them, counts calories and macros from real nutrition data, keeps your streaks, and sends back shareable cards.
One package for any agent: an MCP server (bodylog-mcp), a CLI (bodylog), a Python library and a
Claude skill. Everything lives in one local SQLite file. No accounts, no cloud, no social features.
Food day | Story | Workout |
|
|
|
More: food, light, food + training on one day (full), workout story, 8-exercise workout, two pages, mixed kg and lb, sticker for a photo.
Python 3.10+.
pip install bodylog # CLI + library + MCP server
uvx --from bodylog bodylog-mcp # run the MCP server without installingClaude Code, as a plugin (skill and MCP server together):
/plugin marketplace add abhaymettu/bodylog
/plugin install bodylog@bodylogClaude Code, MCP server only:
claude mcp add bodylog -- uvx --from bodylog bodylog-mcpAny other MCP client:
{
"mcpServers": {
"bodylog": {
"command": "uvx",
"args": ["--from", "bodylog", "bodylog-mcp"],
"env": { "FDC_API_KEY": "optional, free at https://api.data.gov/signup/" }
}
}
}Settings, all optional:
Variable | Default | What |
|
| the SQLite file |
|
| where card PNGs go |
| most-logged unit | kg or lb for workout totals |
|
| USDA FoodData Central key; DEMO_KEY allows only a few lookups an hour |
| off |
|
The skill is skills/bodylog/SKILL.md. Outside the plugin, copy or symlink skills/bodylog/ into
your agent's skills folder.
Related MCP server: MyFitnessPal MCP Server
The CLI prints what the MCP tools return (bodylog eat is log_food). A real run, offline:
$ bodylog eat "2 eggs, toast and a protein shake"
#1 breakfast: 2 × egg, 100 g: 143 kcal, P 12.6 C 0.7 F 9.5
#2 breakfast: toast, 22 g: 64 kcal, P 2 C 12 F 0.9
#3 breakfast: whey protein, 26 g: 92 kcal, P 20.3 C 1.6 F 0.4
$ bodylog eat "greek yogurt with blueberries and a handful of almonds"
#4 breakfast: greek yogurt, 170 g: 100 kcal, P 17.3 C 6.1 F 0.7
#5 breakfast: blueberries, 148 g: 84 kcal, P 1.1 C 21.4 F 0.5
#6 breakfast: 1 handful almonds: not counted (no weight for a handful of almonds; give grams or one of: almond, cup, oz)
$ bodylog food-fix 6 --grams 28
#6 breakfast: 28 g almonds: 162 kcal, P 5.9 C 6 F 14A bare count uses USDA's portion for that food: a large egg (50 g), a slice of toast, a scoop of whey (the FNDDS "1 scoop, NFS", 26 g). Through MCP, the agent asks one short question about item 6 instead of guessing.
How a food gets its numbers:
Bundled table. 62 common foods from USDA FoodData Central (SR Legacy and FNDDS), each with its
FDC id, per-100 g values and USDA's own portion weights (a large egg, a slice of bread, a cup of
rice). Works offline. Rebuilt from the USDA downloads by scripts/build_common_foods.py.
Cache. Anything looked up before, stored in the SQLite file.
USDA FoodData Central search (POST /fdc/v1/foods/search, survey, SR Legacy and Foundation
foods), with FDC_API_KEY or DEMO_KEY.
Open Food Facts search for branded and packaged foods, and product lookup by barcode
(GET /api/v2/product/<barcode>.json, no key).
A search result is used only when its name contains every word you said. Otherwise the item is kept
as unknown with the closest candidates, so the agent can ask which one you meant. An item whose
amount cannot become grams (a handful, or millilitres of something with no USDA volume weight) is kept
as needs_amount. Neither counts toward totals until it is fixed, and neither is ever filled with
made-up numbers. Numbers you read off a label are stored as given (manual).
Also: daily goals for kcal, protein, carbs and fat; a logging streak in days (a day you have not logged yet does not break it) and a training streak in weeks; and a day card in dark, light, clear or story format. On a day you also trained, the card adds a Training block.
The chat below comes from a real run through log_set(text=...). The right column shows what the
store recorded for each message.
you: push day -> title: Push Day
you: bench 20 kg x 10 warm up -> Bench Press: 20 kg x 10 (warmup)
you: 60kg x 10 -> Bench Press: 60 kg x 10
you: 67.5 kg x 4 -> Bench Press: 67.5 kg x 4
you: 62.5 kg x 8 rpe 9 -> Bench Press: 62.5 kg x 8
you: next incline db press 55 lb x 10 -> Incline Dumbbell Press: 55 lb x 10
you: same -> Incline Dumbbell Press: 55 lb x 10
you: 55lb x 9 -> Incline Dumbbell Press: 55 lb x 9
you: 12.5 kg x 12 -> Incline Dumbbell Press: 12.5 kg x 12
you: that was triceps pushdowns on the cable -> named 1 set(s) Triceps Cable Pushdown
you: 12.5 kg x 11 -> Triceps Cable Pushdown: 12.5 kg x 11
you: lateral raise 15 lb x 14 -> Lateral Raise: 15 lb x 14
you: 15 lb x 12 -> Lateral Raise: 15 lb x 12
you: one more -> Lateral Raise: 15 lb x 12
you: wrapped up, workout took 1h 3m -> ended session 4**Push Day**
Thursday, Sep 17 · 6:05 PM
1h 3m · 2,640 kg · 11 sets · 12 PRs
Muscles: Chest 55%, Shoulders 27%, Triceps 18%
**Bench Press** · Chest · 3 sets · best 60 kg x 10 · PR: Heaviest weight, Best 1RM, Best set volume, Most reps
W. 20 kg x 10 (warm-up)
1. 60 kg x 10 🏆 Best 1RM, Best set volume, Most reps
2. 67.5 kg x 4 🏆 Heaviest weight
3. 62.5 kg x 8 @ RPE 9
**Incline Dumbbell Press** · Chest · 3 sets · best 55 lb x 10 · PR: Best 1RM, Best set volume, Most reps
1. 55 lb x 10 🏆 Best 1RM, Best set volume, Most reps
2. 55 lb x 10
3. 55 lb x 9
**Triceps Cable Pushdown** · Triceps · 2 sets · best 12.5 kg x 12 · PR: Heaviest weight, Best 1RM
1. 12.5 kg x 12 🏆 Heaviest weight, Best 1RM
2. 12.5 kg x 11
**Lateral Raise** · Shoulders · 3 sets · best 15 lb x 14 · PR: Best 1RM, Best set volume, Most reps
1. 15 lb x 14 🏆 Best 1RM, Best set volume, Most reps
2. 15 lb x 12
3. 15 lb x 12
This week: 2 workouts, 4,687 kg (−14% vs last week to date)The last message ends the workout, so the tool returns this card along with the workout PNG at the top of
this page (end_session does the same). PRs are counted against the three earlier sessions in
tests/fixtures/chat.txt.
Sets: 60kg x 8, 60 x 8, 50lbs for 9, 8 reps at 60kg, 3x10 @ 90lb, 60kg 3x8, 12 reps
(bodyweight). Flags: warmup, drop set, to failure, rpe 9.
Exercises: named at the start of a message (incline db press 55 lb x 10), announced (now squats),
or named after the fact (this is tricep cable pushdowns btw). A set without a name continues the
last exercise.
Naming after the fact takes the sets that have no exercise yet. If every set already has one, it
takes the trailing run of carried-over sets at the last set's weight. That covers the usual case
where you move to a new machine and name it a set or two later. If you changed weight before naming
it, use edit_last_set(exercise=...) for the earlier sets.
Names are folded to one exercise: case, plurals, db/bb shorthand, word order, filler (on the),
and muscle words that don't change the movement. So tricep cable pushdowns, cable pushdown and
triceps pushdowns on the cable are one exercise, while triceps curl and biceps curl stay apart.
bodylog alias teaches any other name.
Commands: same / one more repeats the last set; done, 1h 5m / workout took 45 min ends the
workout. Agent replies in a pasted log (Agent:, Assistant:, Claude:) are skipped.
Volume is weight x reps over working sets. Warmups are listed on the card but excluded from volume,
set counts and PRs. Each set shows the unit it was logged in. Totals convert every set exactly into
one unit: the unit you pass, else $BODYLOG_UNIT, else whichever unit most sets used.
Muscle split is the share of working sets per primary muscle group, from a name map in
muscles.py that covers the common lifts (unknown names count as Other). Percentages always add
to 100.
Estimated 1RM uses the Epley formula, weight x (1 + reps / 30).
PRs are counted against sessions that started earlier: heaviest weight, best estimated 1RM, best set volume (weight x reps in one set), and most reps at a weight you have lifted before (one per exercise, the largest gain). The first time you do an exercise sets no PRs, so a first workout does not show a PR on every set.
The week line compares this week with last week up to the same weekday and time, so a Monday workout is not shown as a 90% drop.
Duration is what you say at the end. The session start is set to end time minus that duration.
Tool | What it does |
| Add a set to the open workout (opens one if needed). Structured fields or the raw message as |
| Fix or delete the last set. |
| End the workout with the duration the user gives ("1h 5m"). Returns the card as text plus PNG pages. |
| Card for any session: |
| Progress per exercise, all-time records, volume per week. |
| Backfill workouts from a pasted chat log. Safe to repeat. |
| Log food from the user's words, or one item by name, barcode or food id with an amount, or with label numbers. Returns each item's status and the day's totals. |
| Fix an item: amount, food, meal or numbers; or delete it. |
| Search by name or barcode without logging. |
| A day's items by meal, totals, goals, what is left, streaks, flagged items, workouts. |
| The day card as text plus a PNG: |
| Daily targets; logging and training streaks. |
bodylog log "bench 60kg x 8"
bodylog end "1h 5m" --title "Push Day"
bodylog eat "chicken breast 180g, 1.5 cups rice and broccoli"
bodylog food-fix 12 --grams 28
bodylog goals --kcal 2400 --protein 160
bodylog food-card --style story
bodylog --helpfrom bodylog import Store, log_text, log_food, day_summary, summary, render_png
from bodylog.foodcard import render_png as food_png
store = Store() # ~/.bodylog/log.db
log_text(store, "bench 60kg x 8")
log_food(store, "2 eggs, toast and a protein shake")
food_png(day_summary(store), "today.png", style="story")The MCP Python SDK needs a few lines per tool, Pillow draws the cards with no browser, and sqlite3
and urllib ship with Python. Runtime dependencies are Pillow and mcp. Cards use Inter (SIL Open
Font License, bundled in src/bodylog/fonts/), so they look the same everywhere.
uv sync
uv run pytest # offline: API calls replay recorded responses
uv run python scripts/render_examples.py # regenerate examples/ (offline)Tests never touch the network or the repo: tests/fixtures/http/ holds real USDA and Open Food Facts
responses, and every file a test writes goes to a temp dir.
Layout: store.py (SQLite), names.py, chatlog.py, stats.py, muscles.py, card.py (workouts),
food.py (meal parsing, matching, totals, streaks), sources.py (USDA and Open Food Facts),
foodcard.py (day card), cli.py, server.py (MCP), data/common_foods.json (bundled USDA table).
Food data: USDA FoodData Central (public domain) and Open Food Facts (Open Database License; product data is attributed to Open Food Facts contributors).
Fix a logged food item by id: a new amount (grams, or amount + unit), another food (name, or food_id from lookup_food or an item's candidates), another meal, or the numbers themselves. delete=True removes it.
| Name | Required | Description | Default |
|---|---|---|---|
| fat | No | ||
| kcal | No | ||
| meal | No | ||
| name | No | ||
| unit | No | ||
| carbs | No | ||
| grams | No | ||
| amount | No | ||
| delete | No | ||
| food_id | No | ||
| item_id | Yes | ||
| protein | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confidently discloses that this is a mutation operation and specifically warns that delete=True removes the item. However, it does not state whether unspecified fields are preserved or reset, what permissions are needed, or what happens after deletion; with no annotations, these are meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the item_id and the core editing scopes. The parenthetical lists are dense but efficient; only slight clutter remains in phrasing like 'or the numbers themselves.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter mutation with no annotations and no output schema, this description is serviceable but incomplete. It provides useful lookup guidance and delete behavior, yet omits partial-update semantics and validation constraints, so an agent could still mis-invoke the tool with conflicting or incomplete parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description maps nearly all 12 parameters: grams/amount/unit, name/food_id, meal, kcal/carbs/fat/protein, item_id, and delete. It adds substantial meaning beyond bare titles, though it does not handle edge cases like whether amount requires unit or how name is disambiguated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific operation ('Fix a logged food item by id') and enumerates the editable dimensions: amount, unit, food, meal, and macro numbers. This clearly distinguishes edit_food from log_food (new entries) and lookup_food (search), even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes that the tool targets an existing logged item identified by item_id and points to lookup_food or an item's candidates for food_id. It does not explicitly say when not to use it or name log_food as the alternative for new entries, so it is clear but not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fix the most recent set in the open workout ("that was 10 reps", "that was cable pushdowns"), or delete it.
| Name | Required | Description | Default |
|---|---|---|---|
| rpe | No | ||
| kind | No | ||
| reps | No | ||
| unit | No | ||
| notes | No | ||
| delete | No | ||
| weight | No | ||
| exercise | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions that it can fix or delete the last set, but does not state prerequisites (e.g., an open workout with at least one set), side effects of deletion, or any return value. This is insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that front-loads the core action and includes illustrative examples. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 optional parameters, no output schema, and no annotations, this description is far too minimal. It does not explain how to choose parameters for edit vs delete, whether fields are mutually exclusive, or any operational requirements. The agent would struggle to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not map its examples to parameters. The phrases 'that was 10 reps' and 'that was cable pushdowns' hint at reps and exercise/kind, but no explicit linkage to the 8 parameters is provided, leaving the agent guessing how to specify edits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fix the most recent set') and the resource (the open workout's last set), with concrete examples of corrections. It also mentions the alternative delete action. This distinguishes it from siblings like log_set (adding sets) and edit_food (different domain).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use when correcting the most recent set in the open workout, with illustrative phrases. It does not explicitly contrast with log_set or state when not to use it, but the scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End the open workout. duration is what the user says ("1h 5m", "65 min", "1:05"); title is optional ("Push Day"). unit (kg or lb) sets the totals' unit. Returns the summary card as text and PNG images (one per page; long workouts span several) to show the user.
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | ||
| theme | No | dark | |
| title | No | ||
| duration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does most of the work. It discloses parsing behavior for duration, optional title, unit selection, and the return format including text, PNG images, and multi-page output for long workouts. It stops short of noting edge cases like calling end_session with no open workout.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: 'End the open workout.' appears first, followed by efficient parameter details and return behavior. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action, parameter behavior for three of four parameters, and the return value despite lacking an output schema. It is slightly incomplete because theme is undocumented and there is no guidance about preconditions or alternative tools, but it provides enough for a capable agent to invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains duration with concrete examples, clarifies that title is optional, and specifies unit values (kg or lb) and their effect on totals. However, the theme parameter is not mentioned at all, leaving one of four parameters semantically unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'End the open workout.' It clearly identifies the operation and distinguishes it from sibling tools like session_card and log_set by focusing on ending the session. It also states the return artifact, which reinforces the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a workout is finished, but it provides no explicit when-to-use guidance or alternatives. It does not mention conditions like needing an open workout first, or when a sibling tool such as session_card should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-session history for one exercise, newest first: sets, best set, top weight, estimated 1RM, volume.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| exercise | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral transparency itself. It does so by specifying newest-first ordering, per-session granularity, and the exact metrics returned. It still leaves the response shape and limit behavior implicit, but for a read-oriented history tool this is a reasonable level of disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence contains the resource, ordering, and output fields. Every phrase earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool, the description covers the core needs: what it returns, at what granularity, and in what order. It is not fully complete because usage guidance and limit semantics are omitted, but the missing pieces are relatively minor given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that the history is 'for one exercise', linking to the exercise parameter, and the default limit is visible in the schema. However, the meaning of limit (number of sessions returned) is not explicitly described, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as per-session history for one exercise and specifies ordering and returned metrics. It lacks an explicit verb such as 'retrieve/list' and does not explicitly contrast with sibling tools like prs or weekly_volume, but its scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided: it never states when to choose this tool over prs, weekly_volume, or session_card, nor does it mention exclusions. The agent must infer the tool's place from its name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shareable card for a day of food (default today): text plus a PNG. theme: dark, light or clear; style: full (every item) or story (one phone screen). Workouts that day appear on it too.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| style | No | full | |
| theme | No | dark |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses useful behavioral details: it produces text plus a PNG, defaults to today, and includes workouts for that day. With no annotations provided, it still does not cover side effects, authentication needs, delivery mechanism of the PNG, or rate limits, leaving partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core purpose and then efficiently enumerates the option values with parenthetical clarifications. Every phrase earns its place with no repetition of schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with three optional parameters, the description covers the main semantics and output format. However, with no output schema or annotations, an agent still has to infer how the PNG is returned and what date format is expected, so completeness is adequate but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden of explaining parameters. It provides meaning for date (default today), theme (dark, light, clear), and style (full or story), and adds the important clarification of what each style means. Date format is not specified, but the core semantics are present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a shareable card for a day of food, with text plus a PNG, and mentions that workouts appear on it too. It lacks an explicit action verb like 'generate' or 'returns', but the intent is unambiguous and it is visually distinct from siblings like session_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a user wants a visual food-day card, and the defaults suggest typical behavior. However, it never explicitly states when to choose this tool over alternatives such as food_day or session_card, nor does it mention cases where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One day's food (default today, YYYY-MM-DD): items by meal, totals, goals and what is left, streaks, items not counted, and any workouts that day.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description does most of the work by disclosing what is included in the day summary, including streaks and workouts. However, it does not explicitly state whether this is a read-only operation, whether authentication is needed, or what happens when no data exists for the day, so some behavioral ambiguity remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core subject and then lists the returned content in a scannable colon-separated list. Every phrase adds value and no unnecessary information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-style summary tool with one optional parameter and no output schema, the description covers the scope well: date default, date format, and a thorough list of expected outputs. It would be more complete with an explicit 'returns' statement and empty-day behavior, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the single optional date parameter, so the description's clarification of 'default today, YYYY-MM-DD' adds meaningful meaning. This is the key semantic information an agent needs to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a single day's food summary and enumerates the returned content areas: items by meal, totals, goals, remaining amounts, streaks, uncounted items, and workouts. It is clear enough to be distinguished from sibling log/edit tools, though it lacks an explicit verb and does not name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—to view or summarize food data for a day, defaulting to today—and specifies the date format YYYY-MM-DD. It does not explicitly state when not to use it or name alternative tools like food_card, log_food, or streaks, so the usage guidance is adequate but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Backfill workouts from a pasted chat log (lines like "[2026-09-08 18:07] me: 60kg x 8"). Safe to repeat: time spans that already hold sets are skipped. Lists lines it could not read.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses idempotency ('time spans that already hold sets are skipped') and error reporting ('Lists lines it could not read'), which are critical for a write operation. It does not mention potential side effects like whether it creates a new session or modifies existing data, but the disclosed traits are valuable and not redundant with schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core purpose is front-loaded, followed by the safety note and error behavior. Every clause adds information; there is zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema or annotations, the description covers the essential aspects: what it does, input format, idempotency, and error reporting. It does not specify whether it returns a summary or whether it ties to an active session, but given the simplicity, the coverage is strong. Slightly more detail on the return value or session context would make it a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'text' with 0% description coverage. The description compensates by giving an explicit example of the expected format ('[2026-09-08 18:07] me: 60kg x 8'), which makes the parameter's semantics clear. It could be more explicit that 'text' is the entire chat log, but the example is sufficient for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Backfill') and resource ('workouts') plus the source ('pasted chat log'), and gives an example line format. This clearly distinguishes it from sibling tools like log_set (single set entry) and edit_last_set (editing), leaving no ambiguity about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage context: when you have a chat log to backfill workouts from. It does not explicitly list alternatives or when-not-to-use, but the purpose is distinct enough that an agent can infer when to invoke it. The idempotency note ('Safe to repeat') also guides repeated use. Missing explicit exclusion of other tools, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log food. Usually pass the user's words as text ("2 eggs, toast and a protein shake", "lunch: 200g chicken, 1 cup rice"); it is split into items and each is matched to USDA FoodData Central or Open Food Facts. For one item: name (or barcode, or a food_id from lookup_food) with grams, or amount + unit (cup, slice, tbsp, oz, ml...). Pass kcal/protein/carbs/fat when the user reads them off a label. meal: breakfast, lunch, dinner or snack (default from the words, else the time of day). Each item has a status: ok / manual count; unknown (no match; see candidates) and needs_amount do not count until fixed with edit_food. Returns the items and the day's totals so far.
| Name | Required | Description | Default |
|---|---|---|---|
| fat | No | ||
| kcal | No | ||
| meal | No | ||
| name | No | ||
| text | No | ||
| unit | No | ||
| carbs | No | ||
| grams | No | ||
| amount | No | ||
| barcode | No | ||
| food_id | No | ||
| protein | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses how text is split and matched to USDA/Open Food Facts, the per-item statuses, that unknown and needs_amount items do not count until fixed with edit_food, and that it returns items plus day totals. This is unusually transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It is front-loaded with the main usage pattern, then covers structured input, macros, meal defaults, item statuses, and the return value in a logical order. Nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, 12 parameters, no output schema, and no annotations, this description is remarkably complete. It covers all input modes, parameter combinations, units, meal defaults, status semantics, and the return shape. An agent has enough information to call it correctly in most real scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates completely by explaining every parameter: text, name, barcode, food_id, grams, amount, unit, kcal, protein, carbs, fat, and meal. It even gives examples of valid units and when to use each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action, 'Log food,' and immediately explains the main use case. It clearly distinguishes this tool from siblings like lookup_food and edit_food by pointing to them explicitly, so an agent can tell exactly what log_food does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: pass natural-language text, or use structured fields like name/barcode/food_id with grams or amount+unit, and pass macros when reading a label. It also documents meal options and defaults. It does not explicitly state when not to use this tool in favor of log_set or other siblings, so it stops just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a set to the current workout, starting one if none is open.
exercise: name as the user says it ("incline db curl"); omit to reuse the last set's exercise. weight/unit: 0 or omitted for bodyweight; unit is kg or lb (defaults to the last unit used). kind: normal, warmup, drop or failure. count: identical sets at once ("3x10"). text: alternatively, the user's raw message ("62.5kg x 6", "same", "this is tricep pushdowns btw"). Returns the logged sets and any PRs they set. A text that ends the workout ("done, 1h 5m") returns the card.
| Name | Required | Description | Default |
|---|---|---|---|
| rpe | No | ||
| kind | No | normal | |
| reps | No | ||
| text | No | ||
| unit | No | ||
| count | No | ||
| notes | No | ||
| weight | No | ||
| exercise | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It documents side effects (starting a workout if none is open), state reuse (last exercise/unit), defaults (bodyweight, unit), and return behavior (logged sets, PRs, and the workout-end card).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose, followed by terse parameter guidance. Every sentence adds useful information, and the concrete examples make behavior concrete without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nine parameters, no output schema, and no annotations, the description covers the core workflow, parameter semantics, defaults, return values, and special text behavior. An agent has enough context to invoke this tool correctly in most conversational scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for exercise, weight, unit, kind, count, and text, including concrete examples and defaults. It does not explicitly explain reps, rpe, or notes, though reps and notes are reasonably self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Log a set to the current workout," and adds an important scoping behavior ("starting one if none is open"). This clearly distinguishes it from siblings like edit_last_set, end_session, and log_food.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly establishes the context for use: logging a set in the current workout, with special handling for raw text input and workout-ending messages. It does not explicitly name alternative tools or exclusion criteria, but the intended use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search foods without logging: a name ("kimchi", "clif bar") or a product barcode. Returns candidates with per-100 g macros, portions and a food_id to pass to log_food or edit_food.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| barcode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It explicitly states the tool does not log, accepts name or barcode input, and returns candidates with macros, portions, and a food_id. This is substantive behavioral disclosure, though it doesn't cover edge cases like no results or ambiguous matches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the core purpose, give concrete examples, and summarize the return value. Every element earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with no annotations and no output schema, the description covers input forms, return fields, and downstream usage. It could be slightly more explicit about requiring at least one parameter, but overall an agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by mapping 'query' to a food name and 'barcode' to a product barcode, with examples. It clarifies that the two parameters are alternative search modes, adding meaning beyond the bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Search foods without logging', and immediately distinguishes it from mutation tools by noting it returns a food_id to pass to log_food or edit_food. This clearly differentiates it from the sibling logging tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context — use this to search foods before logging or editing, without creating a log entry. It implicitly tells the agent when to use it versus log_food/edit_food, though it doesn't explicitly name alternatives or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All-time records (heaviest weight, best estimated 1RM, most reps) for one exercise or all of them.
| Name | Required | Description | Default |
|---|---|---|---|
| exercise | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It specifies what data is returned (heaviest weight, best estimated 1RM, most reps), but does not explicitly state that the operation is read-only or has no side effects. It also leaves 'all-time' and the exact computation of estimated 1RM open to interpretation. The description adds context beyond the name but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the record types and clearly states the scope. Every word earns its place; there is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema and no annotations, the description provides the essential information: what records are returned and how to scope them to one exercise or all. It does not detail the return format, but that can be inferred from the record types listed. It also lacks a note distinguishing it from sibling tools, but it is still sufficient for invoking correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a nullable string parameter with no description, so coverage is 0%. The description compensates by explaining how the parameter behaves: providing an exercise returns records for that exercise, while omitting it returns records for all exercises. This fully addresses the intended use of the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning all-time personal records, listing concrete record types (heaviest weight, best estimated 1RM, most reps) and specifying the scope (one exercise or all). Although the verb is implied rather than explicit ('get' or 'list'), the resource is unambiguous and distinct from sibling tools like exercise_history or weekly_volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives such as exercise_history or weekly_volume. The only usage hint is the optional exercise filter, which is more about parameter semantics than decision-making; no conditions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summary card (text + PNG pages) for a workout: the open one, else the latest. theme: dark, light, or clear (transparent background, a sticker for a photo); unit: kg or lb for totals (each set keeps the unit it was logged in); style: full (every set, may span pages) or story (one phone-screen image, one line per exercise).
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | ||
| style | No | full | |
| theme | No | dark | |
| session_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It discloses output format (text + PNG pages), theme behaviors (transparent background for clear), unit behavior (each set keeps its logged unit), and style differences (full spans pages, story is one screen). It does not state whether the operation is read-only, how errors are handled, or what happens if no session exists, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that packs purpose and parameter details efficiently. It front-loads the purpose and then explains options. It could benefit from line breaks for readability, but it is concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description covers the output format, selection logic, and three parameters. It omits session_id semantics and does not address edge cases like missing sessions or error behavior. This leaves an agent without full guidance for correct invocation, especially when specifying a session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It describes theme, unit, and style with their allowed values and meanings, but does not explain session_id at all. Since session_id is a key parameter (though optional), the description is incomplete for one of four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: generates a summary card for a workout, selecting the open session or latest if none. It names the resource (workout) and specifies the output format (text + PNG pages). It does not explicitly differentiate from sibling tools, but the context of 'workout' distinguishes it from food-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context about when to use the tool (for a workout) and how the session is selected, but does not explicitly state when to prefer this over other tools. There is no mention of alternatives or exclusions, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily targets (kcal, grams of protein/carbs/fat). Omitted ones stay as they are; 0 clears one.
| Name | Required | Description | Default |
|---|---|---|---|
| fat | No | ||
| kcal | No | ||
| carbs | No | ||
| protein | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and discloses two important traits: omitted parameters leave existing targets unchanged, while 0 clears a target. It does not cover response shape or validation behavior, but the central mutation semantics are clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the target definition and then state the behavior rules; there is no filler. Every phrase contributes meaning not already in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 plus schema give enough to call the tool correctly for the common cases: pass a numeric target to update it, omit a field to keep current, and use 0 to clear. A small ambiguity remains about whether explicitly sending null is treated the same as omission, but this is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only names and nullable number types with 0% description coverage, so the description adds nearly all the parameter meaning: kcal and grams for protein/carbs/fat. It also explains how null/omission and 0 behave, which is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as daily targets and spells out the exact fields: kcal, protein, carbs, and fat. It lacks an explicit verb like 'sets' or 'updates', relying partly on the tool name, but the meaning is unmistakable and distinct from the other food-logging siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use set_goals versus any alternative, nor are prerequisites or exclusions mentioned. The need to use it for setting daily targets is only implicit from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current food-logging streak in days (and the best), and training streak in weeks with a workout.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does add useful context: units (days vs weeks), the 'best' value, and the training streak definition ('with a workout'). However, it does not explain edge behavior such as how a current streak is calculated, timezone effects, or whether the data is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one compact sentence with no filler or repeated information. The core values are front-loaded and every phrase adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, simple lookup tool, the description is nearly complete: it names both streak types and their units. Since there is no output schema, a bit more detail about the return shape or how 'best' is determined would have been helpful, but not much is missing for an agent to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema already makes that explicit with 100% coverage. With no inputs to document, the description does not need to compensate, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: current food-logging streak in days plus best, and training streak in weeks with a workout. It lacks an explicit retrieval verb like 'returns' or 'gets', but the meaning is unmistakable. It also differentiates between two distinct streak types, which helps an agent understand what data is involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus sibling tools such as prs, weekly_volume, or exercise_history. The description only states what the tool reports, not under what circumstances an agent should choose it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Training volume, workouts and sets per week (Monday start), oldest first.
| Name | Required | Description | Default |
|---|---|---|---|
| weeks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses ordering (oldest first) and week boundary (Monday), but does not explicitly state that the tool is read-only, how it handles partial weeks, or what the response format is. Some value added, but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler and the key facts (volume, workouts, sets, week start, ordering) are front-loaded. However, it is so sparse that it omits important parameter guidance, though conciseness itself is excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description should explain the parameter's meaning and the nature of the returned data. It explains the data categories but not the 'weeks' parameter or response shape, leaving an agent under-informed when customizing the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the 'weeks' parameter at all. The agent cannot learn from the description what 'weeks' controls (e.g., number of weeks to return), so the parameter's meaning is left entirely to inference from its name and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides training volume, workouts, and sets per week, with a Monday start and oldest-first ordering. It distinguishes this from siblings like exercise_history or prs by focusing on weekly aggregates, though it lacks an explicit verb like 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus siblings like exercise_history or session_card. No context about use cases, prerequisites, or alternatives is provided, leaving the agent to infer when weekly_volume is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0edit_foodedit_last_setend_sessionexercise_historyfood_cardfood_dayimport_chatlog_foodlog_setlookup_foodprssession_cardset_goalsstreaksweekly_volumeScored across 15 tools
Tools are mostly distinct by domain: food vs. workout logging, and card generation vs. raw data. A few pairs (food_card/session_card, lookup_food/log_food, prs/exercise_history) could be confused, but their descriptions clarify the boundaries well.
All names are snake_case and readable, but the pattern is mixed: some are verb-first (log_food, end_session, edit_food) while others are noun-first (food_card, session_card, weekly_volume, prs). This is a readable mixed convention rather than a consistent one.
Fifteen tools is at the upper end of the typical range, but the server covers two distinct domains—food logging and workout logging—and each tool has a clear, non-redundant purpose. The count feels appropriate for the stated scope.
The surface covers food logging, editing, searching, goals, summaries, and cards, plus workout logging, workout cards, history, PRs, volume, streaks, and chat import. The main gap is that workout set editing is limited to the most recent set, with no way to edit or delete arbitrary past workout entries.
Log workouts and meals by telling your AI. 873 exercises, muscle diagrams, food lookup.
Log what you ate by talking to your AI assistant — calories and macros, completely free.
Food logging, nutrition summaries, and meal photo calorie and macro estimates.
Track workouts, nutrition, body metrics, habits, and SMART goals with insights and trends. Connect…
