YAZIO MCP

by tomastaker

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but get_daily_summary, get_diary, and get_nutrition_trends overlap in returning summary/diary data. The detailed descriptions help, but an agent could misselect between get_diary and get_daily_summary.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern: get_* for reads, add_* for inserts, update_*/remove_* for modifications, plus search_, compare_, and detect_. No mixed styles or vague verbs.
Tool Count4/5
17 tools is slightly above the ideal range but still well-scoped for a nutrition tracking domain covering diary, products, goals, water, weight, exercises, and analytics. Each tool has a clear role, so it does not feel bloated.
Completeness3/5
The set covers CRUD for diary items (add, update, remove, get) and water intake, but missing write operations for goals, weight, and exercises. Notably, get_goals and get_weight exist without corresponding update/add, leaving obvious gaps for a complete tracking experience.
Average 3.8/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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
This repository is licensed under MIT License.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects: preview, duplicate checking, idempotent write, and diary reread. This goes beyond annotations which only indicate readOnly=false, idempotent=true, and destructive=false. No contradictions exist.
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 sentence, efficient, and front-loaded with the most important behavior. Every word adds value, and there is no wasted text.
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?
For an 8-parameter tool with an output schema, the description covers core behavior but lacks parameter semantics and usage context. The presence of annotations and output schema helps, but the description alone is insufficient for correctly invoking the tool with all parameters.
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?
The schema has no descriptions, and the description only mentions the dry_run default. It doesn't explain client_request_id, serving, serving_quantity, or how duplicate detection works. This fails to compensate for the 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 tool name and title clearly indicate adding a consumed item. The description adds specific behavioral details (preview, duplicate check, idempotent write, diary reread) that distinguish it from sibling tools like update_consumed_item or add_meal_batch, though it doesn't explicitly state the primary 'add' function.
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 guidance is provided on when to use this tool versus alternatives. It implies a single-item add with dry-run capability but doesn't mention batch tools or exclusions. It also doesn't describe prerequisites such as whether the product must already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the read-modify-write-verify cycle, which adds value beyond the annotations. However, it fails to mention the critical dry_run parameter, which defaults to true and may prevent the write from actually occurring. This makes the statement 'writes the new total' misleading in the default configuration. The description does not contradict annotations, but it omits a key behavioral trait.
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, concise sentence that captures the core operations without unnecessary detail. It is well-structured and front-loaded with the primary action.
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?
Given the tool's complexity (4 parameters, read-modify-write behavior, dry_run nuance), the description is incomplete. It does not explain the role of the dry_run flag, how the date parameter scopes the cumulative amount, or what the output contains (though an output schema exists). The default dry_run behavior is a significant omission that could lead an agent to invoke the tool incorrectly.
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?
The schema has 0% description coverage, so the description must compensate. It explicitly mentions amount_ml, but it does not explain date, client_request_id, or dry_run. In particular, the dry_run parameter's effect on whether the write occurs is essential and left entirely unexplained. The description provides minimal parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action: reads the current cumulative amount, adds amount_ml, writes the new total, and verifies it. This is a specific verb+resource description that distinguishes add_water_intake from the read-only sibling get_water_intake.
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 describing the read-modify-write process, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It is clear enough for basic usage but lacks explicit guidance.
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 readOnly, openWorld, idempotent, and non-destructive. The description adds value by listing the specific data categories returned (calories, macros, goals, water, steps, meal breakdown), but does not disclose behavior around the date parameter (e.g., default value or format). No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the action verb 'Returns', and includes the key content categories. No wasted words.
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 one optional parameter, simple annotations, and an output schema. The description lists return contents, which is helpful, but omits all information about the date parameter, making it incomplete for effective invocation. The complexity is low, so it doesn't need much more, but the parameter gap prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'date' is not described at all in the description. Schema coverage is 0%, and the description fails to clarify whether date is required, its format, or default behavior. This is a critical gap for a one-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns' and clearly identifies the resource as a daily summary with enumerated data types (calories, macros, goals, water, steps, meal breakdown). This distinguishes it from sibling tools like get_water_intake or get_weight, which focus on individual metrics.
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 does not explicitly state when to use this tool versus alternatives like get_diary or get_nutrition_trends, but the name and content imply it is for retrieving a day's aggregate summary. There is no mention of exclusions or alternative tools, so the guidance is only implied.
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 convey read-only, idempotent, and non-destructive behavior. The description adds that the result is cumulative and in milliliters, but does not clarify optional-date behavior or how missing data is handled. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or redundancy. It states the action, the resource, the unit, and the temporal scope efficiently.
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?
For a simple read-only tool, the description covers the core return value and unit, but gaps around date format, optionality, and no-data behavior make it only minimally complete. The presence of an output schema helps, but the description still leaves important invocation details unspecified.
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%, and the description only restates the parameter name with 'for a date.' It does not define the expected date format (e.g., YYYY-MM-DD) or mention that the schema makes `date` optional, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and identifies the exact resource ('cumulative water intake in milliliters') scoped to a date. It clearly distinguishes this from sibling tools like add_water_intake (write) and get_daily_summary (broader summary).
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 about when to use this tool versus alternatives such as get_daily_summary or add_water_intake. No exclusions, prerequisites, or comparison context are provided, so the agent gets no direction beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, non-destructive, and idempotent. The description goes beyond this by adding that the tool never creates entries and does not claim the user actually ate, which is important context for interpreting the results as probabilistic rather than definitive.
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 two brief, front-loaded sentences with no wasted words. It states the core function first, then adds a safety clarification.
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?
The output schema covers return values and annotations cover safety, but the description lacks context for a 4-parameter tool. It does not explain detection criteria, how to interpret 'suspiciously empty', or when to use this tool, making it incomplete for proper invocation.
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 has no descriptions (0% coverage), and the description does not mention any parameters. While start_date and end_date are self-explanatory, maximum_recorded_calories and meals are not explained, leaving the agent to infer the threshold and filtering behavior from the schema defaults and names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds suspiciously empty meal buckets, with a specific verb and resource. It also distinguishes itself from write tools by noting it never creates entries and from get_diary by focusing on missing meals rather than actual entries.
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 explicit guidance on when to use this tool versus alternatives. It implies its use for identifying missing meals but does not state when to prefer it over get_diary or get_daily_summary, nor does it explain cases where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool as read-only, idempotent, and safe. The description adds meaningful behavioral context beyond these hints: the default regional settings (US/en_US) and the normalization of nutrition data per 100 g/ml. This helps the agent anticipate the output format and the effect of locale/country overrides, which is not covered by the annotations.
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 concise and front-loaded with the core purpose. It consists of two efficient sentences, with no redundant words or repetition of schema details. Every sentence provides substantive information about default behavior and data normalization.
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 and strong annotations, the description is incomplete for a tool with 5 parameters. It does not explain how to use the 'query', 'limit', or 'sex' parameters, which are crucial for executing searches. The normalization and locale defaults are covered, but the overall usage context is under-specified, making it insufficient for an agent to understand all capabilities and constraints.
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 by explaining parameters. It clarifies the 'countries' and 'locales' parameters via 'country/locale overrides', but completely omits the purpose or usage of 'query', 'limit', and 'sex'. The description adds partial meaning but fails to cover the majority of the parameters, leaving the agent without essential information for constructing a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Searches') with a clear resource ('YAZIO products'), and adds important scope details (defaults to US/en_US, accepts overrides, normalized nutrition). This clearly differentiates it from sibling tools like get_product and get_nutrition_trends, which imply more targeted retrieval or analysis.
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 does not provide any explicit guidance on when to use this tool versus alternatives such as get_product. It implies a search use case but lacks clear context about prerequisites, exclusions, or when the overrides are necessary. No alternative tools are mentioned, leaving the agent to infer the appropriate usage scenario.
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 read-only, idempotent, and non-destructive behavior. The description adds that it returns both training and custom training entries but doesn't disclose any additional behavioral details such as whether date is required or how results are organized.
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, front-loaded sentence that clearly states the action and scope with no superfluous words.
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?
For a simple read tool with an output schema and comprehensive annotations, the description is mostly complete. However, it leaves ambiguity around the optional date parameter and the exact content of 'training' entries.
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?
The description mentions 'for a date' which gives meaning to the single parameter, but it doesn't specify format or clarify that the parameter is optional (required=0). It provides some compensation for the 0% schema coverage but lacks completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns training and custom training entries for a date, using a specific verb and resource. It distinguishes from sibling tools like get_diary and get_daily_summary which are broader in scope.
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 guidance is provided on when to use this tool versus alternatives such as get_diary or get_daily_summary. The only implied usage is that it filters by date, but there is no explicit context or exclusions.
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 the tool as read-only, open-world, idempotent, and non-destructive, so the description's main contribution is the input constraint of 'up to 366 days each' and the specific metric ('average calories and macros'). It does not disclose return format, date handling details, or any other behavioral traits, but the annotations lower the bar.
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, front-loaded sentence with no filler. Every word adds value: the action, the metrics, and the range limit. It is concise and well-structured.
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?
For a tool with 4 undocumented parameters and no usage guidance, the description could do more. It states what the tool does and the range limit, but omits any mention of the output structure (though an output schema exists), assumptions about date inclusivity, or guidance on when to use this tool. The annotations and output schema fill some gaps, but the description alone is not fully complete for decision-making.
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. It adds meaning by explaining that the four date parameters define two ranges and that each range is limited to 366 days. However, it does not explicitly describe each parameter (e.g., the relationship between start and end dates) or the expected date format, relying on the self-explanatory parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('compares'), resource ('average calories and macros'), and scope ('two ranges of up to 366 days each'). This differentiates it from siblings like get_nutrition_trends, which likely show trends rather than direct period-to-period comparisons.
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 the tool is for comparing two date ranges, but it provides no explicit guidance on when to choose it over alternatives (e.g., get_nutrition_trends, get_daily_summary). No when-not-to-use or alternative tool names are mentioned, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the safe replacement mechanism (create, verify, remove old ID), compensation on failure, and the unconfirmed PATCH endpoint. This goes beyond the annotations' destructiveHint, adding valuable behavioral context. However, it doesn't clarify the role of dry_run and confirmation_token in the verification process, so not a 5.
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?
Three short, focused sentences with the main action front-loaded. Every sentence adds meaningful information, and there is no redundant or filler content.
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 6 parameters and no schema descriptions, the description leaves the agent without enough details to correctly fill dry_run, confirmation_token, and client_request_id. It explains the high-level algorithm but not the invocation contract, making successful tool use uncertain.
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%, and the description provides almost no parameter-level meaning. It doesn't explain dry_run, confirmation_token, client_request_id, date, item_id, or amount (beyond the title). The 'creates and verifies a replacement' hints at confirmation_token but is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replaces an existing product entry, using the specific verb 'replaces' and naming the resource. This distinguishes it from sibling tools like add_consumed_item and remove_consumed_item, and the title reinforces it updates the amount.
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?
Usage is implied: it's for updating an existing entry by replacement. However, there is no explicit guidance on when to prefer this over add/remove, nor any exclusions or alternative tool mentions. The intended use case is understandable but not fully articulated.
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 description adds valuable non-obvious behavior: sequential processing, partial failure compensation, and per-item result reporting. However, it omits the critical dry_run default behavior (default true in schema), meaning by default no actual writes happen, which is a significant transparency gap not covered by annotations.
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 sentence that packs multiple crucial details (batch limit, sequential execution, compensation, result reporting) without any fluff, and the verb is front-loaded.
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 description covers the batch behavior and failure handling, but misses the dry_run default and idempotency context that are present in annotations and schema. Since an output schema exists, it does not need to explain return values, but the dry_run omission is a significant gap for a mutation tool.
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?
The description provides no information about parameters. With schema coverage at 0%, the agent must rely entirely on the JSON schema, but the schema lacks descriptive text for key fields like 'dry_run' and 'client_request_id', so the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adds'), the resource ('products'), and scope ('up to 25'), distinguishing this batch tool from the single-item sibling 'add_consumed_item'. The behavior is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: it is for batch-adding up to 25 meal items, with sequential execution and result reporting. However, it does not explicitly mention alternatives like 'add_consumed_item' for single items or when not to use this tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish safety (read-only, idempotent, non-destructive). The description adds useful detail about grouping behavior (day/ISO week/month) and computed metrics (averages, goals, stability, deviations), which enhances understanding beyond the structured hints.
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, well-structured sentence that front-loads the action and omits unnecessary detail. It is concise yet informative, covering the core functionality without verbosity.
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?
Given the tool's moderate complexity and the presence of an output schema, the description adequately covers the main behavior (aggregation and metrics). It could clarify terms like 'stability' or 'goals' but is otherwise complete for a read-only aggregation tool.
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?
With 0% schema description coverage, the description partially compensates by explaining the aggregation parameter (day/week/month) and clarifying 'ISO week'. However, it does not elaborate on start_date/end_date semantics beyond their names, leaving some ambiguity about date range behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Aggregates') and clearly identifies the resource ('daily summaries') with aggregation granularity and computed metrics. It effectively distinguishes this tool from siblings like get_daily_summary or get_diary.
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 for analyzing trends over a date range, but it does not explicitly state when to prefer this tool over alternatives like compare_periods or get_daily_summary. No clear exclusions or alternative guidance is 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 already disclose read-only, idempotent, and non-destructive behavior. The description adds the selection logic (latest on/before date), but does not disclose behavior when the date parameter is omitted or when no entry exists, leaving some ambiguity. This is acceptable given annotation coverage but not richly transparent.
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, front-loaded sentence that efficiently conveys the tool's purpose without wasted words. It is appropriately sized for the tool's simplicity.
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 a simple one-parameter tool, an output schema, and robust annotations, the description covers the core behavior. However, the optionality of the date parameter and lack of edge-case handling (missing entries) leave a small gap that prevents full completeness.
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?
With 0% schema description coverage, the description compensates by explaining that 'date' acts as a cutoff for selecting the latest entry. It adds meaning beyond the raw schema, though it omits the expected date format and optionality behavior, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Returns), the resource (weight entry), and the specific logic (latest on or before a date). This differentiates it from sibling tools like get_nutrition_trends or get_daily_summary, which handle broader or aggregated data.
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 for retrieving a single weight reading as of a date, but does not explicitly state when to prefer this over alternatives (e.g., get_nutrition_trends for trends) or provide exclusions. The agent must infer the appropriate context from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by disclosing that nutrients are normalized per 100 g/ml, which affects data interpretation. It does not discuss auth or rate limits, but the annotations cover the safety profile.
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 sentence with no filler. It front-loads the action and resource, and every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple read-only nature, strong annotations, and presence of an output schema, the description is complete enough. The normalization detail is a key addition that prevents misinterpretation of returned nutrient values.
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?
The only parameter, product_id, is already well-defined by the schema with type string and format uuid. The description's 'by UUID' reinforces the parameter's role but adds no extra semantic detail beyond what the rich schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Returns' and identifies the resource 'product' with the retrieval key 'UUID', clearly distinguishing it from search_products. It also adds the valuable detail that nutrients are normalized per 100 g/ml.
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 phrase 'by UUID' implies usage when a specific product identifier is known, but the description does not explicitly state when-not to use this tool or mention alternatives like search_products. The guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, which the description does not contradict. The description adds valuable behavioral detail: the aggregation is performed locally and is limited to 31 days. It does not cover error cases or response format, but this is mitigated by the presence of an output schema and annotations cover the safety profile.
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, tightly written sentence that packs in essential info: what it returns, single vs range, the 31-day cap, and a caveat about the API. There is no redundant wording, and the semicolon separates two related thoughts effectively without bloating the description.
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?
Given the low complexity of the tool and the presence of a detailed output schema, the description covers the core behavior (single date or range) and the local aggregation constraint. It does not explicitly state what happens if no parameters are supplied, but all params are optional, which could be ambiguous. Still, the description is largely complete for the typical use cases.
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?
The schema has no descriptions and 0% coverage, so the description carries the burden for parameter semantics. It clarifies that 'date' is for a single day and 'start_date'/'end_date' define a range, but it does not specify date formats, whether parameters are mutually exclusive, or behavior when no parameters are provided. This is a partial but insufficient compensation for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the diary for a specific date or a locally aggregated range up to 31 days. It uses a specific verb 'returns' and identifies the resource 'diary', effectively distinguishing it from sibling tools like get_daily_summary or get_nutrition_trends. The note about YAZIO lacking a confirmed range endpoint also clarifies the tool's unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use this tool to retrieve diary data for a single date or a range. It implies that for ranges, this tool is necessary due to the lack of a native endpoint. However, it does not explicitly mention when to use alternative tools, such as getting daily summaries separately, or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, read-only, idempotent operation. The description adds value by listing the specific goal categories returned, which is not present in annotations. It does not contradict any annotation.
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, front-loaded sentence with no unnecessary words. It efficiently states the tool's function and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, output schema present, rich annotations), the description is complete enough. It covers what the tool returns and the time scope, with no need for additional details.
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?
The description mentions 'for a date,' which indicates the purpose of the date parameter, but it does not specify the date format, whether it is optional, or what happens if omitted. With 0% schema coverage, the description only minimally compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns specific goal types (calorie, macro, water, step, weight) for a date, making its purpose unambiguous and distinct from sibling tools like get_daily_summary or get_water_intake.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is used to retrieve goals for a specific date, but it does not explicitly mention alternatives or exclusions. However, the context is clear enough for an agent to select this tool when goals are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context by specifying that the response excludes sensitive fields (email, birth date, tokens, payment identifiers), which is behavioral information not conveyed by annotations.
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, well-structured sentence that front-loads the action ('Returns') and immediately conveys the scope and exclusions. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool with an output schema and comprehensive annotations, the description is complete. It tells the agent exactly what the tool returns (minimal profile fields) and what it omits (sensitive data), and the schema handles any further field-level detail.
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?
Tool has zero parameters, so the description cannot add parameter-level meaning. Baseline 4 applies because there is nothing to document beyond the schema, which is empty and thus fully covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a minimal allowlist of YAZIO profile fields, with specific exclusions (email, birth date, tokens, payment identifiers). This provides a specific verb, resource, and scope, distinguishing it from sibling tools like get_goals or get_diary.
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 for fetching basic profile data but does not explicitly state when to use this over alternatives or mention any prerequisites. The 'minimal allowlist' hints at a subset, but without naming other profile-related tools, the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior, but the description adds crucial behavioral details: the requirement of MRTR confirmation, the dry-run fallback that issues a one-time confirmation_token, and the TTL. This significantly enriches understanding beyond the annotations.
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?
Two sentences, front-loaded with the core action ('Removes only the specified diary item ID') and then the fallback detail. Every word earns its place with no redundancy.
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?
The description covers the core removal action and the confirmation flow, which is sufficient given the output schema exists and annotations cover idempotency/destructiveness. However, the acronym 'MRTR' is unexplained, and the description does not mention any error or prerequisite conditions beyond confirmation, leaving some gaps for a complex deletion flow.
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 must compensate. It explains item_id ('the specified diary item ID') and dry_run/confirmation_token ('a dry run issues a one-time confirmation_token with a TTL'). However, date and client_request_id remain unexplained, leaving some parameters without added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Removes' with a specific resource ('the specified diary item ID'), distinguishing it from siblings that add or update consumed items. The phrase 'only the specified' reinforces its single-item scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for removing exactly one diary item (not batch operations) and requires MRTR confirmation, which gives usage context. However, it does not explicitly name alternative tools like update_consumed_item, though no other sibling directly removes items, so the intended use is fairly clear.
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:

[![yazio-mcp MCP server](https://glama.ai/mcp/servers/tomastaker/yazio-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tomastaker/yazio-mcp)

Score Badge

Copy to your README.md:

[![yazio-mcp MCP server](https://glama.ai/mcp/servers/tomastaker/yazio-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tomastaker/yazio-mcp)

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/tomastaker/yazio-mcp'

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