Cronometer MCP server

Server Quality Checklist

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

Latest release: v1.9.2
Disambiguation4/5
Tools are mostly separated by resource and action, with detailed descriptions that prevent most confusion. The main overlaps are get_food_log's nutrition_summary versus get_daily_nutrition, and get_targets versus get_macro_targets, but their descriptions are sufficiently distinct for an agent to choose correctly.
Naming Consistency4/5
Nearly all tools follow a snake_case verb_noun pattern using get, list, add, edit, update, remove, and create. Minor deviations include delete_fast versus the remove_* family, create_recipe versus add_*, and update_* versus edit_*, but the overall pattern remains predictable.
Tool Count2/5
At 40 tools, the surface exceeds the 25+ threshold and feels heavy even for a broad nutrition-tracking domain. Many tools are individually justified CRUD variants across multiple resource types, but the set would benefit from consolidation or clearer grouping.
Completeness4/5
The set covers diary food entries, custom foods, recipes, biometrics, exercise, fasting, notes, and targets with add/get/edit/remove operations nearly everywhere. Minor gaps include no macro target setter, notes cannot be deleted due to Cronometer limits, and exercise retrieval depends on get_food_log.
Average 4.4/5 across 40 of 40 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- Last stable release on August 27, 2026
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description's burden is lighter. It adds some behavioral detail—the amount is a corrected value in the entry's existing unit, and date defaults to today—but does not disclose side effects or authorization needs.
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 clear introductory sentence followed by a compact argument list with no filler. Every line adds information beyond the schema.
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 three-parameter update with annotations and an output schema, the description is mostly sufficient. It misses usage exclusions and includes a possibly incorrect source for biometric_id, leaving some ambiguity for the agent.
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 documenting all three parameters: ID source, unit-preserving amount, and date format/default. However, the claim that biometric_id comes from get_food_log is questionable given sibling tools like get_biometrics and list_biometrics, which could mislead an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear action and object ('Change the value of a recorded biometric'), making it obvious this is an update operation. It doesn't explicitly differentiate from siblings like edit_food_entry or remove_biometric, but the resource scope is clear.
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 explicit when-to-use or when-not-to-use guidance is provided. The wording implies the tool is for an existing biometric entry, but it never states that add_biometric or remove_biometric are the alternatives for other operations.
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 read-only, idempotent, open-world, and non-destructive nature, lowering the burden. The description adds a small behavioral cue about the return format being like the targets shown beside diary totals, but it does not disclose units, scope of nutrients, or how it differs from get_macro_targets.
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?
Single sentence, front-loaded with the resource and scope, and no filler. It communicates the core purpose efficiently without unnecessary detail.
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 parameterless read-only tool with an output schema, the description is mostly sufficient. However, given the sibling get_macro_targets, the description does not clarify how 'nutrient targets' differs from 'macro targets', so an agent may not reliably select between them based on this definition alone.
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?
The tool takes zero parameters, so the baseline is 4. The description reinforces the account-level scope, which is the only semantic needed for a parameterless retrieval.
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?
Description clearly identifies the resource ('nutrient targets'), scope ('for the account'), and a display context ('as shown beside the diary totals'), so an agent knows what it retrieves. However, it does not distinguish itself from the sibling get_macro_targets, which could be the same or a related resource.
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 given about when to use this tool instead of alternatives such as get_macro_targets or set_nutrient_target. The description implies retrieval of account-level targets but provides no exclusions, conditions, or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the ongoing-fast behavior by stating that omitting 'end' records an ongoing fast, which is useful context beyond the schema's null default. It does not contradict 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 compact and well-organized, leading with the action and following with a clear parameter list. Every sentence adds necessary information and there is no filler.
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 parameter formats and the key ongoing-fast nuance, and an output schema exists to describe return values. Minor gaps remain, such as timezone handling and behavior if an ongoing fast already exists, but it is adequate for a simple creation tool.
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 Args section fully compensates by explaining all three parameters: the date-time format for start/end, the omission semantics for an ongoing fast, and goal_hours as target length. This adds real meaning beyond the raw schema, though goal_hours remains somewhat terse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Record a fast,' which is a specific verb and resource. It clearly identifies this as creating/adding a fast entry, though it does not explicitly differentiate from siblings like edit_fast or delete_fast.
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 given about when to use this tool versus edit_fast, delete_fast, or get_fasting_history. The intended use is only implied by the phrase 'Record a fast,' with no explicit when-to-use or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description's 'Remove' aligns with that. It adds the useful context that the target is a 'recorded fast' and that the ID comes from get_fasting_history, but it does not disclose additional behavioral nuance such as irreversibility or side effects; the annotations cover the main safety signal.
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 extremely compact: one clear purpose sentence and a well-scoped Args line. There is no filler, and the key action is front-loaded.
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 one-parameter destructive tool with a strong annotation set and an output schema, the description is nearly complete. It tells the agent what is being deleted and where to get the ID; the main missing piece is explicit routing guidance relative to edit_fast or other mutation tools.
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?
Despite 0% schema description coverage, the description fully explains the single parameter: 'The fast ID, from get_fasting_history.' This adds meaningful provenance beyond the bare integer title in the schema, which is enough for a one-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Remove a recorded fast,' which is a specific verb plus a distinct resource, and clarifies that this acts on a historical fast rather than a generic fast. It is clear enough to separate from sibling remove_* tools, though it does not explicitly name an alternative such as edit_fast.
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 provides no guidance on when to use this tool versus related tools like edit_fast or add_fast. The only usage hint is that fast_id comes from get_fasting_history, which is about parameter sourcing, not about choosing this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the specific profile fields returned, which is useful context but does not disclose behavioral details like authentication requirements or whether it returns the current user's profile. 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?
One short, front-loaded sentence that lists exactly the relevant fields. Every word earns its place; there is no fluff or redundant phrasing.
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 parameterless read tool with rich annotations and an output schema, the description is largely complete. It could specify that this is the authenticated user's profile, but given the tool name and the output schema, the missing nuance is minor.
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?
The tool has zero parameters, and schema coverage is effectively 100%. The description adds semantic clarity by enumerating the fields included in the profile, which helps the agent understand what data it will receive. A baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource explicitly (the account profile) and lists its contents (birthdate, gender, timezone and language). It is not a tautology and is clearly distinguished from sibling tools like get_biometrics or get_macro_targets, though it lacks an explicit verb like 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no exclusions, and no mention of the context in which it is appropriate. The usage is only implied by the name and description; with many sibling tools, this is a minimal signal.
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. The description adds meaningful context: serving_type is fixed at creation, 'weight' and 'servings' have different logging and display behaviors, and include_retired controls inclusion of retired recipes. This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loads the core purpose. The serving_type explanation is slightly verbose but earns its place by clarifying an important response field; the Args line is crisp.
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 an output schema present, return values need not be described. The description covers the tool's purpose, the significant serving_type behavior, and the only parameter. It omits mention of pagination or ordering, which are typical for list tools, but this is not a critical gap.
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?
The schema provides no description for include_retired, so the description's Args block supplies the needed meaning: 'Keep retired recipes in the result when they appear.' This compensates for the 0% schema coverage, though it could more explicitly define 'retired' and clarify the default exclusion behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('every recipe you own') and the key included attribute (serving_type), making the tool's purpose evident. However, it lacks an explicit verb like 'List' and does not differentiate it from sibling tools such as list_custom_foods.
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 about when to choose this tool over alternatives, nor are any exclusions or prerequisites stated. The description only states what the result contains, not the conditions under which this tool is appropriate.
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 indicate a safe read-only, idempotent operation. The description adds meaningful behavioral detail beyond the annotations: it clarifies what qualifies as a day ('fully logged days'), what is returned ('current run' and 'record'), and how the optional date is interpreted ('count back from', 'defaults to today'). This is useful context that the annotations do not provide.
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 compact and front-loaded: the first sentence states the core output, and the second defines the parameter. There is no filler or redundant restatement of the schema.
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 a single optional parameter, an output schema, and strong annotations, the description covers the essential behavior and parameter semantics well. The main gap is that it does not specify timezone handling or the exact rule for what makes a day 'fully logged', but these are not critical for an agent to invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a generic 'Date' property with a null default and 0% description coverage. The description compensates well by specifying the YYYY-MM-DD format and explaining that the date is the point to count back from and defaults to today. This gives the single parameter meaningful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('diary logging streaks') and the two outputs ('current run of fully logged days, and the record'), which makes the tool's purpose immediately understandable. It lacks an explicit verb like 'returns' or 'gets', so it falls just short of a 5, but it is still precise and distinct from sibling tools.
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 that this tool should be used when the caller needs streak information for diary logging, but it does not explicitly state when to use it or when not to use it. No alternative tools for streaks exist among the siblings, so the lack of exclusions is not a major issue, but explicit guidance is still absent.
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?
The description reveals a critical behavioral trait not present in annotations: Cronometer cannot delete notes via the API, they can only be rewritten, and removal requires the Cronometer app. This provides meaningful context beyond readOnlyHint=false and destructiveHint=false, and it does not contradict 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 compact and well-organized: a one-line purpose, a single behavioral caveat, and a concise Args section. Every sentence earns its place without 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?
For a simple two-parameter tool, the description covers purpose, a key behavioral limitation, and parameter formatting. A minor gap is that it does not clarify whether adding a note to a day with an existing note appends or overwrites it, but the output schema covers return-value expectations.
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 must explain parameters. It covers both parameters and adds useful format and default details for date ('YYYY-MM-DD', defaults to today). However, 'text: The note text' is essentially a tautology that adds no real 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 opens with a specific action and resource: 'Add a note to a day in the Cronometer diary.' It unambiguously identifies the operation and distinguishes it from sibling tools like add_food_entry, add_fast, and edit_note.
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 usage is implied—use this to add a note to a diary day—but there is no explicit guidance on when to choose it over alternatives like edit_note, nor exclusions. The note about deletion limitations hints at consequences but does not direct tool selection.
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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds valuable behavior beyond annotations: returned fields (status, timestamps, duration) and default date behavior (30 days ago to today), which helps the agent understand what a call will produce.
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 compact and front-loaded: the core purpose appears first, then return contents, then parameter details. Every sentence contributes useful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two optional parameters, rich annotations, and an output schema present, the description covers the essential call context: what is fetched, the default range, and the date format. Minor details like timezone handling or status enumeration are not specified, but these are not critical given the output schema and the simple read-only nature of the tool.
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?
The input schema only shows nullable string parameters with null defaults and 0% description coverage. The description compensates by documenting start_date and end_date as YYYY-MM-DD with explicit defaults, giving the agent the format and semantics needed to invoke the tool correctly.
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 opens with a specific verb and resource: 'Get fasting history from Cronometer.' It then clarifies exactly what is returned—'fasts within the date range including status, timestamps, and duration'—which distinguishes it from related siblings like get_fasting_stats, add_fast, or delete_fast.
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 when a fasting history within a date range is needed, and the date-range context is clear. However, it does not explicitly mention alternatives or when not to use this tool, leaving the agent to infer the boundary against siblings like get_fasting_stats.
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 the mutation, idempotency, and non-destructive profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false). The description adds the date default and the positive-number constraint, but does not disclose failure behavior or side effects; this is acceptable given the annotation coverage.
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 clear purpose sentence followed by a compact, information-dense argument list. Every line earns its place and the main action is front-loaded.
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 edit tool with an output schema and annotation coverage, this is nearly complete. The one notable gap is that it does not state that at least one of minutes or calories_burned should be supplied, since both are optional in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description documents every parameter with meaning beyond the schema: exercise_id source, minutes unit, calories_burned positivity, and date format with default. This fully compensates for the bare input 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 states a specific action and resource: 'Change the duration or calorie burn of a logged exercise.' This clearly identifies an edit operation and distinguishes it from sibling tools like add_exercise and remove_exercise.
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 phrase 'logged exercise' gives clear context that this tool modifies an existing entry rather than creating or deleting one. It does not explicitly name alternatives or exclusions, but the intended usage is easily inferred from the sibling set.
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?
Beyond the annotations, the description reveals that the tool can close an open fast by setting an end value, and it clarifies that recorded fasts can be modified rather than just created/deleted. It does not contradict the idempotent/non-destructive hints, though it could have been clearer about whether omitted parameters leave existing values unchanged.
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 main behavior is front-loaded in the first sentence, followed by a compact Args list with no filler. Every sentence adds necessary information.
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 output schema exists and annotations cover safety hints, the description is mostly complete: it covers usage, all parameter formats, and special open-fast behavior. The only notable gap is that it does not state whether omitted optional fields are preserved or explicitly cleared, which would matter for an edit operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It explains every parameter: fast_id comes from get_fasting_history, start/end use a specific YYYY-MM-DD HH:MM format, and goal_hours is a target length in hours. This fully compensates for the sparse 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 uses the specific verb 'Change' with the resource 'a recorded fast', and the phrase 'including ending one that is still open' adds a distinctive behavior that separates it from sibling tools like add_fast and delete_fast. It is immediately clear what operation the tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (modifying an existing fast) and even notes the edge case of ending an open fast, and it tells the agent to source fast_id from get_fasting_history. However, it does not explicitly state when not to use it or name the alternatives (e.g., add_fast for creation, delete_fast for removal).
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 readOnly=false, destructive=false, and idempotent=true, so the description only needs to add behavioral context. It clarifies that the tool modifies an existing entry's amount or time, but does not describe what happens if the entry_id is not found or how unspecified fields are treated. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: action sentence, prerequisite sentence, then a clear Args list. Every sentence adds value and the most important information is front-loaded.
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 relatively simple edit tool with annotations and an output schema, the description covers the main usage flow and parameter formats. It could be slightly more explicit that at least one of grams/time should be supplied and that 'or' does not preclude changing both, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args block carries the full burden. It explains entry_id as 'the serving ID', grams as 'new amount in grams', time format as HH:MM or HH:MM:SS, and date format plus default. This gives the agent everything needed beyond the bare 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 opens with a specific verb and resource: 'Change the amount or time of an already logged food entry.' This clearly distinguishes the tool from siblings like add_food_entry and remove_food_entry, and makes the operation immediately understandable.
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 gives explicit procedural guidance: 'Use get_food_log to find entry IDs.' It clearly scopes the tool to already-logged entries, which implies it should not be used for adding or removing entries. It does not explicitly name alternative siblings, but the context is clear enough.
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, so the description does not need to restate safety. The description adds meaningful behavioral context by specifying that the tool returns computed aggregates rather than raw entry data, which is not captured 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 extremely concise: one clear purpose sentence followed by a line enumerating return values. It is front-loaded with the core action and adds no filler or redundant information.
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 zero-parameter, read-only aggregated stats tool with rich annotations and an output schema, the description covers the essential information. It clearly states what the tool does and what it returns, and there are no hidden inputs or side effects an agent would need to know about.
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?
The tool has zero parameters and schema description coverage is 100%, so there is no parameter semantics burden on the description. The baseline of 4 applies because with no parameters, nothing additional is needed.
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 that the tool retrieves 'aggregate fasting statistics' and enumerates the exact computed metrics returned: total fasting hours, longest fast, average fast duration, and completed fast count. This distinguishes it from the sibling get_fasting_history, which implies raw history rather than summary 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 word 'aggregate' and the list of summary metrics imply this tool is for overview statistics rather than detailed history, but the description does not explicitly mention when to prefer it over get_fasting_history or other fasting-related tools. No alternatives or exclusion criteria are named.
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 signal readOnlyHint, idempotentHint, and non-destructive behavior, so the description carries a lighter burden. It adds context about the full nutrient profile and measure_ids, but it does not describe further behavioral traits such as error cases or data availability. 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?
The description is compact, front-loaded with the primary purpose, and every sentence earns its place. The Args section adds provenance for the only parameter without excessive repetition.
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 single parameter, rich annotations, and presence of an output schema, the description is sufficiently complete. It also explains the important workflow relationship with search_foods and add_food_entry, which would otherwise be ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for food_id. It does so by specifying 'Food ID from search_foods results,' which gives the agent the essential source and provenance of the parameter beyond the bare integer type.
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 states a specific verb and resource: 'Get detailed food information including nutrition and serving sizes.' It adds the key deliverable, 'full nutrient profile and available measure_ids,' and implicitly distinguishes itself from search_foods by being the follow-up detail lookup.
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?
It gives explicit usage context: 'Use this after search_foods' and explains that the output is 'needed for add_food_entry.' This clearly positions the tool in a workflow, though it does not explicitly list when-not-to-use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the core mutation (marking a day complete or incomplete), which aligns with the annotations readOnlyHint=false and destructiveHint=false. It does not add richer behavioral context such as side effects on streaks or handling of non-existent days, but the annotations already provide idempotency and destructiveness safety, lowering the burden on the description.
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 crisp sentences followed by a structured Args block. The purpose is front-loaded, and there is no filler or redundant explanation. Every sentence earns its place.
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 two-parameter mutation, the description covers the operation and all parameter meanings. The output schema and annotations cover return values and safety characteristics. It stops short of a 5 by leaving edge-case behavior (e.g., what happens if the day does not exist) unmentioned, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types and a default, with zero parameter descriptions. The description's Args block compensates fully by specifying the exact date format 'YYYY-MM-DD' and the boolean mapping 'True to mark complete, False for incomplete'. This gives an agent everything needed to set each parameter correctly.
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 states a specific verb ('mark') and resource ('diary day') with the two possible states 'complete or incomplete'. It is clearly distinguishable from all sibling tools, which deal with foods, biometrics, exercises, and fasting rather than diary completion status.
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 context for when to use the tool: whenever a diary day's completion status needs to be set. It does not explicitly name alternatives or exclusions, but no sibling tool appears to overlap this functionality, so explicit routing is unnecessary.
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 explicitly states 'Additive -- does not remove existing entries on the destination date,' which adds meaningful behavioral context beyond the annotations. The annotations already indicate non-destructive behavior, but the description clarifies the exact merge semantics and what side effects will not occur.
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 compact and front-loaded with the primary purpose, followed by the key additive behavior and a concise parameter explanation. Every sentence conveys essential information without repetition or filler.
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 tool with one optional parameter, a clear source/destination model, an additive safety note, and an output schema, the description is complete. An agent has enough information to invoke the tool correctly without additional missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description fully documents the only parameter: date as YYYY-MM-DD with a default of today. It also clarifies that date is the destination date, which adds meaning beyond the raw schema definition.
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 'Copy' and the resource 'all diary entries from the previous day' to a specified destination date. This is a specific, unambiguous operation that distinguishes copy_day from the provided siblings, none of which describe copying diary entries.
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 intended use is implied by the core statement 'Copy all diary entries from the previous day to the given date.' However, the description does not explicitly discuss when to prefer this tool over alternatives or mention any exclusions, so usage guidance is only implicit rather than clearly framed.
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 read-only, idempotent, open-world, and non-destructive. The description adds meaningful behavioral context beyond that: it returns frequency counts and flags recipes to prevent logging a whole batch as one portion, which is a subtle behavioral hazard an agent should know.
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 compact and front-loaded: the first sentence states the core purpose, and the second provides actionable usage guidance with no wasted words. Every sentence earns its place.
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 zero parameters, a rich output schema, and strong annotations, the description covers the essential context for correct invocation. It could mention ordering or limits, but those are likely implied by 'recently' and are not critical for the agent to use the tool at a basic level.
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?
The input schema has zero parameters, so the baseline is 4. The description correctly focuses on output and usage rather than parameter details. Nothing more is needed here.
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 resource ('recently logged foods') and the specific data returned ('how often each was logged'). It also signals a distinct use case ('log my usual') that separates it from search-focused sibling tools like search_foods.
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 explicitly names a concrete workflow: 'find the food here, then add_food_entry' as the fastest route for 'log my usual'. It also cautions about recipes, helping avoid misuse. It does not formally list exclusions or compare to all sibling alternatives, but the primary usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already carry the key behavioral hints: destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds the target ('Cronometer diary') and the 'one or more' batch capability, but it does not disclose potential side effects, failure semantics, or irreversibility beyond what 'Remove' and the destructve annotation imply.
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 compact and front-loaded with the purpose, followed by a short prerequisite and an Args list. Every sentence contributes necessary information and there is no filler or unnecessary repetition.
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 two simple parameters, an output schema, and annotations covering destructive/idempotent behavior, the description is complete: it states what is removed, how to find valid IDs, and how to specify the date. No critical information needed to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by explaining both parameters: entry_ids is 'List of serving/entry IDs to remove,' and date is 'YYYY-MM-DD (defaults to today).' It adds format and default semantics that the input schema, which only declares 'string or null', does not provide.
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 opens with a specific action and resource: 'Remove one or more food entries from the Cronometer diary.' This clearly distinguishes it from sibling tools like edit_food_entry or add_food_entry by naming the removal operation and the target (diary entries).
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 gives explicit prerequisite guidance: 'Use get_food_log to find entry IDs,' which tells the agent how to obtain the required parameter. However, it does not explicitly state when not to use this tool or compare it to alternatives such as edit_food_entry, so it lacks full exclusion guidance.
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?
The description adds substantial behavioral detail beyond the annotations: enrichment is 'best-effort,' non-food entries carry their own name, per-entry nutrients differ from day-level nutrition_summary, and untracked nutrients should be reported as plain figures rather than over/under target. This greatly helps an agent interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well-organized with clear bullets and purposeful sections. It front-loads the core purpose and adds needed field semantics without obvious redundancy. A few phrases could be tightened, but every major point earns its place.
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 output schema exists, the description does not need to restate return types, but it adds critical interpretive context: how to present remaining_kcal, how to treat untracked nutrients, and the distinction between per-entry and aggregate nutrition. This makes the tool fully usable for correct agent behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully explains both parameters: date format is YYYY-MM-DD with a default of today, and include_untracked controls whether the summary is restricted to nutrients with targets. This goes well beyond the bare 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 opens with a specific verb and resource: 'Get all diary entries for a given date,' and clarifies it returns every food entry logged for the day. This cleanly distinguishes it from sibling tools like get_daily_nutrition or get_food_details, whose purpose is implied to be different.
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 context of use is clear: retrieve a day's food log and summarize the user's day. It also gives guidance to always report remaining_kcal and prefer it over deriving from burn fields. However, it does not explicitly say when to choose this tool over siblings like get_daily_nutrition or list_biometrics, leaving some selection guidance implicit.
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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context by explaining that the result includes the per-day template mapping and all saved templates with their values, which clarifies what 'macro targets' means.
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 sentences with no filler. The main purpose is front-loaded and the second sentence expands the meaning of 'weekly schedule and templates' without 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?
Given the zero-parameter schema, rich read-only annotations, and presence of an output schema, the description provides all essential context. It clearly states what the tool returns, making it complete enough for an agent to select and invoke correctly.
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?
There are zero parameters, so the input schema fully documents the calling contract. The description correctly implies no arguments are needed.
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 states a specific verb ('Get'), a clear resource ('current macro targets'), and the precise scope ('weekly schedule and templates'). It also distinguishes the tool from the ambiguous sibling 'get_targets' by naming the macro-specific contents returned.
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 indicates this is the tool to call when the agent needs the current weekly macro schedule or saved macro target templates. It does not explicitly name alternatives or exclusions, but with zero parameters and such specific return content, the usage context is obvious.
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 define the read-only, idempotent, non-destructive nature. The description adds valuable behavioral context by disclosing that it returns 'every metric type the account can record' and that results contain metric_id and unit_id fields, enabling a follow-up workflow with get_biometrics. 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?
Three concise, information-dense sentences. The main purpose is front-loaded, followed by a clarifying example list and a practical usage pointer. No redundant words or repetition of schema/annotation content.
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 parameterless list tool with rich annotations and an output schema, the description fully covers what the tool returns, gives concrete examples, and explains the subsequent step (get_biometrics). Nothing essential is missing.
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?
There are zero parameters, so the description is not required to explain parameter meaning. The baseline for zero-parameter tools is 4, and the description goes slightly beyond by indicating how to use the result fields (metric_id, unit_id), which adds semantic value even though not parameter-specific.
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 ('List') with a clear resource ('the biometric metrics tracked in Cronometer'). It explicitly clarifies that this returns metric types (Weight, Body Fat, etc.), not actual measurements, which distinguishes it from get_biometrics (which retrieves actual biometric data). The purpose is 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 description provides clear context that this is a metadata-listing tool and explicitly instructs the agent to 'Use the metric_id and a unit_id from the results with get_biometrics.' It implies when to use it as a precursor to get_biometrics, though it does not explicitly state cases where it should NOT be used (e.g., when actual biometric values 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 description adds useful behavioral context beyond the annotations: it reads from the account's own catalog and stays current as Cronometer adds nutrients. This informs the agent that results may change over time and are account-specific. Annotations already cover read-only, open-world, and idempotent behavior, so the added context is a meaningful bonus.
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 concise sentences with no wasted words. The core purpose is first, followed by useful context and a direct usage instruction. Every sentence earns its place.
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?
With no parameters, an output schema present, and annotations covering safety and idempotency, the description fully equips an agent to call the tool correctly and use its results. There are no meaningful gaps.
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?
The tool has zero parameters, so there is nothing for the description to clarify. This is an appropriate baseline score for a parameterless 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 clearly states what the tool does: it lists every nutrient that add_custom_food accepts, including unit and category. It differentiates itself from sibling tools like list_custom_foods by scoping the output to nutrients accepted by add_custom_food.
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?
It explicitly instructs the agent to use the returned keys for the add_custom_food nutrients dict, which establishes a clear use case. It does not explicitly mention when not to use it or name alternatives, but its purpose is distinct enough among siblings.
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 only indicate read/write and idempotency hints, so the description carries meaningful behavioral weight. It adds valuable details beyond the schema: grams are real grams including recipes, date and time defaults, case-insensitive diary_group values, and how an 'auto' diary_group responds to a passed time. This is substantial and consistent with 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 front-loaded with the core purpose, followed by a short prerequisite workflow, then a structured Args list. Every sentence adds information; there is no fluff or repetition of schema properties.
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?
With seven parameters and three required, the description covers all of them and their edge cases. The output schema exists, so return-value documentation is not the description's responsibility. The prerequisite lookup steps make the tool safely usable without additional investigation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter, including formats, defaults, allowed values, and provenance. For example, it defines date as YYYY-MM-DD, time as HH:MM[:SS], diary_group as a closed set, and translation_id as usually 0.
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 opens with a specific verb and resource: 'Add a food entry to the Cronometer diary.' This clearly distinguishes it from sibling tools like edit_food_entry, remove_food_entry, and add_custom_food by framing it as a diary-entry creation operation. The prerequisite workflow with search_foods and get_food_details further anchors the tool's specific 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 gives clear procedural context: users must first use search_foods to find food_id and measure_id, then get_food_details to confirm serving sizes and gram weights. It does not explicitly discuss alternatives or exclusions, but the workflow makes the intended usage unambiguous.
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?
The description discloses significant behavior beyond the annotations: Cronometer sums nutrients itself, serving type is locked after creation, 'weight' stores ingredients in notes, and updating replaces the entire ingredient list. These are exactly the non-obvious behaviors an agent needs to avoid incorrect calls.
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 long but deliberately structured: a front-loaded summary, then focused paragraphs on important tradeoffs, bullets for serving types, and a concise Args list. Every sentence carries meaningful guidance, and the length is justified by the tool's complexity.
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?
The definition covers prerequisites, alternatives, update semantics, serving-type constraints, and cooking-weight edge cases. With an output schema present, return values need no explanation, and no critical calling context appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section fully compensates by explaining each parameter, including the exact shape of ingredients and the meaning of cooked_grams, serving_type, and recipe_id. This is a complete parameter-semantics layer over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Create a recipe from ingredients, or update one by passing recipe_id') and differentiates from add_custom_food by noting it takes foods and amounts, not nutrient values. However, it never mentions the sibling tool update_recipe, so the update path overlaps with a sibling without any distinction.
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 gives explicit practical guidance: use search_foods first, use add_custom_food instead when providing nutrient values, and provide cooked_rams for baked or simmered dishes. It does not, however, explain when to use create_recipe vs the sibling update_recipe.
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 clearly discloses the core behavior of replacing existing note text and explains the date default behavior. Annotations already cover idempotency and non-destructiveness, so the description does not need to repeat those. It adds useful context beyond the schema without contradicting 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 a single clear operational sentence followed by a compact, well-structured argument list. Every sentence earns its place, and the main action is front-loaded, making the tool easy to scan and understand.
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 simple three-parameter edit tool, the description covers the operation, all parameter semantics, the source of the note ID, and the date format/default. An output schema exists, so return-value details are not needed. The definition is complete enough for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the full burden of parameter explanation. It explains where note_id comes from, what text represents, and the exact format and default for date. This fully compensates for the undocumented 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 states exactly what the tool does with a specific verb and resource: 'Replace the text of an existing diary note.' This clearly distinguishes it from sibling note/food editing tools and makes the operation 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 description gives clear context for when to use the tool: editing an existing note, with the note ID sourced from get_food_log. It does not explicitly name alternatives like add_note for new notes, but the phrase 'existing diary note' strongly implies the distinction, so it falls short of a fully explicit exclusions statement.
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 indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral detail beyond annotations, including the exact return format ('a list of {day, value} points') and default date ranges (start defaults to 30 days ago, end to today). This enhances the agent's understanding of what to expect without contradicting 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 well-structured and appropriately sized: it front-loads the purpose and return format, then provides a useful cross-reference to list_biometrics, followed by a concise parameter list. Every sentence carries meaningful information without 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?
Given the tool has an output schema and rich annotations (readOnly, openWorld, idempotent, non-destructive), the description covers all necessary aspects: purpose, return shape, parameter semantics, defaults, and a prerequisite reference. No critical information is missing for an agent to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter: metric_id is a numeric ID from list_biometrics, unit_id is a numeric unit ID with a clarifying example, and start_date/end_date have format specifications and defaults. This provides meaning far beyond the bare schema properties.
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 begins with a specific verb ('Get') and resource ('a biometric time series such as weight or body fat from Cronometer'), making the tool's purpose immediately clear. It further distinguishes itself from sibling tools like add_biometric, edit_biometric, and remove_biometric by describing a read operation that returns data.
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 explicitly tells the agent to 'Use list_biometrics to find metric_id and unit_id', which is a clear prerequisite and points to the correct sibling for obtaining required parameters. While it doesn't explicitly enumerate exclusions or alternative retrieval tools, the context is sufficient to understand when this tool is appropriate.
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 safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds useful behavioral context beyond annotations: results contain food IDs, measure_ids, and source information, and matching is by name/keyword. There is no contradiction between the description and 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?
Every sentence earns its place: purpose, return shape, downstream routing, then the parameter definition. The purpose is front-loaded in the first sentence, and the entire description is compact with zero fluff.
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 low-complexity, single-parameter, read-only search tool with an output schema and rich annotations, the description is complete. It covers what the tool does, what results contain, how to chain results into add_food_entry or get_food_details, and what the query parameter means. Minor details like pagination or result limits are not critical at this level of simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate — and it does. The Args block defines query as a 'Food name or keyword' and supplies concrete examples ('eggs', 'chicken breast'), adding real meaning that the bare string parameter in the schema completely lacks.
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 opening sentence, 'Search Cronometer's food database by name,' states a specific verb, resource, and scope in a single line. The follow-up about returning food IDs and source information, plus the routing to add_food_entry and get_food_details, distinguishes it from sibling listing and retrieval tools such as list_custom_foods and find_entries_by_food.
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 gives explicit downstream workflow guidance: use the returned food_id and measure_id with add_food_entry, or pass food_id to get_food_details for full nutrition info. It implies the public-database scope and separates this tool from detail-fetching tools, but it never explicitly states when not to use it (e.g., for custom foods, use list_custom_foods), leaving a small gap.
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?
Beyond the annotations, the description reveals important implementation behavior: Cronometer cannot search entries by food, so this tool reads the diary one day at a time and costs a request per day. It also discloses default date behavior. This is valuable context that annotations do not provide.
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 front-loaded with the core result, then gives a concrete use case, a cost warning, and parameter details. Every sentence adds useful information, and the structure is easy to scan with a clear Args section.
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 three-parameter read-only tool with an output schema present, the description covers the core behavior, meaningful use cases, performance implications, and parameter defaults. Nothing essential is missing for an agent to correctly select and invoke this tool.
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 fully compensates by documenting all three parameters: food_id, start_date, and end_date. It provides format (YYYY-MM-DD) and defaults for the date parameters, though food_id is described only minimally as 'the food to look for.'
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 first sentence clearly states the tool returns every diary entry that references a specified food, including dates and amounts. This is a specific resource (diary entries) with a specific filter (by food), which distinguishes it from sibling tools like search_foods or get_food_log.
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 gives an explicit use case: use before replacing or retiring a food so its entries can be moved. It also explains the cost model (one request per day) and warns to widen the date range deliberately. It does not explicitly state when not to use it or name an alternative tool, but the context is clear.
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 readOnly, idempotent, and non-destructive behavior. The description adds valuable context about the scoring source, target coverage, and the confidence level returned, which goes beyond the annotation hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for returns, usage, and arguments. It is somewhat wordy in the returns listing, but every part contributes useful context and the key information is front-loaded.
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 single-optional-parameter tool, the description covers purpose, output, usage boundaries, parameter format, and default behavior. With an output schema present and annotations providing safety hints, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by specifying the date format (YYYY-MM-DD) and its default behavior (defaults to today). This gives the agent everything needed to correctly supply the only parameter.
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 nutrition scores with per-nutrient consumed amounts and category grades. It also distinguishes itself from get_daily_nutrition by specifying this is Cronometer's own scoring focused on nutrients with targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('see how close each nutrient is to its target') and when to use get_daily_nutrition instead ('when you need everything that was actually eaten'). It also explains the target-only limitation, leaving no ambiguity about appropriate use.
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 destructiveHint=true, so the destructive nature is known. The description adds useful behavioral context by giving a concrete example (duplicate tracker sync) and by noting that the date parameter defaults to today. It does not further detail irreversibility, but the annotations cover the core safety signal.
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, well-structured, and front-loaded. It states the action first, then gives selection guidance, then documents parameters. Every sentence contributes useful information with no filler or 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 destructive delete tool with only two parameters and an output schema, this description is complete. It covers purpose, when to use it, how it differs from edit_exercise, parameter semantics, and date defaulting behavior. The annotations cover safety and idempotency, and the output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameters. It provides meaningful semantics for both: exercise_ids as a list of IDs from get_food_log, and date with format YYYY-MM-DD plus a default of today. The reference to get_food_log is slightly confusing since the tool is about exercise, but the parameters are still clearly explained.
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 opens with a specific verb and resource: 'Delete logged exercise entries.' It also clearly distinguishes itself from edit_exercise, which is for entries whose duration or burn is merely wrong. This makes the tool's purpose immediately clear and differentiated from its closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: for an entry that should not be there at all, such as a duplicate from a tracker sync. It also names the alternative, edit_exercise, and explains when that tool is the better choice. This is strong, actionable routing 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 declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true. The description complements this by explaining that only passed parameters change, other settings are preserved, and that setting visible toggles tracking. It also warns that overwriting a target should be preceded by a get_targets call because the change may need manual reversal. This adds meaningful behavioral context beyond the annotations, though it doesn't detail the output behavior; with a rich output schema present, that is acceptable.
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 well-structured and front-loaded. The first sentence states the core action, followed by short paragraphs explaining custom targets, partial-update behavior, and recovery guidance. Args are cleanly listed at the end. Every sentence earns its place, and the length is proportionate to the tool's complexity.
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 mutation tool with one required parameter, three optional parameters, and an open-world hint, the description covers the essential behavioral context: what changes, what doesn't, how to discover valid nutrient names, and how to avoid data loss. The presence of an output schema means return-value details need not be in the description. It is complete enough for an agent to call this tool correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It explains nutrient (with examples and list_nutrients reference), minimum/maximum (daily target and upper limit in the nutrient's own unit), and visible (tracking toggle). It also clarifies the semantics of omitting parameters: only what you pass changes. The only minor gap is the unit ambiguity for minimum/maximum, but it is addressed with "in that nutrient's own unit."
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 opens with a precise verb+object: "Set a nutrient's daily target, its upper limit, or whether it is tracked." It clearly identifies three distinct actions and names the resource (nutrient). This distinguishes it from siblings like get_targets (read) and list_nutrients (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool: to set custom targets, toggle tracking visibility, and how it interacts with defaults. It also routes the agent to get_targets for reading current values before overwriting, and notes that reverting to defaults is done in the app, not via this tool. This is clear when-to-use and when-not-to-use 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 cover readOnly, destructive, and idempotent hints. The description adds useful context beyond those: date defaults to today, unit_id must come from that metric's valid units, and the tool is for recording new readings rather than editing or removing. This enriches the annotation profile without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, well-structured, and front-loaded. The purpose appears in the first sentence, usage guidance follows immediately, and each parameter gets a single clear line. No filler or redundant schema repetition.
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?
With an output schema present and four parameters, the description covers everything needed to invoke the tool correctly: purpose, ID discovery, alternative actions, parameter sources, and date formatting. There are no significant gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It compensates completely: metric_id is sourced from list_biometrics, unit_id is scoped to that metric's units, amount is the measured value, and date includes format plus default behavior. This is exactly what an agent needs.
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 opens with a specific verb and resource: 'Record a biometric measurement, such as weight or body fat.' It clearly distinguishes this creation action from the related siblings by explicitly naming list_biometrics, edit_biometric, and remove_biometric for their respective roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use list_biometrics to find IDs, edit_biometric to correct a wrong value, and remove_biometric when a measurement never happened. This gives direct routing guidance and prevents misuse of add_biometric for corrections or deletions.
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?
Beyond the annotations, the description exposes critical behavioral nuances: omitted nutrients stay blank while 0 means none, unrecognized names error rather than being silently dropped, energy_kj converts to calories and salt_g to sodium, and passing both a convenience field and its underlying nutrient is invalid. This is exactly the kind of information an agent needs to avoid incorrect calls.
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?
Although the description is longer than average, every sentence conveys a distinct operational fact: units, defaults, conversion behavior, error behavior, and integration with add_food_entry. The content is front-loaded with the core action and nutrient semantics before the structured Args list, and there is no filler.
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 complexity — 94 possible nutrients, conversion rules, and a nested nutrients object — the description is fully sufficient for correct invocation. It explains defaults, allowed values, error semantics, and the follow-up logging step; the presence of an output schema also relieves it from documenting the return value in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden, and it succeeds. It explains the nutrients object with a concrete example, defines serving_grams as one serving weight, gives the two allowed label_type values, and clarifies the meaning of leaving a nutrient out versus passing 0.
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 opens with 'Create a custom food' — a specific verb plus resource — and immediately distinguishes this from the sibling logging tool add_food_entry by the explicit post-creation workflow. It clearly separates creation from updating or retiring, making the tool's role 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 description gives clear operational context: call list_nutrients for accepted names/units, and use the returned food_id with add_food_entry to log the food. It does not explicitly state when to prefer update_custom_food or retire_custom_food instead, but it clearly orients the agent within the broader workflow.
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 mark the operation as non-read-only, non-destructive, and idempotent, while the description adds useful context: date defaults to today, calories must be positive, and wrong entries can later be corrected or deleted. It does not elaborate on idempotency semantics, but it does not contradict 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 short and front-loaded: purpose, sibling routing, and parameter list are compactly presented with no filler. Every sentence contributes essential information.
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 low complexity, existing annotations, and presence of an output schema, the description is complete enough for an agent to call it correctly. It covers all parameter semantics, default behavior, and correction/deletion paths with no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0 percent, yet the description documents all four parameters with added meaning: name is what the exercise was called, minutes is duration in minutes, calories_burned is a positive number, and date is YYYY-MM-DD defaulting to today. This fully compensates for the absent schema descriptions.
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 opens with the specific action 'Log an exercise entry,' clearly naming the verb and resource. It also distinguishes itself from siblings by noting that wrong entries can be corrected with edit_exercise or removed with remove_exercise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states that this tool is for logging an exercise entry and explicitly routes corrections to edit_exercise and deletions to remove_exercise. This gives an agent clear when-to-use and when-not-to-use guidance against the most relevant alternatives.
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?
The description adds significant behavior beyond annotations: it explains that null means nothing contained a nutrient, distinguishes 'untracked' from 'not eaten', and clarifies that Cronometer's summary excludes untracked nutrients. This is exactly the kind of contextual behavior an agent needs to interpret results correctly.
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 detailed but well-organized with a clear opening sentence, bulleted response structure, and a dedicated Args section. Every section adds meaningful information, and the most important behavioral caveat about untracked nutrients is given prominent treatment.
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 tool with two optional parameters and an output schema, the description covers all essentials: defaults, parameter effects, response fields, edge-case semantics, and reporting guidance. There are no meaningful gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 carry the full semantic burden. It does: date is specified as YYYY-MM-DD with a default of today, and include_untracked is explained with concrete consequences for the response. This fully compensates for the empty schema descriptions.
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 first sentence states a specific verb and resource: 'Get daily nutrition totals for every nutrient eaten that day.' This clearly separates it from related tools like get_nutrition_scores and get_macro_targets by focusing on per-nutrient daily totals. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the include_untracked parameter and when the false setting matches Cronometer's own summary. It also advises when to suggest set_nutrient_target. However, it does not explicitly name sibling tools as alternatives or state 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description meaningfully discloses behavior beyond the annotations: include_retired cannot surface retired foods hidden by Cronometer's own listing and only affects rows already returned. This is a subtle, non-obvious behavioral trait an agent needs to avoid misuse.
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 front-loaded with the core purpose, followed by a concrete usage example and a caveat about retired foods. The Args section is cleanly separated. Every sentence adds useful information without 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?
With only two optional parameters, clear parameter semantics, and an existing output schema, the description covers all essential behavior for correct invocation. The retired-food caveat and audit-oriented guidance make it complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the Args section fully compensates by explaining query narrows by name, empty query lists everything, and include_retired only retains already-returned retired rows. This adds real semantics beyond the bare type/default declarations in 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 explains the tool lists 'every custom food and recipe you own' and differentiates it from database search results with 'no database results mixed in.' This is a specific verb+resource pairing that distinguishes it from search_foods and other library tools.
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?
It gives concrete usage guidance: leave the query empty for the full library and use this tool to audit custom foods, including a practical example with updating names afterward. It implies when not to use it (when you need database results), but doesn't explicitly name alternative tools.
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 mark this as destructive, non-read-only, and idempotent. The description adds useful semantic context beyond those flags: it clarifies that deletion is for invalid/cancelled measurements and that editing preserves the day's entry and history, implying deletion does not. It could be more explicit about permanence, but the destructive annotation covers the core risk.
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 compact and front-loaded with the core action and example, followed by decision guidance, then parameter details. Every sentence contributes useful information without repetition or filler.
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 two-parameter destructive tool with annotations and an output schema, the description is complete. It covers what is deleted, when to delete versus edit, where IDs come from, and date handling. No critical calling information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It documents both parameters: biometric_ids lists the IDs to remove and identifies their source ('from get_food_log'), and date specifies the format YYYY-MM-DD and the default behavior (defaults to today). This adds meaning well beyond the raw 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 begins with a specific verb and resource: 'Delete recorded biometrics'. It gives a concrete example ('a reading from a misbehaving scale') and explicitly contrasts itself with edit_biometric, which clearly distinguishes this tool from its closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when deletion is appropriate ('when the measurement never happened or is impossible') and when editing should be used instead ('a value that is merely wrong'). This provides clear decision-making guidance and names the alternative tool.
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?
With annotations already marking the operation as destructive and idempotent, the description adds meaningful behavioral detail: existing diary entries that use the food keep working, and the operation is reversible by passing retired=False. This explains exactly what is destroyed and what is preserved, going well beyond the annotation 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 tightly structured with the core action first, followed by lifecycle context, then an Args section. Every sentence contributes meaningful information and nothing is redundant or verbose. The format is easy for an agent to scan and extract call-relevant details.
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 two-parameter mutation tool with rich annotations and an output schema, the description is complete. It explains the operation, the no-delete behavior, the reversibility, and both parameters, so an agent has everything needed to invoke the tool correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully explain both parameters. It does: food_id is identified as the custom food's ID, and retired is explicitly described as 'True to retire, False to restore.' This fully compensates for the lack of schema-provided descriptions.
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 opens with a specific verb and resource: 'Retire a custom food so it stops being offered for new entries.' It further clarifies that this is Cronometer's removal mechanism and there is no delete, clearly distinguishing the tool from a hard-delete operation while making its purpose unmistakable.
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 context for when to use the tool: when a custom food should no longer be offered for new entries. It also explains the restoration path via retired=False, which gives the agent the full lifecycle context. It does not explicitly name sibling alternatives, but states 'there is no delete', which is sufficient exclusion guidance.
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?
The description goes well beyond annotations by explaining partial updates ('Only what you pass changes'), diary linkage, nutrient merging, and the dual behavior of measures (fix vs. add). These details align with the idempotentHint and destructiveHint annotations rather than contradicting them.
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 detailed but each part earns its place, especially given the 0% schema coverage. Behavioral guarantees are front-loaded, and the Args section is dense but structured without wasted words.
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 5-parameter mutation tool with no schema descriptions, the description covers the essential semantics: scoping, merge behavior, measure handling, and related lookup guidance. Since an output schema exists, omitting return-value details is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions at all, but the description fully documents all five parameters, including the ambiguous 'measures' array with optional fields and the add-vs-edit distinction. It also directs the agent to list_nutrients for accepted nutrient 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 opens with a specific verb and resource: 'Edit one of your custom foods in place, keeping its diary entries.' It clearly differentiates from sibling tools like add_custom_food, list_custom_foods, and retire_custom_food by emphasizing in-place editing and diary preservation.
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 gives concrete use cases: fixing typos or wrong nutrients without re-logging, and correcting or adding measures. It does not explicitly state when not to use it or name alternatives like retire_custom_food, but the context is clear enough for an agent to select it appropriately.
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?
Beyond the annotations, the description discloses crucial behavior: only passed fields change, serving type is fixed, passing ingredients replaces the entire list, and cooked_grams requires ingredients because nutrition is recomputed. This is substantial, actionable behavioral context that annotations alone do not provide.
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 front-loaded with the core purpose, then uses compact paragraphs for behavioral nuances and a clear Args list for parameters. Every sentence earns its place; there is no repetition of schema-only information or filler.
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 output schema exists and annotations are present, the description covers all required behavioral and parameter-level context: partial updates, ingredient replacement, serving-type immutability, and the cooked_grams dependency. Nothing an agent needs to call the tool correctly is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining all five parameters in the Args block. It adds meaning beyond the schema, including the nested ingredient object shape, the full-replacement semantics, and the cooked_grams constraint.
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 opens with a specific verb and resource: 'Edit one of your recipes in place, keeping its diary entries.' This clearly distinguishes the tool from create_recipe, delete/recreate workflows, and other food-related update tools by naming the resource and the preservation effect.
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 gives clear context for use: editing an existing recipe while preserving diary entries, as opposed to creating a new one. It also notes that cooked_grams applies only to weight-based recipes, but it does not explicitly name alternatives like create_recipe or update_custom_food or state when not to use them.
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:

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

Score Badge

Copy to your README.md:

[![cronometer-mcp MCP server](https://glama.ai/mcp/servers/rollecode/cronometer-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rollecode/cronometer-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/rollecode/cronometer-mcp'

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