Calorie Tracker MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.2/5 across 11 of 11 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 37 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true and readOnlyHint=false, so the mutation nature is already indicated. The description adds the 'after checking its expected revision' detail, which implies optimistic concurrency control but doesn't explain what happens on revision mismatch (error? no-op?). No disclosure of side effects beyond the patch, or behavior when revision is stale.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, which is positive. However, it's under-specified rather than appropriately concise. It front-loads the core purpose but leaves out essential details about parameters and behaviors.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with destructiveHint=true, no schema description coverage, and a complex nested patch object (MealPatchRequest with ~12 fields). Despite having an output schema, the description still needs to explain the revision-checking behavior, what fields are patchable, and what happens on failure. For a tool of this complexity (3 required params, nested patch structure, concurrency semantics), the description is notably under-complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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, but it doesn't mention any parameters. The description references 'expected revision' conceptually but doesn't explain what it means, how the patch object works, or how meal_id is used. With 3 undocumented parameters in the schema and zero coverage, the description fails to add meaning beyond what the raw schema field names convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Update') and resource ('meal') but 'selected meal fields' is vague about what fields can be updated. It distinguishes itself from delete_meal and log_meal siblings by being an update operation, but doesn't clarify what 'selected fields' means or how it differs from related operations. The revision-checking mention adds useful specificity about the update mechanism.
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?
The description gives no guidance on when to use this tool versus alternatives like log_meal, delete_meal, or get_meal. It doesn't mention when the expected_revision check would be relevant or what scenarios require updating vs logging. No exclusions or conditions for use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, providing a clear safety profile. The description adds 'bounded profile-local filters' which scopes the operation to a profile context. However, it doesn't describe pagination behavior, return format, or sorting, though the output schema exists. The description adds modest value beyond annotations but doesn't contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is clear and front-loaded with the verb 'list'. It names the resource (meals) and the scope (bounded profile-local filters). No wasted words, though it could potentially elaborate somewhat given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters at 0% schema description coverage, the description must compensate but doesn't. Key behaviors like pagination (cursor, limit), date filtering, include_deleted flag semantics, and search behavior are undocumented. The phrase 'bounded profile-local filters' is vague and doesn't explain the actual filtering dimensions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for explaining parameters but entirely fails to. The description's phrase 'bounded profile-local filters' vaguely references filtering but doesn't clarify what filter fields exist (dates, meal_type, confidence, search) or their semantics. Seven of eight parameters are completely undocumented in description text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' with resource 'meals' and scoping to 'bounded profile-local filters'. This reasonably distinguishes the operation from siblings like get_meal (singular) and get_meal_history. However, 'bounded profile-local filters' is somewhat vague and doesn't clearly state what filters are available.
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?
There is no guidance on when to use this tool versus alternatives like get_meal_history, get_summary, or export_meals. The description doesn't state when to use it, when not to, or mention any alternatives. This is a listing tool, and distinguishing it from get_meal_history (which may return a similar data shape) would be valuable but is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare idempotentHint=true and readOnlyHint=false, which signals a safe-to-retry write operation. The description adds the note that estimates are 'caller-supplied' and that an idempotency key is used, which is useful behavioral context about retry semantics. However, it doesn't disclose what the response contains or whether items can be optional (the schema shows a default of []). With annotations present, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero waste. It's concise and front-loaded. However, it's arguably too thin given the 16-parameter schema, but for what it states, it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which shifts some burden), this is a complex 16-parameter tool with 0% schema description coverage. The description does not explain the relationship between estimated_total_* and items, whether items are optional alternatives to totals, or how idempotency_key should be generated. For a write operation with this many interdependent parameters and no parameter-level documentation, the description is substantially under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 16 parameters (6 required), the description must compensate, but it only names two parameters (estimates and idempotency_key) without explaining their semantics. It doesn't clarify the relationship between estimated_total_* fields and the items array (are items derived from totals, or separate?). The schema provides names but no guidance on how items and totals interact, which is the crux of this API.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Log a meal using caller-supplied estimates and an idempotency key,' which clearly identifies the verb (log) and resource (meal) and distinguishes it from sibling tools like get_meal, update_meal, and delete_meal which are read/modify/delete operations. It doesn't differentiate from update_meal, but the 'Log' verb combined with readOnlyHint=false and idempotentHint=true clearly signals a creation action.
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?
The description gives no guidance on when to use this tool versus alternatives. It doesn't mention that this is for creating new meals (vs update_meal), doesn't explain the idempotency key's role in preventing duplicates, and doesn't note any prerequisites like authentication. A caller must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context — it clarifies that the date range is 'inclusive'. However, it doesn't describe what the returned summary contains or how output is structured. With strong annotations, the baseline is met and slight value is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with zero wasted words. It conveys the core purpose compactly. Could arguably add a bit more usage context, but for what it covers, it is very concise.
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 and strong annotations (readOnly, idempotent, non-destructive), the description covers the core purpose adequately. But the 0% schema coverage on parameters means the agent must guess at date/start_date/end_date combinations, and the description offers no help there. A little more parameter semantics context would raise this.
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 0%, so the description must compensate. The description mentions 'one date or an inclusive date range', hinting at the date/start_date/end_date parameters. However, it doesn't explain the relationship among the three params (all optional) or specify which combinations are valid — e.g., can you pass both date and start_date? This is minimal compensation for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Summarize' and the resource 'meals', and scopes it to 'one date or an inclusive date range'. This is clear and specific. However, it doesn't explicitly differentiate from siblings like get_meal_history or list_meals, though 'summarize' implies aggregation which distinguishes it somewhat.
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?
There is no guidance on when to use this tool vs alternatives like list_meals, get_meal_history, or export_meals. The description doesn't state what a 'summary' includes (totals? per-day breakdown?) or when summarization is preferable to listing. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (not read-only, not idempotent, not destructive), which means the description carries the burden of behavioral disclosure. The phrase 'after checking its expected revision' hints at optimistic-concurrency behavior but doesn't explain what happens on mismatch (error? no-op?). It also doesn't clarify whether this is a destructive operation or what state the meal returns to. The revision-check concept adds some value but is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence with zero wasted words. It front-loads the primary action and appends the key precondition. Efficient, though it could add a note about revision mismatch behavior without becoming verbose.
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?
There is an output schema, so return-format explanation isn't needed. However, for a mutation tool with no helpful annotations (all false), the description should do more: clarify the optimistic concurrency model, describe what a failed revision check produces, and explain the relationship to soft-delete. The description is adequate for a simple restore but leaves important behavioral questions unanswered given the complexity hinted by revision checking.
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 documentation coverage is 0%, so the description must compensate. It mentions meal_id indirectly (which meal to restore) and expected_revision (via 'checking its expected revision'), but doesn't explain what expected_revision means — e.g., what happens if the current revision differs, or how to determine the correct value. Since there are only 2 params, the description maps to both, but leaves semantics of the revision mechanism unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: "Restore a soft-deleted meal". It's specific about what the tool does. However, it doesn't distinguish from siblings like delete_meal or update_meal beyond implying it reverses a deletion, which is fairly clear given the naming.
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 when-to-use guidance is provided. It doesn't mention when restoration is appropriate (e.g., after a soft delete, before a hard purge), nor does it contrast with alternatives like update_meal or delete_meal. The description mentions checking 'expected revision' implying a precondition, but doesn't explain when to use this vs other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint=false, idempotentHint=false), and the description confirms mutation via 'set'. However, it doesn't disclose whether this creates a new effective-dated entry alongside existing goals, overwrites prior ones, or requires existing goals to be present. The effective-dating semantics deserve more explanation given no idempotency guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, informative sentence with no wasted words. Front-loaded with the verb and resource. Slightly under-specified but efficient.
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 output schema exists, so return format is covered. The tool has 3 required params and the description explains roughly half. The effective-dating mechanism is a meaningful behavior not explained anywhere, which matters for a non-idempotent write operation.
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 0%, so the description carries the burden, but it names only two of three parameters (calorie, protein) while silently omitting the crucial 'effective_from_date' parameter meaning. A helpful description would explain effective-dating behavior and how targets relate to each other. With high schema coverage (formats, exclusivity) providing baseline meaning, a 3 is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Set effective-dated daily calorie and protein goals') and clearly states what it modifies. It distinguishes from siblings like get_goals (retrieval) and log_meal (meal logging), though it doesn't explicitly name alternatives.
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 this is the write counterpart to get_goals and establishes the 'effective-dated' concept, which suggests planning context. However, it gives no explicit when-to-use guidance, prerequisites, or exclusions compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the destructive nature is established. The description adds value by specifying it's a 'soft-delete' (as opposed to hard delete) and that it checks expected revision before proceeding. However, it doesn't explain what happens on revision mismatch (error? no-op?), how to obtain the expected revision, or whether restore_meal can undo it.
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 concise sentence that packs in soft-delete semantics and the revision-check precondition. No wasted words; appropriately brief for a simple two-parameter deletion operation.
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 annotations declaring destructive behavior and an output schema present, the tool is reasonably specified. The description covers the key behavioral nuance (soft-delete, revision check). However, given there are sibling tools like restore_meal and list_meals that could provide context, and a 0% schema description coverage, additional detail about revision mismatch behavior or undo-ability would strengthen completeness.
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 0% and there are no parameter-level descriptions in the schema, so the description carries the burden. It mentions 'expected revision' conceptually, which hints at the meaning of the expected_revision parameter, and meal_id is self-evident. But it doesn't explain where to get the expected_revision value (from get_meal or get_meal_history?), nor its exact semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Soft-delete') and resource ('a meal'), and distinguishes from siblings like 'restore_meal' and 'update_meal' by indicating this is a deletion operation. It's clear but brief; the soft-delete nuance adds specificity beyond what the name alone conveys.
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 when to use it (when deleting a meal) and the revision-check mechanism suggests an optimistic-concurrency pattern, but it doesn't explicitly state when NOT to use it or contrast with alternatives like 'restore_meal' or 'update_meal'. The revision requirement hints at context but isn't elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, signaling this tool can write/destroy. The description adds that it can write 'to a local path' and mentions overwrite behavior is available, which aligns with the destructive hint. However, it doesn't disclose what gets overwritten, file permission requirements, or side effects beyond the annotation. The description adds modest context over the destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence that front-loads the purpose and key options (JSON/CSV, inline/path). No wasted words. However, it's arguably under-specified for the tool's complexity, so while concise, it could trade some brevity for more guidance on filters and output behavior.
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 tool has a destructiveHint, an output path (potentially writing files), and a nested filter object, yet the description offers minimal detail on these. An output schema exists, so return values are covered, but the write-to-disk behavior and overwrite semantics (which have destructive implications) are not explained. For a tool of moderate complexity with write behavior, this is adequate but leaves gaps around what output_path writes and overwrite consequences.
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 0%, so the description must compensate but doesn't detail any parameter semantics. However, the schema itself is rich with titles, defaults, and enums for the nested MealFilterRequest. Since the nested filters object is complex (8 fields with defaults and enums), the description could add value by explaining how filters bound the export, but relies on the schema. Baseline for 0% coverage would be low, but the schema's self-documenting titles lift comprehension. The description 'bounded meal page' does hint that filters limit the export scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Export) + resource (meal page) and clarifies output formats (JSON or CSV) and delivery modes (inline or to a local path). It's clear what the tool does, though it doesn't explicitly distinguish it from siblings like list_meals or get_meal. The phrase 'bounded meal page' hints at pagination/filtering scope but could be more explicit.
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 this is for exporting filtered meal data, but gives no explicit when-to-use vs alternatives. With siblings like list_meals and get_meal, there's no guidance on when export is preferred over listing. No exclusions or alternatives are named, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the retrieval key context (server-generated id) and implies single-record behavior, which is useful, but doesn't describe return format or the include_deleted behavior beyond what the params show. With strong annotations, this is adequate.
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 efficient sentence that front-loads the verb and resource. Zero wasted words, perfectly concise.
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 (which covers return values), strong annotations covering safety, and a simple fetch-by-id operation, the description is mostly adequate. The main gap is the unexplained include_deleted parameter, which could benefit from clarification about its semantics (e.g., whether deleted meals are normally excluded and what happens when true).
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 0%, and with 2 parameters, the description carries meaningful burdens. However, the description only covers meal_id (referenced as 'server-generated id'), which clarifies that meal_id isn't user-chosen. The include_deleted parameter is entirely unexplained — no description of what it does. This is incomplete coverage of the parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get one meal by its server-generated id' uses a specific verb (get) plus resource (meal) and identifies the retrieval key (server-generated id). It's clear in what it does, though it doesn't explicitly differentiate from siblings like list_meals or get_meal_history, relying on the 'one meal by id' scope which adequately separates it.
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 — retrieve a single meal by its id — but doesn't explicitly state when to prefer this over siblings like list_meals (for multiple meals) or get_meal_history. The 'server-generated id' phrasing hints at prerequisite knowledge (need an id) but doesn't state it as a requirement or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the 'immutable' trait of the history, which is useful context. However, it doesn't disclose what the output structure looks like or whether include_snapshots affects payload size/performance, though the output schema exists to partially cover return 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?
The description is a single, tight sentence with zero waste. It front-loads the verb and resource clearly. Appropriate for a simple read-only tool.
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-value documentation is covered by structured data. However, the include_snapshots parameter is unexplained in both schema and description (0% coverage), creating a real gap. The tool is relatively simple, so completeness is adequate but leaves the boolean parameter ambiguous—an agent can't tell what a 'snapshot' means in this context from the description alone.
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 0%, so the description carries the burden of explaining parameters. The description mentions 'revision history' but doesn't explain meal_id semantics or the include_snapshots boolean's meaning. The baseline 3 applies since schema is minimal; the description adds only marginal value by implying meal_id identifies which meal, but include_snapshots is completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get immutable revision history for one meal' with a specific verb (get), specific resource (meal history), and scope (one meal). It's clear, though it doesn't explicitly distinguish from the sibling get_meal or the restore_meal tool, so sibling differentiation is implicit rather than explicit.
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 noting it retrieves revision history for a single meal, which contrasts with list_meals. However, there's no explicit when-to-use vs alternatives guidance, no mention of how it relates to restore_meal (which would consume this history), and no exclusion criteria to help an agent choose between get_meal and get_meal_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the profile-local date semantics, which is useful context. However, it does not discuss return format, error behavior, or what happens when no goals exist for the date.
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 a single, efficiency-focused sentence with zero wasted words. 'Get the goals' plus the date qualifier conveys the purpose completely in one line.
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?
With only 1 parameter, comprehensive annotations, and an output schema present, the description's burden is light. The tool is structurally simple (read-only, single param), and the description covers the main semantic nuance (profile-local date). A stronger description could clarify return format when no goals exist, but overall it is adequate for the tool's simplicity.
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 0%, but there is only one required parameter ('date') with a clear format: date. The description mentions 'profile-local date', which hints that the date is interpreted in the profile's local timezone—adding value beyond the schema. However, this is minimal enrichment for a single obvious parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Get the goals') and adds scoping context ('applicable on a profile-local date'), which clarifies what is being retrieved. However, it does not explicitly distinguish itself from sibling tools like get_meal_history or get_summary, though 'goals' is a distinct concept from meals and summaries.
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 use case by mentioning 'profile-local date', clearly scoping when this applies. But it does not explain when to use this versus alternatives like set_goals (the write counterpart), or provide exclusions or alternatives. No explicit when/when-not guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Calorie_tracker_mcp_cli MCP server](https://glama.ai/mcp/servers/Yani3rt/Calorie_tracker_mcp_cli/badges/card.svg)](https://glama.ai/mcp/servers/Yani3rt/Calorie_tracker_mcp_cli)

Score Badge

Copy to your README.md:

[![Calorie_tracker_mcp_cli MCP server](https://glama.ai/mcp/servers/Yani3rt/Calorie_tracker_mcp_cli/badges/score.svg)](https://glama.ai/mcp/servers/Yani3rt/Calorie_tracker_mcp_cli)

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/Yani3rt/Calorie_tracker_mcp_cli'

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