ForkMate
Server Details
Effortless calorie tracking for people who train — just tell your AI what you ate.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 7 of 7 tools scored.
Each tool has a distinct purpose: diary retrieval (get_day, get_range), preferences (get_preferences), logging (log_meal), food lookup by barcode (lookup_barcode) or text (search_foods), and diagnostic (whoami). No overlap.
All tools follow a consistent verb_noun pattern with snake_case (e.g., get_day, log_meal, search_foods). whoami is a minor deviation but standard in diagnostics. Overall very consistent.
7 tools is well-scoped for a food diary assistant, covering all core functionalities without being excessive or insufficient.
Covers preferences, logging, lookup, search, and history. Missing update/delete for diary entries and set preferences, which are minor gaps.
Available Tools
12 toolsadd_pantry_itemAIdempotentInspect
Add a food to the user's pantry, or UPDATE it if it's already there (matched by name, any casing) — e.g. 'add rolled oats to my pantry'. Only name is required; include macros (for one serving), a serving label, a source, and a short note when you know them, so a later log can reuse them. Re-adding the same food REPLACES its details (an upsert — it never creates a duplicate). Only pass a source you actually got from search_foods/lookup_barcode; an unrecognized value is recorded as the user's own estimate ('client'). This does NOT log a meal — it only curates the user's staples.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The food to keep on hand, e.g. 'rolled oats'. | |
| note | No | Optional short note, e.g. 'the Costco tub'. | |
| macros | No | Macros for ONE serving of this food, when known. | |
| source | No | Where the macros came from, if grounded via search_foods/lookup_barcode (e.g. 'usda'). Defaults to your own estimate ('client'); unrecognized values are recorded as 'client'. | |
| serving | No | Serving label the macros are for, e.g. '1 cup' or 'per 100 g'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the upsert behavior ('never creates a duplicate'), replacement of details on re-add, and the handling of unrecognized source values (recorded as 'client'). These details go beyond the annotations, which only indicate idempotentHint and non-destructive. The description aligns with annotations and adds critical behavioral context.
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, well-structured paragraph that begins with the primary purpose, then explains the upsert nature, parameter details, and boundaries. Every sentence adds value without redundancy. It is front-loaded with the most important information, making it easy for an agent to quickly understand the tool.
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 all essential aspects: purpose, upsert behavior, parameter usage, source validation, and scope (not logging a meal). Given the tool has 5 parameters, nested objects, and no output schema, the description provides sufficient operational context for an agent to use 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 description adds meaningful context beyond the schema: it explains that macros are for one serving, that a serving label is for reuse later, and that source should come from specific tools. It also clarifies that only name is required. Although the schema already describes parameters (100% coverage), the description enriches understanding of their purpose and constraints.
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 explicitly states the tool adds or updates a food in the pantry by name, matching any casing. It gives a concrete example ('add rolled oats to my pantry') and clearly distinguishes it from logging a meal. This specificity and differentiation from sibling tools like log_meal and get_pantry earns a 5.
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 explains when to use the tool (to add or update pantry items) and provides clear guidance on parameter usage, such as only passing a source from search_foods/lookup_barcode. It also explicitly states what the tool does not do ('This does NOT log a meal'). However, it does not directly contrast with alternatives like remove_pantry_item or get_pantry, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_mealADestructiveIdempotentInspect
Delete a food from the user's diary — remove one food from an entry (by item_index), or the whole entry (omit item_index). Identify the entry by its id and local_date (both from get_day). This is a TRUE removal: the data is gone, with NO server-side tombstone and no undo. Deleting the last food in an entry removes the entry. Safe to retry — deleting something already gone is a no-op success. SAFETY: all calorie and macro values here — including carbohydrates — are ESTIMATES (from USDA / Open Food Facts or the user's own entry), approximate and not lab-measured or per-batch. They are for general nutrition tracking ONLY. Do NOT use them for insulin dosing, carb-counting for a bolus, blood-glucose prediction, or any other medical decision, and do NOT compute a dose or glucose estimate from them. For anything medical, direct the user to the product's own label and their care team.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The entry id to delete from (from get_day). | |
| item_index | No | Which food to remove (0-based). Omit to delete the whole entry. | |
| local_date | Yes | YYYY-MM-DD diary date of the entry (from get_day). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, idempotentHint=true), the description adds critical behavioral context: it is a 'TRUE removal' with no tombstone or undo, safe to retry (idempotent), and deletes the entry if the last food is removed. It also includes a detailed safety disclaimer about nutritional data not being for medical decisions.
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 front-loaded with the core purpose and usage, then adds important behavioral notes. The safety warning is lengthy but necessary given the medical disclaimer. Overall it is efficient, though the warning could be slightly condensed.
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 output schema, the description adequately explains the removal behavior, idempotency, and safety concerns. It could briefly note that calorie/macro values are affected, but the safety warning covers the essential completeness.
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 100%, and the description adds meaning beyond the schema: item_index is 0-based, and omitting it deletes the whole entry; id and local_date are expected to come from get_day. This clarifies usage beyond the schema descriptions.
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 verb ('Delete') and resource ('a food from the user's diary'), specifies two modes (remove a single food by item_index or the whole entry by omitting it), and distinguishes from siblings like remove_pantry_item (pantry vs diary).
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 explains when to use the tool (to delete a food or entry), how to identify the entry (by id and local_date from get_day), and how to control granularity (omit item_index for whole entry). It does not explicitly state when not to use it or compare to other deletion tools, but the safety warning advises against medical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dayARead-onlyInspect
Read the user's food diary for a day (entries + calorie/macro totals). SAFETY: all calorie and macro values here — including carbohydrates — are ESTIMATES (from USDA / Open Food Facts or the user's own entry), approximate and not lab-measured or per-batch. They are for general nutrition tracking ONLY. Do NOT use them for insulin dosing, carb-counting for a bolus, blood-glucose prediction, or any other medical decision, and do NOT compute a dose or glucose estimate from them. For anything medical, direct the user to the product's own label and their care team.
| Name | Required | Description | Default |
|---|---|---|---|
| local_date | No | YYYY-MM-DD; defaults to today. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds critical safety context: all calorie/macro values are estimates, unsuitable for insulin dosing or medical decisions. This goes well beyond 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?
The core purpose is front-loaded, then a paragraph of critical safety information follows. While verbose, every sentence serves a purpose; not overly concise but acceptable given the medical importance.
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 single-param tool without output schema, the description covers the task and provides essential safety context. It lacks details on return format, but the mention of 'entries + totals' is adequate.
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 100% (one parameter well-documented). The description adds no new parameter details, earning the baseline score of 3.
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 'Read the user's food diary for a day (entries + calorie/macro totals)' uses a specific verb (Read) and resource (food diary for a day), clearly distinguishing it from siblings like get_range.
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 for a single day's diary but does not explicitly state when to prefer this over siblings like get_range or other tools. The safety section provides medical disclaimers but not usage alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pantryARead-onlyInspect
Read the user's PANTRY — the foods they keep ON HAND (their staples), so you can suggest meals from what they actually have and pre-fill macros when they log one. Returns each item's name and, when the user saved them, macros (for the item's serving), a serving label, a source, and a short note. The pantry is the user's CURATED list of what they stock — separate from what they've logged (their diary) and from their frequents (what they log often). IMPORTANT: a source (e.g. 'usda') is the user's own CLAIM about where the macros came from, NOT a server-verified guarantee — treat it as a hint, never as certified.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating safety. The description adds important context about return values and especially the caveat that the 'source' field is the user's claim, not verified. This goes beyond 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?
The description is well-structured with key information front-loaded. It includes several clarifications in a few sentences, though it could be slightly more concise. Every sentence contributes 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?
Given no output schema, the description clearly states what is returned (name, macros, serving label, source, note). It also explains the relationship to other tools and data concepts, making it complete for an agent.
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 is empty. No parameters need explanation, so the baseline score of 4 is appropriate. The description does not need to add parameter semantics.
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 the specific verb 'Read' and clearly identifies the resource 'pantry'. It distinguishes the pantry from the user's diary and frequents, which differentiates this tool from sibling tools like 'get_day' and 'log_meal'.
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 explains when to use the tool (to suggest meals from pantry items, pre-fill macros) and distinguishes it from related concepts (diary, frequents). It does not explicitly state when not to use it, but the context of sibling tools provides that guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_preferencesARead-onlyInspect
Read the user's saved dietary preferences so you can tailor logging and suggestions WITHOUT re-asking every chat: their diet style, a structured list of allergies to avoid (the big-9 major allergens), foods they dislike, and a typical-portion note. IMPORTANT: the allergen list is self-reported and is NOT a safety guarantee — always tell the user to check ingredient labels themselves; cross-contamination and gaps in food data are not captured (see the returned allergy_disclaimer). The allergies field covers the major US allergens ONLY; a user may have an allergen outside it (e.g. mustard, celery, corn, mollusks, barley/rye) — ask about those directly. NEVER treat the dislikes list as an allergy: it is a taste preference to de-prioritize, never a safety exclusion.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating safe read. Description adds significant context: self-reported nature, safety disclaimer, coverage limitations (only major US allergens), and behavioral rules (never treat dislikes as allergies). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and includes necessary detailed caveats. Could be slightly more concise but each sentence adds critical value, especially the safety warnings.
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 zero parameters and no output schema, the description thoroughly covers what the tool returns, its limitations, and how to use the results appropriately. It is complete for the tool's 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?
No parameters are defined, so baseline is 4. The description effectively compensates by explaining the returned data and its semantics, adding value beyond the empty schema.
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 reads saved dietary preferences to tailor logging and suggestions without re-asking. It specifies the exact information retrieved: diet style, allergies, dislikes, portion note, distinguishing it from siblings like log_meal or search_foods.
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?
Explicitly states when to use (to avoid re-asking) and provides critical caveats: allergies are self-reported, no safety guarantee, must tell user to check labels, and instructs not to treat dislikes as allergies. Also advises to ask about non-US allergens directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rangeARead-onlyInspect
Read the user's diary across a date range, with per-day calorie/macro totals. SAFETY: all calorie and macro values here — including carbohydrates — are ESTIMATES (from USDA / Open Food Facts or the user's own entry), approximate and not lab-measured or per-batch. They are for general nutrition tracking ONLY. Do NOT use them for insulin dosing, carb-counting for a bolus, blood-glucose prediction, or any other medical decision, and do NOT compute a dose or glucose estimate from them. For anything medical, direct the user to the product's own label and their care team.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | YYYY-MM-DD (inclusive). | |
| start | Yes | YYYY-MM-DD (inclusive). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotation, description adds critical behavioral context: all values are estimates from USDA/Open Food Facts and not for medical use. Discloses that carbohydrates are also estimates.
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?
Front-loaded with purpose, then safety warning. No wasted words, though safety paragraph is somewhat lengthy but necessary. No extraneous 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?
No output schema, and description only mentions 'per-day calorie/macro totals' without detailing return structure (e.g., list of days, fields per day). Agent may need to infer return format. Good for a simple tool but could specify more.
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 100% with clear descriptions for start and end (YYYY-MM-DD inclusive). Description does not add extra meaning beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'read', resource 'user's diary', and scope 'across a date range, with per-day calorie/macro totals'. Distinguishes from sibling 'get_day' which is for a single day.
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 explicit comparison to alternatives like 'get_day' or 'search_foods'. Includes a negative safety guideline not to use for medical decisions, but lacks positive guidance on when to use this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
log_mealAInspect
Log what the user ate to their food diary. Parse the user's free text into items and, when you can, include estimated macros per item for accuracy. SAFETY: all calorie and macro values here — including carbohydrates — are ESTIMATES (from USDA / Open Food Facts or the user's own entry), approximate and not lab-measured or per-batch. They are for general nutrition tracking ONLY. Do NOT use them for insulin dosing, carb-counting for a bolus, blood-glucose prediction, or any other medical decision, and do NOT compute a dose or glucose estimate from them. For anything medical, direct the user to the product's own label and their care team.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | ISO-8601 instant the meal was eaten; defaults to now. | |
| meal | No | ||
| note | No | ||
| items | Yes | ||
| source | No | Optional provenance for these items. After search_foods/lookup_barcode, pass the candidate's source class (e.g. 'usda' or 'off') so the diary shows it's grounded. Defaults to 'client' (your own estimate). Unrecognized values are recorded as 'client'. | |
| local_date | No | YYYY-MM-DD diary date; defaults to the user's local date (from their timezone). Pass this to log a meal on a different day. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false) are limited, so description adds important behavioral context: all macro values are estimates, not for medical decisions. It also discloses parsing behavior and default parameter values. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with important safety information front-loaded. The safety warning is lengthy but necessary for a food-logging tool. 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 6 parameters (with nested items) and no output schema, the description lacks information about return values or error handling. It covers usage well but leaves gaps in expected behavior after logging.
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 50% with many parameters having descriptions (at, meal, items sub-fields). The description adds that parameters should include estimated macros and parse free text, but does not elaborate on each parameter beyond what schema already provides.
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 'Log what the user ate to their food diary' with specific actions (parse free text, include estimated macros). This distinguishes it from sibling tools like delete_meal, update_meal, and search_foods.
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 explains when to use this tool (when user eaten, parse text, include macros) and includes a safety warning against medical use. However, it does not explicitly mention alternatives or when NOT to use it, such as when only searching foods is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_barcodeARead-onlyInspect
Look up a packaged food by its UPC/EAN barcode via Open Food Facts. IMPORTANT: the macros are PER 100 g (see serving) — scale to the portion eaten before logging with log_meal. It MAY also carry serving_grams/serving_label for one household serving — offer 'N servings' when present, still scaling the per-100 g macros before logging. Pass the returned source to log_meal to preserve provenance. SAFETY: all calorie and macro values here — including carbohydrates — are ESTIMATES (from USDA / Open Food Facts or the user's own entry), approximate and not lab-measured or per-batch. They are for general nutrition tracking ONLY. Do NOT use them for insulin dosing, carb-counting for a bolus, blood-glucose prediction, or any other medical decision, and do NOT compute a dose or glucose estimate from them. For anything medical, direct the user to the product's own label and their care team.
| Name | Required | Description | Default |
|---|---|---|---|
| upc | Yes | UPC/EAN barcode, digits only (8–14 digits). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. Description adds critical behavioral details: macros per 100g, estimates, and a strong medical safety warning, all beyond 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?
Front-loaded with purpose and key instructions. The safety warning is verbose but essential. Overall well-structured with minimal 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?
Covers purpose, usage, scaling, provenance, and safety. Lacks explicit details on return fields but sufficient for a read-only lookup tool with no output schema.
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 100% for the single parameter 'upc'. Description restates barcode format but adds no new information beyond schema description.
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 it looks up packaged food by barcode via Open Food Facts. It specifies the barcode type (UPC/EAN) and distinguishes from sibling tools like search_foods and log_meal.
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?
Provides explicit instructions on scaling macros per serving and passing source to log_meal. Does not explicitly mention when not to use, but context implies it's only for barcodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_pantry_itemADestructiveIdempotentInspect
Remove a food from the user's pantry by name — e.g. 'take eggs off my pantry list'. This removes it from their on-hand STAPLES only; it does NOT delete anything from their food diary. Safe to retry — removing something that isn't in the pantry is a no-op success.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The food to remove from the pantry (any casing). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true. The description adds behavioral details: it only affects on-hand STAPLES, not food diary, and removal of nonexistent items is a no-op. This context goes beyond annotations, making the tool's behavior fully 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 two sentences long, with no wasted words. It front-loads the core action and scope immediately. Every sentence adds value, making it highly efficient.
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 simplicity (one required parameter, no output schema), the description is complete. It covers scope, idempotency, case insensitivity, and what the tool does not do. No additional context is needed.
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 100% schema coverage, the baseline is 3. The description mentions 'by name' and gives an example, but does not add significant new meaning beyond the schema's 'any casing' note. It is adequate but not exceptional.
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 specific verb 'remove' and resource 'pantry item', and clarifies it does NOT affect the food diary. The example 'take eggs off my pantry list' further clarifies the purpose. It distinguishes from sibling tools by specifying its scope is pantry items only.
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 states the tool is safe to retry and that removing a nonexistent item is a no-op success, which is a clear usage guideline. It also contrasts with food diary deletion. However, it could have explicitly mentioned alternatives like 'delete_meal' or when not to use this tool, so it's not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_foodsARead-onlyInspect
Search USDA FoodData Central and Open Food Facts for foods matching a query, returning candidates with macros and a source you can show the user. IMPORTANT: the macros are PER 100 g (see each candidate's serving) — scale them to the portion the user actually ate before logging with log_meal. A candidate MAY also carry serving_grams/serving_label for ONE household serving (e.g. 48 g / "1 frank") — when present, offer the user 'N servings' instead of asking for grams, but still scale the per-100 g macros to the resolved grams before logging. When you log a chosen candidate, pass its source to log_meal so the diary records real provenance (USDA/Open Food Facts) instead of an estimate. SAFETY: all calorie and macro values here — including carbohydrates — are ESTIMATES (from USDA / Open Food Facts or the user's own entry), approximate and not lab-measured or per-batch. They are for general nutrition tracking ONLY. Do NOT use them for insulin dosing, carb-counting for a bolus, blood-glucose prediction, or any other medical decision, and do NOT compute a dose or glucose estimate from them. For anything medical, direct the user to the product's own label and their care team.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max candidates to return (default 5, clamped to 1–10). | |
| query | Yes | Food to search, e.g. 'greek yogurt' or 'Chipotle chicken'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate `readOnlyHint=true` and `openWorldHint=true`. The description adds significant behavioral details: macros are per 100g, candidates may have `serving_grams`/`serving_label`, and the `source` field indicates provenance. It also clarifies that values are estimates, reinforcing the open-world nature. No contradictions.
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 somewhat verbose (over 300 words) but every sentence is purposeful. It is front-loaded with the core purpose, then important scaling instructions, then safety warnings. Could be slightly tighter, but the safety content is essential.
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 (searching external databases with scaling and safety concerns) and the absence of an output schema, the description is fully complete. It explains return values (macros, source, serving info), how to interpret them, and how to use the results with `log_meal`. Safety warnings address critical misuse.
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 100% for both parameters. The description adds value by providing examples for `query` (e.g., 'greek yogurt') and specifying default/clamping for `limit` (default 5, clamped to 1-10), which goes beyond the schema's descriptions.
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 searches USDA FoodData Central and Open Food Facts for foods matching a query, returning candidates with macros and a `source`. It distinguishes itself from siblings like `lookup_barcode` and `log_meal` by explaining its role in the workflow (search by query) and how to pass the source for logging.
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 extensive usage guidelines: how to scale macros per 100g, handle household servings, and pass the `source` to `log_meal`. It also includes safety warnings about not using for medical decisions. While it doesn't explicitly state when not to use vs alternatives, the context of searching by query vs barcode is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_mealAIdempotentInspect
Correct a food already logged to the user's diary — fix a wrong calorie/macro value, quantity, or name, or move an entry to a different meal. Identify the entry by its id and local_date (both from get_day) and the food by its item_index within that entry's items[]. Only the fields you send change; the macros you send are MERGED onto the existing ones (so sending just kcal leaves protein/carb/fat as they were). This overwrites the value IN PLACE — there is no history of the previous value. Editing never moves an entry to another day (to do that, delete and re-log). SAFETY: all calorie and macro values here — including carbohydrates — are ESTIMATES (from USDA / Open Food Facts or the user's own entry), approximate and not lab-measured or per-batch. They are for general nutrition tracking ONLY. Do NOT use them for insulin dosing, carb-counting for a bolus, blood-glucose prediction, or any other medical decision, and do NOT compute a dose or glucose estimate from them. For anything medical, direct the user to the product's own label and their care team.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The entry id to edit (from get_day). | |
| meal | No | Move the entry to a different meal label. | |
| name | No | ||
| note | No | ||
| macros | No | Corrected macros — only the components you send are changed. | |
| fluid_ml | No | Corrected fluid/hydration volume, in millilitres. | |
| quantity | No | Portion as stated, e.g. '2' or '1 cup'. | |
| item_index | No | Which food in the entry's items[] to edit (0-based). Required when changing a food's name/quantity/macros/caffeine/fluid; omit for an entry-level change (meal/note). | |
| local_date | Yes | YYYY-MM-DD diary date of the entry (from get_day). | |
| caffeine_mg | No | Corrected caffeine content, in milligrams. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important behaviors not in annotations: macros are merged, overwrites in place with no history, cannot change date. Safety disclaimer about estimates. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main action, effective structure. Slightly verbose due to safety warning, but necessary. Sentence earns its place.
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?
No output schema described; return value unspecified. However, given the tool's nature (edit in place), the description covers user-facing aspects well. Safety and constraints are well documented.
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 80%; description adds context on item_index purpose, macros merging, and when to omit. Small gap: caffeine_mg and fluid_ml have descriptions but not detailed context beyond schema.
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 it corrects a logged food's value, quantity, name, or meal, distinguishing from siblings like log_meal (log new) or delete_meal (delete). It specifies identification via id and local_date.
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?
Explicitly states when to use (correcting logged entries) and when not (cannot move to another day; delete and re-log instead). Provides safety warning against medical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiARead-onlyInspect
Diagnostic: returns the authenticated user id and scopes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds the context that it is a diagnostic tool, confirming safe usage. No behavioral traits beyond annotations are disclosed, but given the simple nature, it is sufficient.
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, concise sentence that is front-loaded with the purpose. No unnecessary 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 zero-parameter, no-output-schema diagnostic tool, the description fully captures its purpose and return value. No additional context is needed.
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 no parameters, so schema coverage is 100%. The description does not need to add parameter information; the baseline is appropriate.
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 it returns the authenticated user id and scopes, using a specific verb and resource. It is distinct from sibling tools which deal with days, meals, and foods.
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 explicit guidance on when to use versus alternatives. The diagnostic nature implies usage for identity checks, but no when-not-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!