Calorie Tracker MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| log_mealC | Log a meal using caller-supplied estimates and an idempotency key. |
| get_mealA | Get one meal by its server-generated id. |
| list_mealsC | List meals using bounded profile-local filters. |
| update_mealC | Update selected meal fields after checking its expected revision. |
| delete_mealA | Soft-delete a meal after checking its expected revision. |
| restore_mealB | Restore a soft-deleted meal after checking its expected revision. |
| get_meal_historyA | Get immutable revision history for one meal. |
| set_goalsB | Set effective-dated daily calorie and protein goals. |
| get_goalsA | Get the goals applicable on a profile-local date. |
| get_summaryB | Summarize meals for one date or an inclusive date range. |
| export_mealsA | Export a bounded meal page as JSON or CSV, inline or to a local path. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Each tool targets a distinct operation on meals, goals, or summaries. get_meal/get_meal_history/list_meals are differentiated by single-item, revision-history, and filtered-list purposes. Update/delete/restore are clearly distinct state-transition actions with unique semantics.
All tools follow a consistent verb_noun snake_case pattern (get_, set_, list_, log_, update_, delete_, restore_, export_, log_). Verbs are apt and descriptive, and the pattern is uniform throughout with no stylistic mixing.
Eleven tools is well within the ideal 3-15 range for a calorie tracker domain. Each tool earns its place: core CRUD (log/get/list/update/delete/restore), goals management, history, summary reporting, and export capabilities. No redundancy or bloat.
The surface covers the full meal lifecycle (log, read, list, update, delete, restore), goals get/set, history, summary, and export—a thorough set. Minor gaps exist, such as no bulk-delete or goal-archival/cleanup operations, but agents can accomplish all core workflows without dead ends.