Wellness Project MCP

Server Quality Checklist

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

Latest release: v1.2.2
Disambiguation2/5
Many tools serve near-identical read purposes: list_meals and show_meal_diary both answer "what did I eat today?", and list_wearable_data overlaps heavily with show_health_overview, show_recovery, and show_week_steps. While individual CRUD pairs are well-described, the sheer number of overlapping list/get/show variants makes misselection likely.
Naming Consistency4/5
Most tools follow clean snake_case verb_noun patterns (log_meal, update_injury, delete_cycle) and each domain has a consistent CRUD family. The main deviations are the three read verbs (list_/get_/show_), plus broad "manage_" tools and add_or_update_personal_context, but the overall convention is still readable and mostly predictable.
Tool Count1/5
73 tools is far beyond the 50+ extreme range for an MCP server. Although the wellness domain is broad, many show_* visualization tools and per-entity CRUD families duplicate each other and could be consolidated.
Completeness3/5
Core workflows are well covered: workouts, meals, labs, injuries, recovery, supplements, cycle, and goals all have create/read/update/delete or equivalent lifecycle tools. However, there are notable gaps: sleep/body metrics/wearable logs cannot be deleted, run entries cannot be updated, and personal_context explicitly has no delete capability.
Average 4.6/5 across 70 of 73 tools scored. Lowest: 4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 24 commits in the last 12 weeks
- Last stable release on September 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
View related servers

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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description conflicts with the annotation by declaring the operation idempotent while the annotation sets idempotentHint to false. This contradiction undermines transparency. Additionally, it does disclose side effects like suppressing workout-prompt nudges, but the contradiction is a major issue.
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 moderately long but well-structured with clear paragraphs and a bullet point for inference rules. There is minor repetition, but it remains concise and easy to parse.
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 description covers when to use, how to infer the date, the effect on workout nudges, idempotency, and the alternative cancellation tool. It provides all necessary context for the tool's functionality.
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 already documents the 'date' parameter with format and default, but the description adds crucial inference rules for parsing user references like 'today' and 'yesterday,' going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the verb 'Mark' and the resource 'date as an intentional rest day.' It also provides usage examples, making the action unambiguous.
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 explicitly specifies when to use the tool ('Use when the user says they took a rest day...') and directs users to the sibling tool 'cancel_rest_day' for removal, leaving no ambiguity about when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is highly transparent (additive step semantics, replacement behavior, no-op success), but it explicitly claims 'IDEMPOTENT' while the annotation idempotentHint is false. This is a direct annotation contradiction, so per rubric the score must be 1 despite the otherwise rich detail.
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 long but well structured, with front-loaded purpose and uppercase section headers (VITALS, STEPS, ALL OTHER FIELDS, INFER, IDEMPOTENT). Some enumeration of vitals duplicates the schema, creating mild redundancy, but the operational rules justify most of the length.
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 17-parameter tool with an output schema and 100% schema coverage, the description covers all critical behaviors: defaulting to today, step additive semantics, replacement scope, no-op idempotent success, and lab-result routing. Only minor gaps exist, such as explicit behavior for omitting all fields, but nothing required for correct invocation 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 100%, but the description adds substantial extra meaning: step_count is additive and requires explicit confirmation, vitals replace existing manual values, systolic requires diastolic to accompany, and glucose routing depends on source. These are the exact semantic constraints the schema does not fully capture.
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 a specific verb and resource: logging daily wearable/manual health metrics across many vitals. It explicitly distinguishes where lab glucose values belong (log_lab_results instead), which separates it from that sibling without opening schemas.
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?
Provides explicit when-to-use and when-not-to-use guidance: manual step_count only for device-missed steps, never for sync issues; lab-derived glucose belongs in log_lab_results; all other fields replace existing manual values. This is model-level 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 already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value beyond the annotations by disclosing the inline-chart rendering, the preference for the interactive MCP app, and the short text summary returned alongside the visual.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. The first front-loads the core function and content, and the second adds the usage preference and return format without 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?
For a simple optional-parameter, read-only visualization tool with an output schema, the description covers what is shown, how it is shown, and what accompanies it. The only real gap is not signaling that the range is configurable beyond the default 7d, but the schema fills that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the range parameter with enum values, default, and 100% coverage, so the baseline applies. The description adds no parameter-level detail and slightly frames the tool as fixed to 'past 7 days' even though range supports 30d, 90d, and 1y.
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 a specific resource ('past 7 days of workouts'), specific metrics ('heart points per day, days trained'), and the presentation format ('inline chart'), so the tool's job is clear. It does not explicitly distinguish itself from siblings such as show_workout or show_week_fit_score, so it stops short of full sibling differentiation.
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 a clear triggering context: when the user asks about this, prefer calling this tool and rendering the interactive MCP app over describing rows in text. It does not name alternative tools or give explicit when-not-to-use conditions, but the guidance is still actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is rich in behavioral detail, covering replace-vs-add semantics, hydration deletion, matching errors, and the historical silent-replace bug. However, it directly contradicts the idempotentHint=true annotation: add_recipe_name and add_food_items 'ADD' macros to the meal's current value, so retrying the same call would append the food again and produce a different result. This is an annotation contradiction.
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 long but well organized with labeled sections and front-loaded sibling differentiation. Some parameter details are restated from the schema, but the length is justified by the high complexity of three interacting modes and a 14-parameter surface.
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 14-parameter mutation tool with zero required parameters, this description is unusually complete: locating the meal, all three modes, mutual exclusions, ambiguity handling, hydration side effects, error behavior, and defaults are all covered. An output schema exists, so return-value documentation is unnecessary.
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 100%, and the description still adds substantial meaning: it explains the interaction between add_* and plain fields, the required-with-add_food_items rule, target_meal_type never being written while meal_type is, matching/error behavior, and hydration fluid semantics. This goes far beyond the schema and materially improves correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Update an existing meal', and immediately differentiates from log_meal by requiring the current message to explicitly change, correct, or add to an already logged meal. The boundary is unambiguous: a plain food statement is a new entry and should use log_meal.
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?
Gives explicit when-to-use guidance ('Use only when the current message explicitly changes, corrects, or adds to a meal already logged') and when not to ('A plain food statement... use log_meal'). It also routes within the tool across the three modes and instructs the agent to ask when add-vs-correct intent is ambiguous.
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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds transparency about the tool's behavior beyond that: it 'renders an interactive MCP app' and 'returns a short text summary alongside the visual view.' These are useful behavioral details that the annotations do not capture, and they do not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and efficiently front-loads the core purpose. The first sentence states what is shown and lists metrics; the second provides usage guidance and output format. Every clause contributes meaningful information—there is no fluff, redundancy, or excessive detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter with an enum, no nested objects), the description covers all essential context: what the tool displays, which metrics are included, when to use it, and what the output looks like (visual app plus text summary). It is complete enough for an agent to decide when and how to call it, though the actual output schema is not detailed in the description itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage: the only parameter 'range' has a description ('Time window. One of 7d, 30d, 90d, 1y. Default 90d.') and an enum. The tool description adds no additional parameter-specific information beyond what the schema already provides. Since the schema fully documents the parameter, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Show body composition over time with an interactive metric picker' and enumerates the specific metrics (weight, body fat, lean and muscle mass, hydration, visceral fat, BMI, waist, and related scale metrics). It uses a specific verb ('show') and identifies the resource ('body composition'), leaving no ambiguity about what the tool does.
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 explicit usage guidance: 'When the user asks about this, prefer calling this tool and rendering the interactive MCP app over describing the underlying rows in text.' This tells the agent when to invoke the tool and contrasts it with an alternative (text descriptions). It could be more explicit about other alternatives (e.g., raw data tools like list_body_metrics), but the condition and preference are 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that: the tool renders an interactive MCP app, provides a visual view, and returns a short text summary. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and metric list, followed by usage preference and output format. 'When the user asks about this' is slightly vague filler, but overall the text is compact and each sentence contributes useful 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?
With one optional parameter, full schema coverage, a rich output schema, and annotations covering safety and idempotency, the description fully enables correct invocation and selection. It covers choice rationale, rendering behavior, and output format; nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'range' parameter, including its enum values and default of 30d. The description adds no parameter-specific detail, but the schema already carries the full semantic load, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'Show a rich overview of wearable health signals' and enumerates the included signals (steps, Zone Minutes, resting heart rate, HRV, VO2max, stress). It distinguishes from sibling metrics tools by framing this as a broad overview for overall health-trend questions.
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?
Description explicitly says to prefer this tool for 'broad wearable or overall health-trend questions' and to render the interactive MCP app rather than describing rows in text. It does not name specific sibling alternatives or exclusion conditions, but the guidance is clear enough for an agent to choose correctly.
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, idempotent, and non-destructive behavior. The description adds genuine behavioral context by explaining that it renders an interactive MCP app and returns a short text summary alongside the visual view. This goes beyond what annotations provide and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The core action and format are front-loaded, and the second sentence adds a usage preference and return-value hint 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 tool with one optional parameter, an output schema, and safety annotations, the description is nearly complete. However, it says 'last 14 days' while the schema allows only 7d/30d/90d/1y with a default of 30d, creating a factual mismatch that could mislead an agent into expecting a 14-day window or setting an unsupported range value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'range' has documented enum values and a default. The description adds no parameter-specific detail, but since the schema carries the full semantic burden, the baseline 3 applies.
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 ('Show'), a resource ('running mileage'), a time scope ('last 14 days'), and a presentation format ('inline bar chart'). It also differentiates from sibling tools by saying this tool should be preferred over describing underlying rows in text, clearly distinguishing it from list_runs and similar 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?
The description gives an explicit usage cue: 'When the user asks about this, prefer calling this tool... over describing the underlying rows in text.' This provides clear context for when to choose this tool, though it does not name specific alternatives or state when not to use it (e.g., when a raw list is explicitly requested).
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; the description adds value beyond that by disclosing that the tool renders an interactive MCP app and 'returns a short text summary alongside the visual view.' This informs the agent how to present the invocation result, which annotations cannot convey.
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 sentences, each earning its place: core function and format, tool-selection guidance, and return behavior. The content is front-loaded with the primary purpose and contains no 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 single-optional-parameter tool with a fully documented schema, output schema, and safety annotations, the description covers what to invoke, when to prefer it, and what to expect back. Minor gaps are reconciling the '7 days' wording with the larger range windows and explicitly naming show_sleep_detail as the drill-down alternative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the range parameter is fully described with its enum values and default ('Default 7d'), so the schema carries the burden. The description adds no parameter detail and even centers on 'past 7 days' while the schema permits 30d/90d/1y; at full coverage this lands at the baseline 3.
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 — 'Show the user their past 7 days of sleep (hours per night and sleep score) as an inline chart' — naming both content and output format. It also differentiates from sibling list tools by preferring 'rendering the interactive MCP app over describing the underlying rows in text.'
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?
Gives clear selection context: 'When the user asks about this, prefer calling this tool... over describing the underlying rows in text,' which routes the agent away from the list_sleep pattern. It stops short of naming explicit alternatives or exclusions, such as when to send the user to show_sleep_detail for granular detail.
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 is consistent with the readOnly and idempotent annotations, and it adds useful context about rendering an interactive MCP app and returning a short text summary. It does not mention side effects, but none are implied and the annotations already cover safety.
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 sentences with no fluff: purpose, usage preference, and return format. The most important information is front-loaded and 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 the output schema exists and the parameter schema is fully documented, the description is mostly complete. It explains the visual and summary outputs, though it does not explicitly mention that the range parameter can extend beyond 7 days; the schema covers this, so the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description fully covers the parameter's enum values and default, so the baseline is met. The tool description adds no extra parameter guidance and even says 'past 7 days' while the range parameter supports 30d/90d/1y, which could be slightly misleading for non-default ranges.
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?
Clearly states the action ('show'), the data ('step counts vs daily goal'), the time scope ('past 7 days'), and the presentation format ('inline chart'). The purpose is immediately understandable and distinct from a plain text response.
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?
Explicitly says to prefer this tool over a text-only description when the user asks about this topic. It does not enumerate sibling tools, but it gives a clear condition and preferred behavior, so the guidance is useful though not exhaustive.
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 disclose destructiveHint=true and idempotentHint=true, so the description does not need to restate those. It adds useful framing with 'previously declared' and real user scenarios, but it does not reveal additional behavioral traits such as what happens when no rest day exists or whether the action is reversible.
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: it states the action first, then gives usage examples, then supplies a clear inference instruction. Every sentence earns its place, and the structured 'INFER — do not ask' line is easy for an agent to parse.
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?
This is a single-optional-parameter tool with an output schema present and annotations covering mutability, destructiveness, and idempotence. The description covers what the tool does, when to use it, and how to handle the parameter, so an agent has everything needed to invoke it 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?
Schema coverage is 100%, so the schema already documents the date parameter, its format, and default. The description adds meaningful semantic guidance beyond the schema by instructing the agent to infer the date from the user's reference rather than asking, which directly affects invocation behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Remove a previously declared rest day.' This clearly differentiates the tool from sibling tools like log_rest_day and list_rest_days, since it targets undoing a prior declaration rather than creating or listing one.
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 when-to-use guidance: when the user changes their mind or wants to undo a mistaken declaration. It does not explicitly name alternatives or state when not to use it, but the 'previously declared' qualifier and the examples make the intended context 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 convey read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by noting that it returns 'a short text summary alongside the visual view' and that it renders an interactive MCP app.
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 sentences, each earning its place: what the tool does, when to prefer it, and what it returns. The key purpose is front-loaded and there is no redundancy 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 single-optional-parameter read-only tool with a full output schema, the description is complete. It explains the visual rendering behavior, the summary return, and the intended use case, leaving no important gap for an agent deciding to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the only parameter (`date`) with type, format, optionality, and default behavior. The description adds no additional parameter-level meaning, so the baseline 3 applies.
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 ('Show'), a specific resource ('meals logged on a day'), and a distinctive format ('rich diary with daily calories and macros versus targets'). This clearly separates it from sibling tools like list_meals and log_meal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to prefer this tool for 'what-did-I-eat and daily food-log review questions' and instructs rendering the MCP app over describing rows in text. It establishes clear usage context, though it does not explicitly name sibling alternatives or state when not to use it.
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 tool as read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond that: it produces an interactive dual-line chart, offers range toggles, and returns a short text summary alongside the visual. This is sufficient for a low-risk read tool.
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 sentences each earn their place: the first states what the tool shows, the second gives routing guidance, and the third describes the returned output. Information is front-loaded 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?
With one optional parameter, a fully documented schema, rich annotations, and an output schema, the description is complete enough for an agent to select and invoke the tool correctly. It covers the visual output, interaction behavior, and high-level return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single optional range parameter with an enum and description, so the baseline is 3. The description adds the notion of a range toggle but omits the 7d option present in the schema enum, so it does not fully align with and adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: showing resting heart rate and HRV recovery trend over time. It also specifies the output form as an interactive dual-line chart with a range toggle, which clearly distinguishes it from sibling show_* tools and list_recovery_sessions.
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 says to prefer this tool when the user asks about recovery trends and to render the interactive MCP app rather than describing rows in text. It provides clear context and a preferred behavior, though it does not name a specific alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint, idempotentHint, and destructiveHint annotations are present and consistent with the description. The description adds value by disclosing that the tool returns a text summary alongside a visual view and that it renders an interactive MCP app, which are behavioral details not covered by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the first sentence stating the tool's purpose and the second sentence providing usage guidance and output details. Each sentence adds necessary information without redundancy or excessive length.
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 description fully explains what the tool does, what it returns (text summary and visual view), and when to use it. The default behavior (current Fit Score and past 7 days) is specified, and the output schema is implied. No critical context is missing for a read-only reporting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'range' is fully documented in the schema with an enum and description ('Time window'), achieving 100% coverage. The tool description does not add additional semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
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 'Show' and the resource 'Fit Score' with a specific composite (0-100) and its six components. It also distinguishes itself from similar tools by specifying the 7-day default and the preference for rendering an interactive view over text descriptions.
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 explicit user-intent guidance ('When the user asks about this, prefer calling this tool...') and explains the output format. It does not mention alternative tools for similar requests, but the instruction to prefer this over text descriptions gives sufficient context.
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, covering the safety profile. The description adds meaningful behavioral context: it renders an inline/interactive MCP visual and returns a short text summary alongside it, which is useful beyond what annotations 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?
Two concise sentences with no filler. The action, scope, output style, and usage preference are all front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, non-destructive tool with one optional parameter, a full input schema, an output schema, and clear annotations, the description is complete. It covers what is shown, in what form, and what the user receives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter 'range' is fully documented with an enum and default. The description does not add new parameter semantics beyond implying the default 7-day window, so it appropriately relies on 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 states a specific verb ('show'), a specific resource ('past 7 days of calories and macros vs targets'), and the output form ('inline chart'). The title 'This week in nutrition' reinforces the domain and distinguishes it from sibling show_week_* tools focused on fitness score, workouts, sleep, and steps.
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 guidance: when the user asks about this, prefer calling the tool and rendering the interactive MCP app rather than describing rows in text. It does not explicitly name alternative tools or exclusions, but the usage context is clear enough for an agent to select it appropriately 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 already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds value by disclosing that it renders an interactive MCP app and returns a short text summary alongside the visual view, which the schema alone would not convey.
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?
Three sentences with no filler, front-loading the tool's purpose. There is minor redundancy between 'Prefer this for...' and 'When the user asks about this, prefer calling this tool', but the description remains tight and scannable.
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 with an output schema and safety annotations, the description covers purpose, usage context, and output behavior. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single range parameter has an enum and a default in the schema. The description adds no new parameter meaning, so the baseline of 3 is appropriate.
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?
States a specific verb (Show) and resource (energy, mood, stress, soreness) with scope (recent context, wellbeing trend). It clearly distinguishes itself from list_wellbeing by emphasizing the visual/interactive wellbeing view rather than raw rows.
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 directs the agent to prefer this tool for 'how-I-have-been-feeling' and subjective recovery questions, and contrasts it with describing underlying rows in text. This gives clear when-to-use guidance and implicitly names the alternative.
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 (readOnly false, idempotent, non-destructive), the description discloses that only provided fields are updated and omitted fields remain unchanged, and that ambiguous date matches cause an error with candidate IDs. This gives the agent accurate expectations about partial updates and failure modes.
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 short paragraphs with no filler: the operation is stated first, then the selector rule. Every sentence carries necessary information for correct invocation.
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 description covers all non-obvious invocation logic (selector requirement, ambiguity handling, partial update behavior). With the output schema present and annotations covering safety/idempotence, nothing essential is missing for an agent to call this tool 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?
Although the schema already documents all 7 parameters at 100% coverage, the description adds the crucial constraint that exactly one of id/date is required and explains the resolution error behavior. It also clarifies partial update semantics that apply to the optional fields, which the schema alone does not state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and resource ('existing wellbeing entry'), making the operation unambiguous. The word 'existing' implies modification rather than creation, separating it from log_wellbeing, though it does not explicitly name 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit invocation conditions: exactly one of id or date is required, with a fallback rule for dates that match multiple entries. It does not explicitly contrast against create/delete alternatives, but the context for when to use this update tool 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 establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: it is a search over public content, returns specific fields, and prescribes how results should be linked inline. This is more than the annotations alone provide, though it does not cover edge cases like empty results or error behavior.
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: purpose first, usage constraint second, return format and link handling last. Every sentence adds useful information, with no redundancy 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?
This is a simple, optional-parameter read tool with a rich schema, output schema, and full annotations. The description covers when to use it, what it returns, and how to format links, so an agent has everything needed to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented with types and descriptions. The tool description adds no new parameter semantics beyond the general search framing, which matches the baseline for fully covered schemas.
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: searching the public Crew Blog at /blog for advisor-authored posts. It clearly identifies what the tool returns and the /blog/<slug> link format, making its purpose unambiguous and distinguishable from the many list/show siblings.
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 gives explicit when-to-use guidance: only when the user explicitly asks about the blog or what an advisor has written. It also provides a clear when-not-to-use instruction: don't volunteer posts in normal conversation. No sibling tool covers this same domain, so naming an alternative 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it clarifies date-range scoping, explains the relationship to update/delete operations, and instructs the agent to infer defaults rather than ask the user.
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 purpose. The sibling differentiation, usage condition, and default-inference instruction each earn their place without redundant filler. It is structured for quick scanning by an agent.
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 list tool with two optional parameters, full schema coverage, a safe read-only annotation profile, and an output schema, the description provides everything needed to invoke it correctly. It also covers the relevant edge case of ambiguous update/delete matches, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both start_date and end_date already documented including format and defaults. The description mostly repeats these defaults in the INFER block. It adds the 'do not ask' operational instruction, but that is not new parameter semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List the user's logged period records within a date range.' It also explicitly differentiates this tool from update_cycle and delete_cycle, so an agent can tell exactly what list_cycle is for relative to its siblings.
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 gives explicit when-to-use guidance: use it when the user asks about cycle history, or to get an id after an ambiguous update/delete match. It also explicitly says the tool is no longer required before update_cycle/delete_cycle because those resolve records by date, which prevents unnecessary calls.
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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful context by revealing the grouping behavior and explaining that canonical names support exercise tracking and NSI score calculation, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no filler: output definition, when to call it, and why it matters. The most actionable guidance is front-loaded, and 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?
For a zero-parameter read-only listing tool with an output schema present, the description is complete. It explains the return content, the grouping, the practical invocation timing, and the downstream benefit, leaving no obvious gap for an agent to call it 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?
The tool has zero parameters, so there is no parameter semantics burden on the description. The baseline is 4, and the description appropriately focuses on the return value and usage context rather than inventing parameter details.
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 ('Returns'), a precise resource ('all canonical exercise names from the exercise library'), and an organizing detail ('grouped by muscle group'). It clearly distinguishes this tool from sibling list_* tools by focusing on the canonical exercise library rather than logs, meals, or metrics.
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 says to call this before log_workout or update_workout to match user-described exercise names to canonical ones. This provides clear contextual guidance, though it does not explicitly discuss when not to use it or name alternatives as exclusions.
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 description only needs to add extra context. It adds meaningful behavioral details: maximum range of 31 days, defaulting to the last 7 days, and the Settings prerequisite. This goes beyond the annotations 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences cover purpose, usage trigger, prerequisite, range, and defaults with no filler. The most important scoping information is front-loaded in the first sentence.
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 read-only two-parameter list tool with an output schema, the description is complete: it states what is returned, when to use it, the prerequisite, the allowed range, and the default behavior. Nothing needed for correct invocation or selection 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?
Schema coverage is 100%, so the schema already describes both parameters and their defaults. The description adds value by stating the maximum range (31 days) and the default window (last 7 days), which helps an agent validate input without opening 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 uses a specific verb ('Review') with a clear resource ('hydration events and stored effective hydration totals'), and the hydration domain distinguishes it from the many list_* siblings. It states exactly what the tool returns without relying on the title.
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 says 'Use when the user explicitly asks about hydration history or fluid intake' and adds a prerequisite ('Hydration tracking must already be enabled in Settings'). It does not name an alternative tool, but no direct hydration-list sibling exists, so the guidance 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by stating the INFER rule: default start_date to 30 days ago and end_date to today without asking the user.
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: purpose first, then usage conditions, then inference rules. No filler or redundant phrasing; every sentence contributes.
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 read-only list tool with two optional, fully documented parameters, an output schema, and annotations covering safety, the description provides everything an agent needs: purpose, when to use, inference behavior, and range semantics. Nothing critical 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?
Schema description coverage is 100%, so the schema already documents both parameters and their defaults. The description adds meaningful guidance beyond the schema by instructing the agent to infer defaults rather than ask, which changes invocation behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('dates a user has marked as rest days within a range'), clearly distinguishing it from sibling tools like log_rest_day and cancel_rest_day. The accompanying examples reinforce the exact purpose.
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?
Explicitly says 'Use when the user asks about their rest pattern' and gives two concrete example queries. It doesn't name alternatives or state exclusions, but the context is clear enough for an agent to route to this tool correctly.
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 context beyond the annotations: one row per day, calling twice on the same date is an upsert, all fields except date are optional, and the tool converts units once before storage. These are critical runtime behaviors an agent needs to know and are not present in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but justified given 23 parameters and complex unit/derivation rules. It is logically sectioned, though not perfectly front-loaded: the purpose statement appears only after an initial dense unit-input paragraph.
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 high-complexity tool, the description covers purpose, usage, units, inference rules, upsert behavior, and exclusions like BMI. An output schema exists, so return-value details are not necessary. The minor input_distance_unit inaccuracy prevents a perfect score.
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 coverage is 100%, but the description greatly enhances parameter meaning by explaining unit-input conventions, derived-field formulas, percentage ranges, and the distinction between muscle mass and lean mass. It loses a point because it references input_distance_unit, which does not exist in this tool's schema, creating potential confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Log or update body composition metrics for a given date.' It names the exact resource and action, and differentiates itself from sibling read/list tools by explicitly describing when the user shares a body composition reading.
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 strong when-to-use guidance: weight, body fat percentage, or other composition readings from manual entry, smart scale apps, or photos. It also provides important when-not behavior, such as never asking for BMI. However, it does not explicitly name alternative tools like log_wearable or list_body_metrics for exclusions.
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 signal mutation (readOnlyHint=false). The description adds meaningful behavior beyond that: it documents inference defaults (date=today, taken=true), the requirement that exactly one selector be provided, and the error behavior when supplement_name matches multiple items. This is valuable context for invocation.
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. Purpose, usage condition, inference rules, and selector requirements are each given their own section with no redundant or filler content. Every sentence adds operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity, the 100% schema coverage, the presence of an output schema, and annotations covering mutation safety, the description is complete. It covers prerequisites, defaults, selector resolution, and failure behavior, so an agent can invoke it 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 coverage is 100%, so the baseline is 3. The description adds important semantics beyond the schema: the exact-one-required relationship between supplement_id and supplement_name, the inference rules, and the multiple-match error behavior. This compensates well for the schema's lack of required-parameter enforcement.
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: 'Mark a medication or supplement as taken or not taken for a specific date.' This clearly distinguishes it from sibling tools like list_supplements or manage_supplement, and the action 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?
It explicitly says when to use the tool: 'Use when the user says they took (or missed) a medication or supplement on a particular day.' It also notes the daily tracking mode prerequisite. It does not explicitly name alternatives or state when not to use it, but the guidance is clear enough for 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 cover read-only and destructive hints, so the bar for disclosure is lower. The description adds useful behavioral detail beyond that: start_date defaults to today, category is inferred from the name, strategy_name is a case-insensitive substring, and ambiguous matches produce an error with candidate IDs to retry with.
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 organized into clear sections: trigger cases, selector rules, and post-add follow-up. It stays front-loaded and every block earns its place, though the post-add paragraph is fairly verbose and could be trimmed without losing the required conversational loop.
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 12-parameter mutation tool with one required field in schema, this description covers the most likely failure points: how to resolve strategy names, what to infer, what defaults to use, how to handle errors, and what to do after a successful add. The output schema exists, so the description does not need to explain return values.
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?
Even though the schema has 100% parameter coverage, the description adds critical semantics the schema does not express: exactly one of id or strategy_name is required for update/end/delete, name is the only truly required field for add, and optional fields like duration_minutes and time_of_day should be confirmed after an add. This is highly actionable guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line uses a specific verb-resource pairing: 'Add, update, end, or delete a recovery/mindfulness strategy,' and covers the full set of actions. This distinguishes the tool from session-level siblings like log_recovery_session and list_recovery_strategies by making it clear this tool manages the strategy lifecycle.
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 concrete trigger cases: when the user describes a new practice, changes a schedule, stops a practice, or removes one. It also says to ASK only if the name is missing, but it does not explicitly name alternative siblings or state negative 'do not use this when' 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?
Describes that it renders an interactive MCP app and returns a short text summary, making the behavior transparent without contradicting the read-only and idempotent 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 uses two concise sentences that convey purpose, usage, and output without extra fluff 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?
Provides enough context for an agent to decide when to call the tool and what to expect in return (interactive chart and text summary), given the simple nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'range' is fully covered by the schema enum and description; the tool description mentions the range toggle but does not add meaning beyond the schema, so baseline 3 is appropriate.
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?
Clearly states the tool shows body weight and body-fat % trend over time as an interactive line chart with a 30/90-day/1-year range toggle, providing a specific and actionable purpose.
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 instructs to prefer this tool over text descriptions when the user asks about body weight trend, giving a clear when-to-use directive and mentioning the alternative interaction.
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, idempotentHint, and destructiveHint. The description adds useful behavioral context beyond the annotations, such as the effect of passing null for ended_on (clears the date and marks active) and the selector resolution behavior. 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 well-structured with a main statement, a 'Common uses' list, and a 'SELECTOR' paragraph. Each sentence adds value (use cases, selector rules, null handling) without redundancy or fluff. It is appropriately sized for the 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 tool has an output schema, so return values are documented elsewhere. The description covers the action, use cases, selector logic, and parameter behaviors, making it self-sufficient for an agent to decide when and how to call it. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description repeats the parameter explanations already present in the schema (e.g., id as alternative to date, date resolving only when a single match exists). It does not add new semantic details beyond what the schema already provides, so it stays at baseline.
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 'Update' and the resource 'period record', and it lists common use cases (correct dates, add/clear end date). It is easily distinguished from sibling tools like log_cycle, list_cycle, and delete_cycle by the explicit update action.
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 provides concrete examples of when to use the tool ('my period ended on the 9th not the 8th', 'I'm still on my period'), and it explains the selector rules (pass id or date, exactly one required, error if multiple matches). This gives clear guidance on when and how to invoke without needing to infer.
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?
Goes well beyond annotations by disclosing side effects: severity changes are automatically tracked in history, setting end_date auto-marks Resolved, and severity_date backfills history. Also explains that ambiguous selectors cause an error with candidate IDs. These behavioral details are not available in the minimal idempotent/destructive hints.
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 somewhat lengthy due to the selector explanation, but it is well-structured into three logical blocks (purpose/usage, side effects, selector rules) and includes a concrete example for substring matching. It is front-loaded with the core purpose, and every sentence adds necessary information 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?
The description covers essential operational details: default value for severity_date, auto-status behavior, selector ambiguity and error handling, and precedence of id over injury. While it does not describe the response shape, an output schema exists (context signal indicates has output schema: true), so that omission is acceptable. The description is sufficiently complete for a caller to use the tool 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?
The schema already covers each parameter (100% coverage), so the baseline is 3. The description adds meaningful semantic relationships not evident from individual field descriptions: end_date ↔ status, severity ↔ severity_date, and the selector precedence (date ignored when id is given). This raised the score from baseline.
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?
Clearly states the action and resource: 'Update an existing injury entry.' The description also explicitly lists use cases ('improving, worsening, resolved, or wants to change details'), which fully distinguishes it from siblings like log_injury, list_injuries, and delete_injury without needing to name them.
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?
Provides explicit when-to-use guidance ('Use when the user reports an injury is improving, worsening, resolved, or wants to change details') and explains parameter selection rules (e.g., 'Only send fields that need to change', selector ambiguity and error behavior). It does not explicitly name alternative tools, but the existing-entry phrasing and use-case list make the boundary 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 indicate readOnlyHint=false and destructiveHint=false, and the description aligns with a creating/writing operation. It additionally discloses behavioral details: the tool loads current goals itself, refuses to stack duplicate goals, reports what a standard target changed from, and supports acknowledged warnings. Minor gap: no explicit statement about persistence or side effects beyond creation, but annotations cover the general write nature.
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 organized into three focused paragraphs and avoids unnecessary filler. It is slightly repetitive with the 'See UNIT INPUTS' references and the phrase 'Required on create / Set at create, not editable later', but these repetitions serve clarity in a large parameter surface and do not harm usability.
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 large number of parameters (29) and the existence of an output schema, the description does not need to explain every field individually; the schema handles that. It does provide important contextual guidance on unit conversion, duplicate prevention, and when to omit list_goals. A small gap is that it references 'canonical Goals definitions' without embedding them, but this is acceptable given the schema already enumerates valid goal_type values.
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 100% and each parameter includes targeted descriptions referencing relevant goal types. The description also gives important cross-cutting semantics for unit fields (input_weight_unit/input_distance_unit) and clarifies required-on-create versus not-editable-later fields. This goes 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 clearly states the tool's purpose: 'Create a new Wellness Project goal or standard target' and specifies when to call it directly. It names the primary action (create) and the resource (goal), leaving no ambiguity about what the tool does.
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 provides explicit usage guidance: call directly when establishing a goal, no prerequisite schema discovery or list_goals call is needed. It also warns against calling list_goals first and explains the tool's built-in duplicate guard, which is actionable and relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint: true, idempotentHint: true, and destructiveHint: false, with no contradiction in the description. The description adds useful behavioral context beyond the annotations, such as that exercise_name 'resolves to canonical, or says so if never logged' and that 'Banded and unbanded PRs are shown side-by-side when both exist.' This extra detail about resolution and output formatting earns a score above the baseline of 3.
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 distinct sections (overview, USE FOR, NOT, INFER) and uses bullet-like lines for readability. However, some information is repeated (e.g., the opening paragraph already mentions all-time PR and recent performance, and the USE FOR section restates these examples). This slight redundancy keeps it from a perfect score, but it remains clear and reasonably concise.
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 description is thorough for the tool's complexity. It details the output contents (est. 1RM PR, exact set, date, weight, reps, RPE, banded vs unbanded, superset siblings, notes, rep-range bests, recent sessions, delta), explains the optional parameters' effects, and covers edge cases like 'never logged.' Given that no output schema is shown, this descriptive completeness is essential and well-executed.
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 100% (all three parameters are described). The description adds semantic nuance that improves parameter understanding: since_date 'narrows only the Recent block; the PR is always all-time,' recent_limit is 'default 10, capped at 50,' and exercise_name is 'free-text — the tool resolves to canonical.' This additional guidance justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Look up everything the user has done for ONE exercise: all-time PR plus recent performance, across many sessions.' It uses a specific verb ('look up'), a specific resource (exercise history), and a clear scope (one exercise). It also distinguishes the tool from siblings like get_workout and list_workouts by mentioning 'NOT for a full session' and 'or a date-window list regardless of 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?
The description explicitly lists use cases under 'USE FOR:' (PR lookups, recent-activity questions, trend questions) and non-use cases under 'NOT for' (full session, date-window list), naming the appropriate sibling tools (get_workout, list_workouts). It also provides operational guidance under 'INFER — do not ask:' for each parameter, making 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.
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 description does not need to restate safety. It adds valuable behavioral context beyond the schema: the default filter combines Active and Monitoring, the meaning of 'all' versus 'Resolved', and an explicit instruction to infer rather than ask.
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 a clear usage section and a compact INFER block. The only minor flaw is slight redundancy between the sentence 'Defaults to active and monitoring injuries' and the INFER line restating the same default, but the overall size is appropriate and 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 simple read-only list tool with one optional parameter, an existing output schema, and strong annotations, the description covers everything an agent needs: what it returns, when to use it, how to handle the status filter, and how it relates to sibling mutation tools. No important operational gap remains.
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 coverage is 100% and the schema already documents the status filter, so the baseline is 3. The description adds extra semantic value by specifying the default behavior, the exact meaning of each enum option, and an INFER directive that helps the agent invoke the tool without unnecessary clarification.
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 and resource ('List injuries from the injury log') and clearly distinguishes the tool's purpose from update_injury and delete_injury by explaining that those can resolve injuries without a prior lookup. It also enumerates concrete use cases: reviewing the log, answering history/rehab questions, and retrieving an id after ambiguous matches.
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 says when to use this tool (review, answer history/rehab questions, get an id after ambiguous matches) and when it is not required (before update_injury/delete_injury). It also gives direct guidance on the status filter values, making the decision boundary 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 it read-only and idempotent, lowering the bar. The description adds useful behavioral context beyond the annotations, such as timezone resolution for dates, the 31-day maximum range, and the recommendation to make multiple calls for longer periods. This enhances transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, with clear sections for usage, ranges, and inference rules. While it repeats some schema information, the added guidance on when to call and how to handle date ranges is valuable and not redundant. The organization makes it easy to parse.
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 description covers when to use the tool, what it returns (meals with fields), limitations (max range, multi-call strategy), and parameter handling. Given that an output schema exists, an agent has all necessary information to decide when and how to call this tool successfully.
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 covers 100% of parameters with detailed descriptions (format, optionality, meaning), establishing a baseline of 3. The main description adds extra semantic context, particularly the inference rules for date and end_date (e.g., "this week" maps to Monday through today), which helps agents interpret parameter values 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 clearly states the tool's function: 'List all meals logged for a date or date range, including each meal's ID, date, type, food description, and macros.' It also distinguishes itself from sibling tools by noting that update_meal and delete_meal can resolve meals without this tool, making the purpose and scope unambiguous.
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?
Explicit usage scenarios are provided: 'use it to answer "what did I eat today/this week/yesterday?", review what has been logged, or get an id after an ambiguous update_meal/delete_meal match.' It also gives practical guidance on date ranges and multi-call handling, and clarifies that it is not required before update/delete operations.
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 readOnly/idempotent/non-destructive behavior. The description builds on that by explaining the INFER behavior ('do not ask'), the default filter, and what fields are returned. This adds useful operational context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose first, use cases second, then a clearly marked INFER block with parameter guidance, and finally a one-line return convention. Every sentence carries 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 single-parameter, read-only list tool with annotations and an output schema, the description covers usage, filter semantics, inference behavior, and return fields. Nothing an agent needs to invoke it 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?
Although schema coverage is 100%, the description adds meaning not present in the schema: 'use 'all' for history; use 'historical' for ended strategies only.' This disambiguates the enum values and gives the agent a rule for inferring the parameter without asking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with a specific verb and resource: 'List the user's recovery and mindfulness strategies.' It also gives concrete use cases ('user asks about recovery practices, mindfulness routines, or you need strategy IDs before logging a session'), which distinguishes it from related siblings like manage_recovery_strategy or list_recovery_sessions.
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 states when to use the tool: when the user asks about recovery practices, mindfulness routines, or needs strategy IDs before logging a session. It does not explicitly name alternatives or say when not to use it, so it earns a 4 rather than a 5.
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 important behaviors beyond the read-only annotation: it explains how Zone Minutes are calculated, how calories burned may be estimated and labeled, and how TDEE is derived or why it might be missing. It also states the tool will infer defaults without asking, which is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and somewhat repetitive: the same list of metrics appears in both the opening sentence and the 'Use when' clause. While the extra paragraphs on Zone Minutes and calories are informative, they could be condensed, and the overall length makes it harder to scan quickly.
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 all necessary context: what data is returned, operational limits (31-day range), default handling, and special labeling for estimates. It does not describe the output schema, but that's not required for a list operation. It is complete but slightly over-explained.
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 already provides 100% coverage with clear descriptions and defaults for both parameters. The description reinforces the default behavior (INFER) but does not add new details beyond what the schema already states, though it does clarify the date format implicitly through 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 states the tool lists daily wearable data across multiple specific metrics (steps, HRV, calories, etc.), with a verb and resource. It distinguishes itself from sibling list tools like list_workouts and list_body_metrics by explicitly naming the wearable data categories.
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 includes a direct 'Use when' clause listing user queries (step count, heart rate, HRV trends, etc.) and provides operational guidance such as the 31-day maximum range and instruction to make multiple calls for longer periods. This leaves no ambiguity about when to invoke 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?
With only weak annotations (all hints false), the description carries the behavioral burden and delivers richly: it discloses that the tool converts units itself ('The tool converts once before storage, so this overrides any wording that asks you to do the arithmetic'), that logging 'writes the completed run and returns a card marker for in-app editing', and imposes anti-fabrication constraints ('Never invent sensor data or splits', 'do NOT call it easy merely because it was a run'). These go well beyond what readOnlyHint=false and idempotentHint=false convey. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long (~250 words) but earns its length given 19 parameters and two operational modes. It is well-organized with labeled sections (UNIT INPUTS, intent, RUN TYPE, DETAIL) and front-loads the most critical instruction (unit handling) before anything else. Minor deduction: some redundancy with schema descriptions — the run_type and splits/segments 'never invent' constraints appear both in the schema and the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 19 parameters, two intents, and five enums, the description covers the decision-critical ground: unit conversion policy, the log-vs-plan distinction with required fields, run-type classification guardrails, and data-fidelity constraints. An output schema exists, so return values need not be described. Minor gaps: no explicit guidance on ambiguous cases (e.g., a run that might be both a plan and a log) and some per-field sourcing rules are left to the schema — but nothing an agent needs to call it 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?
Though schema coverage is high (89%), the description adds critical cross-parameter semantics the schema only references: the UNIT INPUTS paragraph explains the pairing rule ('when they gave kg / km / cm set input_weight_unit / input_distance_unit / input_length_unit in that same object. Omit the companion when the number is already lb / mi / in'). It also adds intent-specific required fields for log (date, distance_mi, duration_sec) that the schema does not state, and clarifies run_type classification guardrails. This far exceeds the baseline 3 for high schema coverage.
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: 'Create an editable running card. Use for a completed run OR a future run plan.' It further distinguishes two intents — log (the run happened) vs plan (the run has NOT happened) — which sets it apart from nearby siblings like log_workout, log_wearable, and log_rest_day. An agent can clearly identify this as the run-specific card creator without opening the schema.
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 'when' guidance: use for a completed run OR a future run plan, with a hard rule that a future run must never go into completed history. It also clarifies defaults (log is default) and mode-specific required fields. However, it does not explicitly name alternatives or exclusions (e.g., 'use log_wearable for synced wearable data' or 'use update_workout to modify'), so routing between siblings is left partly to inference.
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 discloses important behavior: actions are inferred, 'end' sets end_date while 'delete' removes the record, and a non-unique supplement_name causes an error with candidate IDs. This gives a clear model of side effects and failure modes, and there is no contradiction with the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but deliberately structured: purpose, trigger conditions, inference rules, ask conditions, and selector behavior are each clearly separated, with the core verb and resource front-loaded. Every sentence earns its place given the tool's 18-parameter 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 complex mutation tool with conditional selector requirements, the description covers user-intent mapping, defaults, disambiguation, and error behavior. Since an output schema is present, return values do not need to be spelled out, and nothing essential for correct invocation 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?
The input schema already documents all 18 parameters at 100% coverage, but the description adds substantial value by specifying inference rules, defaults for start_date, end_date, category, and frequency, and the id/supplement_name selector contract. This is meaningfully more than what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, multi-operation statement—'Add, update, end, or delete a medication or supplement'—and clearly identifies the resource being managed. It then gives concrete user-intent triggers, making it easy to distinguish from read-only siblings like list_supplements or log_supplement_taken.
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 'Use when...' sentence provides explicit triggering context, and the INFER/ASK guidance tells the agent when to act autonomously versus when to seek clarification. It does not explicitly name sibling alternatives or state when not to use this tool, but the operational guidance is strong enough for correct 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 provide idempotentHint and destructiveHint. The description goes beyond by explaining error behavior (e.g., 'Errors with candidate IDs if more than one marker matches') and the subtlety that per-marker fields cannot be changed via a date-only selector. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than typical but every part is necessary to explain the complex selector logic and field restrictions. It is well-structured with a clear breakdown of selectors, making the length justified.
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 (12 parameters, 0 required, multiple selector modes), the description provides everything needed: selector rules, field constraints, error handling, and examples. The output schema is present, so return values don't need to be described. The description is fully self-contained for correct usage.
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 already has 100% description coverage. The description adds critical extra semantics on top, such as which fields are allowed only with id/date+marker, and how 'marker' and 'panel_name' narrow the selection. This goes well beyond the basic parameter 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?
States a specific verb ('Update') and resource ('lab result'), clearly distinguishing it from sibling tools like log_lab_results, list_lab_results, and delete_lab_result. The purpose is immediately clear.
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 says when to use it ('when the user wants to correct a result already logged'), and provides detailed selector logic (id vs date vs date+marker) with constraints on which fields are allowed per selector. This gives unambiguous guidance on how to invoke the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this destructive, but the description adds meaningful behavioral context: deletion is permanent, severity history is also removed, and ambiguous injury matches cause an error returning candidate IDs. This goes well beyond the structured hints and clearly sets expectations for side effects.
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: effect first, side effect second, then selector rules. Each sentence earns its place and no information is repeated from the schema or annotations. The use of an em-dash separator and explicit rule statements makes it easy to parse.
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 cover safety, the description supplies everything else needed: selection strategy, disambiguation behavior, requiredness despite no schema-required params, and destructive consequences. The tool is fully usable based on this description 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?
Schema coverage is 100%, so the baseline is met. The description adds value by explaining the mutual exclusivity between id and injury, the exact-one-required contract, the role of date as a narrowing filter, and the error behavior on ambiguous matches — all beyond the schema's individual property 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?
States a specific verb and resource: 'Permanently delete an injury entry.' The scope is precise, and naming the cascading removal of severity history distinguishes this from update_injury and log_injury. An agent can tell exactly what this tool does and what side effects come with it.
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?
Provides clear operational guidance: how to choose between id and injury, when to use date to narrow, and that exactly one selector is required. It does not explicitly discuss alternatives like update_injury for non-destructive changes, but the selector guidance is detailed enough for practical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive and idempotent, and the description adds meaningful behavior beyond that: it will error with candidate IDs when multiple runs match, distance matching is approximate within 0.25 mi, and unit conversion is handled internally so the agent must never convert values itself. This gives the agent important operational expectations not encoded elsewhere.
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 appropriately sized and every sentence contributes useful information, but the main purpose ('Delete a run') is not front-loaded; the tool starts with a unit-inputs caveat instead. The selector and ambiguity guidance are well organized afterward, so the structure is good but not maximally focused.
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 description covers all necessary invocation context: when to use it, confirmation behavior, how to choose between id and date, approximate matching, unit handling, and the error outcome when multiple runs match. An output schema exists, so not detailing return values is acceptable; nothing an agent needs to call this 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?
While schema coverage is 100%, the description adds critical semantic rules not present in the schema: exactly one of id or date is required, distance_mi is ignored when id is given, distance matching is approximate, and input_distance_unit only applies when the user supplied km. These constraints materially change how the parameters should be used and are essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens the second paragraph with 'Delete a run. Use when the user wants to remove a run entry,' which names a specific verb and resource and clearly distinguishes this tool from run-logging or run-listing siblings like log_run, list_runs, and show_runs. The title and name reinforce the action, and the description adds unambiguous purpose.
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 states when to use the tool ('when the user wants to remove a run entry') and instructs the agent to ask for confirmation if intent is ambiguous. It also provides selection guidance for resolving the target run, but it does not explicitly mention when-not-to-use or compare against sibling deletion tools, so it stops just short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds meaningful behavioral context beyond that: it explains that include_capabilities=true appends a 'full catalog' that is 'large', informing the agent of an output-size tradeoff. It also clarifies that write tools resolve current goals themselves, preventing unnecessary calls. Minor gaps remain (e.g., pagination or exact response shape), but the output schema exists to cover structure.
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 three sentences, each earning its place: the first states purpose and output, the second gives usage triggers, and the third covers negative usage and the parameter caveat. It is front-loaded with the core purpose and contains 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?
For a single-optional-parameter read-only tool with a full output schema and comprehensive annotations, the description covers everything an agent needs: when to use, what it returns, when to pass the parameter, and when not to use it. No critical context 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?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by tying include_capabilities to a specific user intent ('what kinds of goals Wellness Project supports') and explicitly warning that the appended catalog is 'large'. This helps the agent decide when to set the flag, which is more actionable than the schema's generic phrasing.
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 ('Analyze or show the user's current and past goals'), names the resource ('user's goals'), and enumerates the exact return categories: active/paused formal goals, completed/historical formal goals, and current standard targets. It also implicitly distinguishes itself from sibling write tools by noting it should not be used to fetch an ID for create_goal or update_goal.
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?
Explicit usage conditions are provided: use when the user asks about their goals or wants a review/analysis. The description also gives a clear when-not-to-use rule ('Do not call this tool merely to obtain an ID before create_goal or update_goal') and a precise condition for setting include_capabilities. This fully routes an agent to the correct tool and parameter choice.
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, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds useful behavioral context: it returns canonical library data, includes aliases for matching, and supports canonicalization. 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 sentences with no filler. The primary return value is front-loaded, the output fields are enumerated compactly, and the usage directive follows naturally. 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?
The tool has no parameters, has an output schema, and is fully annotated as read-only and idempotent. The description adds the only missing context: what the data represents, what fields are returned, and how it should be used in the logging workflow. Nothing essential is left out.
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 there is no parameter burden for the description to carry. The description instead clarifies the semantic meaning of the returned canonical marker set, which is more valuable here. Baseline 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns'), a specific resource ('LOINC-coded markers in the reference library'), and enumerates the returned fields. It clearly distinguishes itself from list_lab_results, which is about logged lab results rather than the reference marker library.
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 to call this BEFORE log_lab_results, gives the matching purpose, references the analogous list_exercises pattern, and explains why it matters ('prevents name drift and ensures trending works'). This is strong when-to-use guidance with a concrete alternative pattern.
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 covered. The description adds useful behavioral context beyond those annotations: the tool returns IDs, defaults start_date to 365 days ago, end_date to today, and clarifies that update/delete can resolve results independently. It does not describe every output detail, but an output schema exists, so this is not a major gap.
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 with the core purpose. Each subsequent sentence adds distinct value: sibling relationship, use cases, filtering, and inference defaults. There is no filler or repetition of schema fields, and the formatting makes the INFER instructions easy to parse.
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 (0 required parameters, 4 optional well-documented parameters, no nested objects, and an output schema), the description covers all important context. It explains when the tool is needed, when it is not needed, what IDs are for, and how defaults should be inferred. Nothing essential is missing for correct selection and invocation.
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 100%, with each parameter already documented with format, defaults, and optionality. The description adds value by instructing the agent to 'INFER — do not ask' the defaults and by explaining why start_date defaults to 365 days ago ('labs are infrequent'). This goes beyond the schema and gives practical guidance for parameter selection.
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: 'List lab/biomarker results within a date range, including each result's ID.' It clearly distinguishes itself from related siblings like list_lab_markers, update_lab_result, and delete_lab_result by focusing on historical review and ID retrieval. No ambiguity remains about what the tool does.
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 the tool: to review lab history, answer trend questions, or get an ID after ambiguous update/delete matches. It also explicitly says this tool is 'no longer required' before update_lab_result or delete_lab_result, giving clear exclusion criteria. The INFER defaults further guide autonomous invocation without asking the user.
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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by specifying that only 'active' memories are returned and by describing the type of content stored, which helps the agent set expectations 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it states the core action and resource first, gives illustrative examples, then provides usage context. Every sentence adds value and there is no redundancy beyond the harmless 'Read-only' confirmation.
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 read-only tool with an output schema and annotations covering safety, the description fully covers purpose, scope, content type, and when to invoke it. Nothing essential is missing for an agent to select and call this tool 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?
The tool has zero parameters and the schema is trivially complete at 100% coverage. With no parameters to document, the description's focus on the returned content and usage context is appropriate. The baseline for zero-parameter tools is 4, and the description earns it.
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 names a specific verb ('List'), a specific resource ('the user's active Personal Context memories'), and includes concrete examples. It clearly distinguishes this tool from the sibling add_or_update_personal_context and from other list tools by focusing on durable remembered preferences and circumstances.
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 explicitly states when to use: when the user asks what has been remembered about them, or before proposing a new memory to check for existing coverage. This gives clear practical guidance and implicitly routes the agent to add_or_update_personal_context when no existing memory covers the subject.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, destructiveHint, and idempotentHint, and the description does not contradict them. It adds meaningful behavioral context such as the 90-day maximum range, the need for sequential calls to cover longer periods, and the 'INFER — do not ask' directive, which helps the agent behave correctly. It does not explicitly mention output format or error behavior, but with an output schema present that is less critical.
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 lengthy but well-organized: it starts with the primary purpose, then contrasts with a sibling, and finally gives usage and inference rules. While it could be trimmed, the added detail on multi-call traversal and inference rules is necessary for correct usage, so the structure is appropriate.
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 (multiple optional parameters, inference rules, range limitations, and a sibling that is easily confused), the description covers all necessary context: it identifies when to use it, how to handle date ranges, how to distinguish from list_recovery_strategies, and how to handle long histories. No critical information is missing for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all four parameters, and the description enriches them further: it explains default values for start_date/end_date, that omitting category returns all categories, and the limit's default/maximum. This goes beyond the schema and gives the agent full understanding of each parameter's meaning and usage.
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 'List', the resource 'logged recovery sessions', and the scope 'within a date range, each with its ID'. It also explicitly contrasts with the sibling tool list_recovery_strategies to remove ambiguity, so an agent immediately knows what this tool does and how it differs.
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 provides explicit usage scenarios ('answer what recovery sessions have I logged', audit/spot-check, get an id after ambiguous match) and gives concrete inference rules for parameters (default date range, category omission). It also tells the agent when to make multiple calls for longer histories, making the usage guidance highly actionable.
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 context beyond the annotations: injuries are date ranges that stay open until end_date is set, many fields should be inferred rather than asked, and only body_part warrants a clarifying question. The annotations correctly indicate a write operation with readOnlyHint=false, so there is no contradiction.
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: purpose, trigger conditions, domain model, then a scannable INFER list. Every sentence earns its place, and there is no redundancy with the schema descriptions.
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 9-parameter create tool, the description covers when to call, what to infer, what to ask, and the date-range semantics. Since an output schema exists and schema coverage is 100%, no critical information is missing for an agent to invoke this tool 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?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful extra value with numeric severity anchors (minor twinge=2-3, moderate pain=5-6, severe/acute=8-9), an example for affected_movements, and a clear policy to ask only when body_part is unclear. This is above baseline but not maximal because the schema already carries much of the parameter information.
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: 'Log a new injury or aggravation.' It also lists concrete user signals like 'getting hurt, feeling pain, straining something' that trigger this tool. The word 'new' distinguishes it from sibling tools like update_injury and delete_injury.
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 says when to use the tool: when the user mentions getting hurt, feeling pain, straining, or describes an injury. It doesn't explicitly state when not to use it, such as 'if the injury already exists, use update_injury instead,' 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description surfaces behaviors not visible from annotations: repeated calls on the same date upsert rather than duplicate, entries are always tagged manual, and wearable-provider sources are reserved for auto-sync. It also discloses the proactive questioning behavior. These details match the write-oriented annotations and add real operational transparency.
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 organized into labeled sections, each earning its place: core purpose, proactive collection, inference rule, subset/upsert behavior, and manual tagging. There is no redundant or filler content, and critical scoping 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 9-parameter write tool with many optional fields, the description answers the key operational questions: when to call it, what to ask if data is missing, how to compute date, whether partial data is allowed, what happens on duplicate calls, and how entries are tagged. An output schema also exists, so the description does not need to explain 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 coverage is 100%, so the schema already defines each parameter. The description adds valuable semantics by clarifying that date refers to the wake date (night ending on that date), defaults to today, allows any subset of fields, and that a second call on the same date updates the existing row. This goes beyond the schema's per-field 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-resource pair, 'Log a sleep entry', and lists the exact data types accepted (duration, score, stage breakdown, bedtime, wake time) and the sources (Fitbit, Oura, Whoop, Apple Health, manual recall). It clearly distinguishes this write tool from read siblings like list_sleep and show_sleep_detail, and separates manual entry from wearable auto-sync behavior.
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?
'Use when the user shares sleep data...' gives an explicit triggering condition. Proactive data collection instructions specify what to ask when the user wants to log but has no numbers, and the 'INFER — do not ask' section prevents unnecessary clarification. It does not explicitly name sibling alternatives for when to use something else, but the manual-vs-auto-sync note provides a meaningful exclusion rule.
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 that writes happen immediately with no separate approval step, that free accounts are capped at 3 memories and Pro at 50, that updates by id are allowed even at the cap, and that there is no delete/bulk capability. This meaningfully extends what the annotations alone communicate.
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 typical, but each paragraph earns its place: purpose, do-not-duplicate workflow, exclusions for structured health data, and write/cap behavior. The core action is front-loaded before broader guardrails.
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 a 3-parameter tool with full schema coverage, an output schema, and meaningful annotations, the description closes the important gaps: when to update vs add, what content belongs, what caps apply, and why duplicate structured records should be avoided. No critical dimension appears 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?
The schema already covers all three parameters at 100%, but the description adds real semantics: it clarifies that content must be a compact durable fact/preference, illustrates valid content with examples, and explains the relationship between memory_id and operation update in the list-first workflow.
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 new Personal Context memory, or update an existing one by id.' It also distinguishes itself from nearby tools in the sibling list by explaining that memories are durable circumstances/preferences and that structured health data belongs in other dedicated tools.
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 gives explicit, actionable guidance: use list_personal_context first, pass the existing id with operation update instead of duplicating, and avoid storing metrics/trackable health data here because dedicated tools exist for those. This is strong when-versus-alternative 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 declare destructiveHint=true and idempotentHint=true, so the destructive nature is covered. The description adds valuable behavioral detail: exactly one of id or date is required, date resolution matches only the period start date or any date within it, and an ambiguous match causes an error that returns candidate IDs to retry with. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by usage constraints and selector details. Every sentence earns its place, with no filler or repetition of schema 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 2-parameter destructive tool with annotations and an output schema, the description is complete. It covers what the tool does, when to use it, when not to use it, how to select the target, and how ambiguity is handled. 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 100%, so the schema already documents both parameters. However, the description adds important semantics: 'Exactly one required' clarifies the optional-looking schema, and it explains how date resolves and what happens on ambiguous matches. This meaningfully aids correct invocation beyond the schema alone.
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: delete a period record. It explicitly distinguishes itself from update_cycle, telling the agent it must not use this tool to 'fix' a record. This makes it easy to tell apart from the sibling update_cycle tool.
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?
Provides explicit when-to-use guidance: only when the user explicitly asks to remove a specific record. It also gives a clear exclusion and alternative: do not delete to fix a record; use update_cycle instead. The selector instructions further clarify how to invoke it correctly.
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 the annotations by disclosing that date-scoped deletes are irreversible, can remove many rows at once, and require user confirmation. It also includes the strong guardrail 'Never guess a selector.' These behaviors are not inferable from readOnlyHint=false or destructiveHint=true alone, so the description adds substantial value.
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 with a bolded selector heading and bullet-like separators. Every sentence serves a purpose: defining the action, stating when to use it, warning about irreversibility, and explaining parameter combinations. The length is appropriate for the destructive and ambiguous nature of the operation.
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 destructive nature and four optional parameters with complex interactions, the description fully covers what an agent needs: when to use it, how to choose selectors, what is irreversible, and when to confirm with the user. The output schema exists, so return-value documentation is not required. No critical context 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?
Although schema coverage is 100%, the description enriches the parameters by explaining the selector hierarchy: id deletes one row, date deletes the whole draw, and date+marker resolves to one row with error behavior if multiple markers match. It also clarifies that panel_name narrows date-based selectors and that marker is ignored when id is present—none of which the schema alone conveys as clearly.
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 'Permanently delete one or more lab results,' which is a specific verb and resource. It also clarifies the exact use case ('when the user explicitly asks to remove or delete a logged lab result') and distinguishes itself from siblings by focusing on deletion rather than update or logging.
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 states when to use the tool and provides detailed selection guidelines among id, date, and date+marker. It does not explicitly name alternatives like update_lab_result for non-destructive corrections, but the context is clear enough that an agent should not confuse this with other lab-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's job is behavioral context beyond safety — and it delivers: the guide is 'intentionally limited to stable, customer-facing help,' navigation must be grounded only in explicitly named paths ('Do not infer, invent, or autocomplete nearby navigation'), and pricing must be reproduced verbatim with an exact CTA block appended in the in-app coach. These operational constraints shape how the agent should consume the result and cannot be inferred from annotations or schema.
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?
Front-loaded with purpose in the first sentence, then flows from usage scope to exclusions to navigation grounding to operational pricing rules to examples — a logical structure. It is long, but every section carries operational weight; the only drag is the dense single-sentence exclusion list, which could be broken up for easier parsing.
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 1-parameter lookup tool with an output schema present, the description covers everything needed for correct invocation: purpose, scope boundaries, grounding constraints, exact pricing reproduction behavior, and worked examples. Combined with annotations covering the read-only/idempotent profile, nothing material 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?
Schema description coverage is 100%, so each of the 12 enum values is already thoroughly documented, giving a baseline of 3. The description adds genuine value above that via natural-language example mappings ('where do I see my PRs?' -> pages_training) and by clarifying that cost/Free/Pro/Founding Member/3-analysis questions route to topic=pricing — a routing detail not present in the schema enum description.
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?
States a specific verb and resource: 'Look up general customer help for the Wellness Project app.' Then narrows scope to 'broad questions about where a feature lives, how to use it, what a visible feature does, common troubleshooting steps, or pricing,' which clearly distinguishes it from the data-centric sibling tools like log_meal, update_workout, and get_exercise_history.
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?
Gives explicit scoping with 'Use this only for...' followed by a precise list of question types, plus negative guidance listing what must not be added or inferred (implementation details, policy, privacy claims, billing mechanics, etc.). It also provides concrete example-to-topic mappings and detailed conditional rules for the pricing topic, telling the agent exactly which message to reproduce and when.
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 covered by structured data. The description adds useful behavioral context: default filtering behavior, how to request history, and the full list of returned fields. This goes beyond annotations 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by concise parameter inference guidance and a clear list of return fields. Every sentence adds value, and the use of labeled sections ('INFER — do not ask') makes it easy for an agent to parse. Nothing feels redundant or wasted.
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 read-only list tool with two optional enum parameters and an output schema, the description is complete. It covers when to use the tool, what each parameter means, how to handle ambiguous matches, and what fields are returned. There is no missing information an agent would need to invoke this 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?
Although the input schema covers both parameters 100%, the description adds significant extra meaning. It defines the inference rules, explains the default 'active' filter, clarifies when to use 'all' vs 'historical', and specifies that omitting category returns both types. This is exactly the kind of parameter guidance that helps an agent choose values correctly without asking the user.
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: 'List the user's medications and supplements.' It clearly distinguishes itself from the sibling manage_supplement by explaining that list_supplements is for reviewing what the user takes, not for managing individual items. This lets an agent immediately know what the tool does and how it differs from related tools.
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 the tool: when the user asks what medications/supplements they're taking, asks to review their stack, or needs an id after an ambiguous manage_supplement match. It also explains that manage_supplement can resolve items on its own, so list_supplements is not a required prerequisite. 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses meaningful behavior: it can reopen a period that was marked ended, it infers started_on and ended_on instead of asking, and it requires a consent/tracking check before logging. No statement contradicts the provided 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 with a clear top-line definition, a bulleted list of cases, a prerequisite warning, and an inference section. Every sentence carries information an agent needs; nothing is filler or redundant.
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 description covers edge cases, prerequisites, inference rules, and forbidden usage. An output schema exists, so the description does not need to explain return values. For a tool that logs cycle data with inference and consent requirements, this is complete.
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?
While the schema already documents both parameters at 100% coverage, the description adds crucial semantics: started_on defaults to today for current-period statements, ended_on should be omitted unless explicitly stated, and both dates can be inferred from context. This goes well beyond the schema's basic format 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, 'Log a period to the user's cycle log', and then enumerates the distinct real-world utterances it handles. This makes the tool's scope unmistakable and clearly separates it from siblings like list_cycle, update_cycle, and delete_cycle.
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 applicability through concrete examples, a prerequisite check for cycle tracking, and an explicit exclusion: 'Do NOT use this tool to log future dates.' It does not explicitly route users to update_cycle for modifications, but for a logging action the guidance is strong and actionable.
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?
Even though annotations mark this as readOnly=false, the description adds substantial behavioral context: the required list_lab_markers workflow, the infer-not-ask policy for date/panel_name/flag/reference ranges/lab_name, and the requirement to submit all markers from one visit in a single call. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely informative and well organized with clear sections (glucose routing, workflow, inference policy). It front-loads the purpose and gives the most critical routing distinction early. Minor redundancy exists between the workflow section and schema field descriptions, but 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?
For a lab-logging tool with nested result items and several inferable fields, this description is complete: it covers when to use it, how to prepare parameters, how to disambiguate from related tools, what to infer, and how to batch submissions. The output schema exists, so return-value details do not need to be repeated.
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 coverage is 100%, so the schema already documents each field well. The description adds extra parameter-level guidance: use canonical marker_name and loinc_code for matches, omit loinc_code when no match exists, infer defaults for several fields, and batch all markers from a visit into one results array.
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?
States a specific verb and resource: "Log one or more blood test or biomarker results." It also distinguishes from log_wearable by explicitly routing glucose measurements to that sibling, so an agent can tell them apart.
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 says when to use this tool (lab/blood-draw results from a PDF, paper report, or photo) and when not to use it (finger-stick, CGM, home meter, wearable glucose belongs in log_wearable). It also defines a required workflow with list_lab_markers and tells the agent what to do if results are mentioned but not shared.
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, it details real behavior: infer date/category/strategy_name instead of asking, omit duration_minutes for skipped sessions, include quality only when the user rates it, and map 'skipped/missed/didn't do' to skipped=true. These rules tell the agent exactly how the tool expects the call to be constructed.
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 organized into a two-sentence purpose, a compact INFER bullet list, and a short workflow callout. There is no filler, and the highest-value guidance 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 an 8-parameter write operation, it covers all major decision points: defaults, inference rules, skipped handling, strategy linking, and the standalone fallback. Optional fields like notes are already documented in the schema, and an output schema exists, so the description does not need to explain return values.
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 already 100%, but the description adds inference semantics that the schema cannot express: category comes from the practice name, strategy_name comes from the linked strategy or user phrasing, and duration is omitted when skipped. This materially improves an agent's ability to fill the parameters 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 concrete action and resource: 'Log a completed or skipped recovery/mindfulness session,' and lists representative practices. It also carves out 'one-off standalone sessions not linked to a recurring strategy,' which separates this tool from strategy-management siblings and gives the agent a clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The trigger is explicit ('Use when the user says they did or skipped...') and the preferred workflow names list_recovery_strategies and a standalone fallback, so the agent knows when to invoke it. It never states a when-not or names a sibling tool as the alternative, leaving some exclusion logic implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it discloses the overlap conflict behavior: returns a warning with conflicting entry IDs and requires the user to update or delete existing entries first. It also explains date-range inference defaults and rating estimation. This adds meaningful behavioral context not present in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then organized into support scope, conflict handling, and inference bullets. Every section adds operational value, with 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with all optional fields and an output schema, it covers when to use it, how to derive period and ratings, and what happens on conflicts. The output schema handles return-value details, so 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?
Although schema coverage is 100%, the description adds substantive meaning: natural-language inference rules for period_start and period_end ('this week' = Monday–Sunday, 'this month' = first–last day) and example rating mappings ('exhausted'=2, 'great energy'=8). It also clarifies that any subset of rating fields may be logged, which is operationally useful.
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: 'Log subjective wellbeing ratings for a day, week, month, or custom date range.' It names the rating dimensions (energy, mood, stress, soreness), which clearly distinguishes it from sibling log_* tools such as log_sleep, log_body_metrics, and log_workout.
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 states when to use: 'Use when the user describes how they feel — energy level, mood, stress, or muscle soreness.' It also defines date-inference behavior and overlap handling, but it does not explicitly name alternative tools or give when-not-to-use exclusions.
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 and idempotent behavior. The description adds that it returns a short text summary alongside the visual view, which is useful behavioral detail beyond the annotations, though it does not cover error cases or side effects (which are already implied safe by annotations).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and information-dense: it states the output, default behavior, targeting capability, and a usage preference, all in two sentences without redundant wording.
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 single-parameter read-only tool with an output schema, the description provides sufficient context: what the user sees, how to target a date, and the relationship to the interactive app. 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?
The single 'date' parameter is fully described in both schema and tool description, including format (YYYY-MM-DD), optionality, and default behavior. Schema coverage is 100%, and the description adds meaningful usage context 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?
Clearly states action ('Show'), resource ('single logged workout session's exercises and sets'), and format ('inline card'), distinguishing it from list tools and get_workout by emphasizing the visual/interactive rendering.
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 instructs to prefer this tool over text descriptions when the user asks about a workout, and contrasts it with alternative presentation methods. The optional date parameter and default behavior are also specified.
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 important behavioral details: delete removes the goal, end follows the Goals UI cancel lifecycle, standard-target end/pause turns the target off, and ambiguous goal_ref returns candidates without making changes. This complements the destructiveHint annotation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into clear paragraphs: unit handling, tool usage, and action behavior. It is somewhat long, but each section serves a distinct purpose and avoids 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 the tool's complexity and 31 parameters, the description provides sufficient context for invocation, including lifecycle semantics and ambiguous-reference handling. An output schema exists, so return-value details are not required.
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 already covers 100% of parameters with descriptions, so the baseline is 3. The description adds meaningful guidance beyond the schema, such as 'For edit, pass only the fields to change' and the unit-input rule for _lb/_mi fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: change, complete, pause, end, reopen, or delete an existing goal. It distinguishes this from related tools by explicitly saying to call update_goal directly instead of list_goals first.
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 provides explicit when-to-use guidance, including 'Call this tool directly for ordinary goal changes' and 'do NOT call list_goals first just to find an ID.' It also explains edit vs. lifecycle actions and ambiguous goal_ref behavior.
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 (readOnly=false, idempotent=true, destructive=false), the description reveals selector resolution behavior: exactly one of id or session_date is needed, session_category can narrow the match, and ambiguity errors with candidate IDs for retry. This is valuable behavioral context an agent would otherwise infer only from failures.
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 tightly scoped paragraphs: the first gives the use case and patch style, the second the selector contract. It is front-loaded with the actionable verb and includes an example list without bloat. Every sentence contributes.
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 an 11-parameter update tool with an output schema available, the description covers the purpose, patch semantics, selector requirements, disambiguation, and error behavior. The only small omission is an explicit 'do not pass both id and session_date' rule, but the 'or' selector language makes that sufficiently clear.
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 the schema already documents all 11 parameters (100% coverage), the description adds critical relational semantics: the exact-one-of id/session_date selector rule, optional narrowing by session_category, that session_category is ignored when id is supplied, and the patch-style 'omit unchanged fields' convention. These relationships are absent from the individual parameter 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 action and object: 'Update one or more fields on an existing recovery session log entry.' It distinguishes from related siblings like log_recovery_session and delete_recovery_session by emphasizing 'existing' and 'already logged,' and lists concrete fields (duration, quality, category, notes) that make the scope 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?
It explicitly states when to use the tool: when the user wants to correct or change something already logged, and it gives updating guidance ('Only send the fields that need to change'). It does not name alternatives such as log_recovery_session for new entries, but the 'existing'/'already logged' framing and examples supply clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and idempotent behavior, and the description goes far beyond them by disclosing a non-obvious accuracy quirk: a wrong or missing equipment tag on a dumbbell exercise 'silently halves or doubles its NSI score.' It also explains when equipment is shown per exercise vs per set and what 'missing' means, which is highly useful behavioral detail not present in 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 long but densely informative, with clear section headers (NSI, EQUIPMENT, REQUIRED WORKFLOW, SAVED WORKOUTS) that make scanning easy. Every sentence adds operational knowledge; there is no filler or repetition of schema definitions.
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?
Despite having an output schema, the tool has complex behavior (nested NSI scoring at session/exercise/set grains, equipment-tag sensitivity, two distinct input modes). The description covers all of these, plus the required lookup workflow and a correctness caveat. Together with the annotations and schema, an agent has everything needed to invoke the tool correctly and interpret its unusual scoring behavior.
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 100%, so the baseline is 3. The description adds value beyond the schema: it explains that session_id comes from list_workouts and is required, clarifies saved_workout_id returns a 'reusable prescription instead of a completed workout session,' and warns against combining saved_workout_id with session_id/session_date. These semantic clarifications exceed the schema's basic field 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: 'Retrieve full detail of a workout session' and enumerates the exact contents (exercises, sets, reps, weights, superset groupings, heart points, notes, NSI scoring). It clearly differentiates from siblings like list_workouts (list vs full detail) and show_workout (which may focus on summary/display), and also explains the separate saved_workout_id mode.
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: 'Use for detailed questions about a past workout, reviewing training before recommendations, confirming what was logged, or comparing a session to population strength standards.' It also mandates the preceding workflow step ('call list_workouts first to find the session ID — never guess it') and gives a clear exclusion/alternative for saved workouts ('Do not combine it with session_id/session_date').
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 readOnlyHint and idempotentHint annotations, the description reveals important runtime behaviors: default date range, 90-day maximum range, the need to chain calls for older periods, and the effect of the saved_workouts flag. This adds meaningful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly long but well-organized with labeled sections (SAVED WORKOUTS, INFER) and each sentence adds value. It front-loads the core function and usage examples before diving into edge cases, though a bit of trimming could improve conciseness.
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 three optional parameters and the tool's role in a broad ecosystem, the description covers all necessary aspects: default dates, range limitations, chaining strategy, saved workout mode, and the output fields. Users have enough context to call it correctly without referencing external docs.
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 descriptions cover all three parameters, but the tool description enriches them further by specifying defaults (start_date = 7 days ago, end_date = today), the meaning of saved_workouts, and instructions to widen the range up to 90 days. This goes well beyond the schema's basic 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 clearly states the tool's function: listing workout sessions with specific attributes (ID, date, focus, location, NSI rating). It also gives concrete usage examples and distinguishes between completed workouts and saved workouts, making its purpose unambiguous.
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 provides explicit guidance on when to use it: before get_workout to find a session ID, for answering trend questions, and how to handle older data via chaining. It also clarifies the saved_workouts flag to switch modes, which helps select the right tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false and no other safety hints, so the description carries the behavioral burden. It fully discloses important behaviors: never overwriting known stored macros with fresh estimates, requiring confirmation before force=true, handling duplicate errors by prompting the user, and letting the server decide whether hydration tracking is enabled.
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 long, but its complexity warrants it: 11 parameters, macro resolution rules, duplicate handling, and hydration all need explanation. It is well-organized with clear section headers and fronts the core purpose before diving into edge cases, though a more compact phrasing would slightly improve conciseness.
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, the description is remarkably complete. It covers inference rules, macro sourcing, required fields, fasting, duplicates, and hydration, leaving no major decision ambiguous. An output schema exists, so the absence of explicit return-value details is not a 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?
Despite 100% schema coverage, the description adds substantial meaning beyond the schema: date inference rules, canonical meal_type time mapping, when recipe_name supplies macros, how fluids and alcohol_g interact, and the explicit rule to never call without all four macros populated. This goes far beyond what the input schema alone conveys.
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: 'Log a meal to the user's food diary,' and expands with concrete trigger conditions ('mentions eating, describes a meal, or asks to log food'). It covers special cases like fasting and drinks without blurring the core purpose, and it is clearly distinguishable from siblings like update_meal and list_meals.
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 gives detailed when-to-use guidance: direct meal logging, repeats, saved recipes, brand names, fasting days, and drinks/hydration. It explicitly names alternatives such as list_meals for repeats and update_meal for correcting duplicates, and it states this is the single write path for drinks, clearly routing behavior away from other tools.
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?
Discloses the tool's own unit conversion, exercise-name resolution, near-miss prompting, silent matching behavior, and saved-workout semantics. The destructive annotation aligns with logging side effects, with no contradiction.
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 long but well-sectioned and each section conveys important rules. A few repeated emphases could be tightened, but the length is largely warranted 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?
Provides enough context to call the tool correctly: what to infer, when to ask, how to structure sets, how to handle units and equipment, and what the tool returns. Even without an explicit output schema, the return value and follow-up usage are covered.
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?
Adds substantial meaning beyond the schema: unit-input overrides, per-set reps/holds/carries, equipment load basis, superset grouping, slot inference, RPE interpretation, and saved-workout fields. This goes well beyond the field 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?
Clearly states the tool logs a complete workout session with exercises, sets, reps, weights, and metadata. It also distinguishes itself from related actions like updating, deleting, or proposing workouts.
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 says when to use it: when the user describes finishing a workout or asks to log training. It also says not to use it for future workouts and explains saved-workout mode and follow-up use with the returned ID.
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 thoroughly explains the side effects: writing a 0-kcal food_log entry for 'fast', leaving the day blank for 'forgot', and clearing both for 'unanswered'. It also notes that it refuses to touch days with real meals. This goes beyond the annotations (readOnlyHint=false, destructiveHint=true) by detailing exactly what changes occur to the data.
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 clear but somewhat repetitive, repeating the three-state definitions twice and the 'setting one clears the other' rule twice. It could be tightened without losing meaning, but it remains organized and not excessively verbose for the complexity of the tool.
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 description covers prerequisites (use list_meals first), parameters, exact effects, and failure conditions (refuses days with real meals). It even notes that the tool is for chat usage instead of the in-app prompt. No critical context is missing for an agent to invoke this 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?
Both parameters (date, answer) are described in the schema with full coverage. The description further elaborates on the 'answer' enum values—'fast' means intentional 0-calorie day, 'forgot' means day stays excluded, 'unanswered' clears any prior answer—adding richer semantics beyond the schema's basic 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 clearly states the tool's action: 'Set, change, or undo the answer to why is this day empty?' It specifies the resource (a date) and the exact states (fast, forgot, unanswered) it manages. It also distinguishes itself as the only way to move between these states, making its purpose unambiguous.
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?
Explicit usage guidance is provided: 'Use when the user wants to flip a fast day to forgotten (or back), or undo either one, in chat instead of the in-app prompt.' It also advises to 'Use list_meals first if unsure whether the date already has real food logged' and mentions refusal when real meals exist, giving clear when-to-use and when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnlyHint=false, destructiveHint=true, idempotentHint=true. The description adds exactly the contextual detail the rubric asks for: what gets destroyed ("remaining sets renumber; an emptied exercise/slot is removed automatically"), side effects (rename "preserves set IDs, RPE, notes; rebuilds NSI"), silent failure modes (missing equipment tag "silently halves or doubles NSI"), and error semantics (ambiguous matches "error rather than guessing," with "nothing changed"). No contradiction 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long (~450 words) but earns most of its length: 19 parameters, 8 operation types, and multiple addressing schemes justify dense detail, and the section headers (UNIT INPUTS, FIND THE SESSION, OPERATIONS, SUPERSET SLOTS, LITERAL NAME, EQUIPMENT, SAVED WORKOUTS) make it scannable, with the highest-risk guardrail (units) front-loaded. It loses a point for minor redundancies — the set-addressing concept is restated a few times, and it references input_distance_unit/input_length_unit that do not appear in the schema.
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?
An output schema exists, so return-value documentation is unnecessary. The description covers every operational need: session disambiguation rules, ambiguity/error behavior, cross-tool prerequisites (get_workout for slot names and set_ids, list_exercises for canonical names, get_exercise_history for progression), the Saved Workout alternative, and post-call user communication ("relay it in your own words," "ask the user which they meant"). Nothing required for correct invocation 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 100%, so the baseline is 3, but the description goes far beyond type/format notes: UNIT INPUTS explains when to set input_weight_unit and when to omit the companion; OPERATIONS defines the set_id vs exercise_name+set_position addressing duality; EQUIPMENT gives the load-basis meaning ("dumbbell_pair is one dumbbell in EACH hand, weight_lb PER HAND"); LITERAL NAME explains resolver-skipping and NSI implications. These are value semantics the schema alone could not convey.
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 — "Update a workout session: correct metadata, fix set values, rename/add/remove exercises or individual sets, or move exercises between supersets" — and closes the scope with "Use for any post-log correction." This clearly differentiates it from log_workout (creation) and delete_workout (removal) among the large sibling set.
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?
Explicit when-to-use guidance is given: "Use for any post-log correction." It routes to siblings with concrete conditions — "get_workout still gives full detail ... when needed; list_exercises first if adding or renaming" — and covers the alternative target via "pass saved_workout_id to edit a reusable Saved Workout instead of completed workout history." It even provides an exclusion: "For progression requests, inspect real exercise history first rather than applying a deterministic formula."
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?
Despite strong annotations (destructiveHint=true, readOnlyHint=false), the description adds important behavioral detail: irreversibility, cascade deletion of linked hydration events, and the exact error behavior when a match is not exactly one meal. It also clarifies that nothing is deleted on ambiguity, which is critical safety context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every sentence earns its place. It is front-loaded with purpose, then organized into clearly capped sections (FIND THE MEAL, HYDRATION) with no filler or 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?
For a destructive, irreversible operation, the description covers all critical aspects: how to identify the exact meal, what happens on ambiguity, retry guidance, and cascade effects. An output schema exists, so return-value documentation is not the description's responsibility. 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 100%, but the description adds substantial selection logic: id is an alternative to date+name, name is a case-insensitive substring used only for disambiguation, and date defaults to today. This gives the agent the decision rules needed to choose the right parameter combination, going well beyond the 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 a specific verb and resource: 'Permanently delete a meal entry.' It also states the exact triggering condition ('when the user explicitly asks to remove or delete a logged meal'), which clearly distinguishes it from related meal tools like update_meal and log_meal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance, including the user-intent trigger. It also provides a detailed decision procedure for locating the meal (id vs. date+name, name only when multiple meals exist) and an explicit exclusion: do not issue a separate hydration delete. This fully routes the agent away from incorrect usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveness and idempotency, and the description adds irreversibility, ambiguity-handling guidance, and the error behavior with candidate IDs. The description and annotations align, and the additional context meaningfully exceeds what annotations alone 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 most important facts (permanence, irreversibility, ambiguity handling) followed by a compact selector block. Every sentence adds operational value and there is 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?
Given the tool's destructive nature and the non-obvious selector logic, the description fully equips an agent to call it correctly: it covers user clarification, parameter selection, ambiguity resolution, and error recovery. The output schema and annotations cover remaining details, so nothing material 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 100%, but the description adds crucial cross-parameter semantics: the selector relationship between id and session_date, the optional narrowing role of session_category, that session_category is ignored when id is given, and the exactly-one-required constraint. This goes well beyond the baseline 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 states a specific verb ('Permanently delete') and a specific resource ('a recovery session log entry'), clearly distinguishing it from sibling delete/update/log tools. The title annotation adds a parallel label, and the resource is unambiguous against the large set of 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent on when to ask the user for clarification, how to resolve the target session using either id or session_date, and what to do if multiple sessions match. It also clearly states that exactly one of id or session_date is required, which is not reflected in the schema's required parameters.
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 reinforces the destructive nature ('Permanently delete') and adds transparency about the idempotent behavior (error with candidate IDs on ambiguous date). It goes beyond the annotations by detailing the exact failure mode and retry guidance.
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 yet complete, comprising two sentences and a selector note. Every word contributes to usage clarity, with no redundant or vague statements.
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 delete operation, the description covers all necessary context: target, selector, exclusivity, and error handling. The lack of output schema details is acceptable since a delete confirmation is standard and does not hinder usage.
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?
Both parameters (id and date) are fully described in the schema and the description, including the semantics of date ('any day within the entry's period') and the exclusivity requirement. High schema coverage combined with clear prose makes parameter usage unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Permanently delete') and the target ('a wellbeing entry'), with no ambiguity. It effectively distinguishes this from sibling tools like update or log by specifying deletion and the selector mechanism.
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 explains when to use the tool by providing a selector rule: pass id or date, exactly one required. It also describes the error condition when the date matches multiple entries, giving clear guidance for resolution.
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 annotation destructiveHint=true is reinforced by the description's use of 'Permanently delete' and 'irreversible.' The description also explains the idempotent behavior (if no unique match, nothing is deleted and an error is returned), which aligns with idempotentHint=true. No contradictions exist 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?
The description is well-structured with clear sections: the primary purpose, FIND THE SESSION, and SAVED WORKOUTS. It avoids redundancy and each sentence adds necessary information. The use of bold labels and concise bullets (though not bullets) makes it easy to parse. Despite being lengthy, it is efficiently organized and not verbose.
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 description fully covers the decision tree for selecting parameters: session_id vs session_date+name, defaults, the saved_workout_id alternative, and the error case (no unique match). It also states the destructive and irreversible nature, leaving no ambiguity for an agent. Given the moderate complexity (4 params, 0 required, with defaults and alternatives), the description is complete.
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?
All four parameters are fully described in the schema, and the description adds valuable context beyond the schema. For example, session_id is described as an 'Alternative to session_date + name,' session_date includes format and default, name explains substring/case-insensitivity and when it applies, and saved_workout_id clarifies its distinct purpose. The description references the FIND THE SESSION section for cross-guidance, making semantics clear.
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 and resource: 'Permanently delete a workout session and all its exercises and sets.' It also explicitly says 'Use when the user wants to remove a logged workout entirely,' providing unambiguous intent. The distinction between completed workout history and reusable saved workouts is also clarified.
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 gives explicit usage guidance: it instructs when to use the tool and how to select the correct target. It explains the two identification paths (session_id vs session_date + name), the default for session_date, and the alternative for saved_workout_id. It also states the error behavior when no unique match exists, so the agent knows when to retry or use a different parameter.
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 (readOnlyHint, idempotentHint, destructiveHint false), the description adds behavioral context: it states BMI in the output is derived from the user's canonical height and that day's resolved weight, and instructs the agent not to recompute it. It also explains default parameter behavior (infer 30 days ago to today). These details help the agent understand side effects and derived data, exceeding annotation-only transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It covers purpose, usage conditions, range constraints, and behavioral notes without unnecessary verbosity. Each sentence serves a distinct purpose: identifying the resource, stating when to use, noting the 31-day limit, and explaining parameter inference. No fluff 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?
Given an output schema exists, the description need not explain return values. It fully covers input parameters, defaults, usage context, range limits, and derived data behavior. The description provides all necessary information for an agent to invoke the tool correctly in various scenarios, making it contextually complete.
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 descriptions for start_date and end_date specify format (YYYY-MM-DD) and defaults ('30 days ago', 'today'). The description reinforces these defaults and adds the 'INFER — do not ask' guidance, making the parameter semantics fully clear. Schema coverage is 100%, and no enums exist, so the description effectively complements 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 states the tool lists body composition entries within a date range. It specifies the resource ('body composition entries') and scope ('date range'), and the context signals show sibling tools include similar list tools, enabling an agent to distinguish this from list_workouts, list_meals, etc. The verb 'list' and explicit resource make the purpose unambiguous.
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 the tool ('when the user asks about their weight history, body fat trend, or any body metrics over time'). It also provides guidance for handling longer periods by making multiple calls with sequential date ranges, and instructs the agent to infer default parameters rather than asking the user. This gives clear, actionable usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior; the description adds transparency about the output structure (compact summary then individual runs) and that metrics are computed together, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with the primary purpose first, then output details, then usage guidance; each sentence adds value, including the list of computed metrics and the note about longer spans.
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 provides all necessary context for an agent to decide when and how to use this tool, including return structure and limitations, with no missing guidance.
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?
Both parameters are fully described with format and defaults in the schema, and the description adds crucial semantics about the maximum range (92 days) and default window (7 days ago to today).
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 lists runs within a date range, specifies the resource and scope, and differentiates it by being the preferred single read for computed metrics, contrasting with piecing together data from multiple calls.
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 explicitly positions this tool as the preferred single read for specific metrics, implies alternatives by stating 'rather than pieced together from several calls', and gives usage guidance for longer spans by advising multiple consecutive calls.
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 annotations already provide readOnlyHint and destructiveHint, and the description adds transparency about the returned data fields (duration, score, stage breakdown) and the nature of the entries. There is no contradiction; the description supplements the annotation adequately.
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 yet information-dense, covering purpose, scope, parameters, defaults, limits, and exclusions in a clear, structured format without superfluous wording.
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?
All necessary details for correct usage are present: the data returned, the date range constraints, the default behavior, and the exclusion of naps. Given the tool's simplicity, the description is fully complete and leaves no ambiguity.
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?
Both parameters are explained with format and default values in the description, adding guidance on the 31-day limit and the inference of defaults, which goes beyond the schema's basic descriptions. This is particularly valuable given the schema only lists field names and 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 verb 'List' clearly specifies the action, the resource 'sleep log entries' is unambiguous, and the scope (date range) is defined. It also implicitly differentiates from logging a new sleep entry via the sibling tool 'log_sleep'.
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 the maximum range of 31 days and instructs to make multiple calls for longer periods. It also clarifies the default values for start_date and end_date, and notes that daytime naps are excluded, providing clear when-to-use 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?
Annotations already mark it as read-only, idempotent, and non-destructive; the description adds further transparency by explaining that the tool is not a prerequisite for update/delete operations and that it returns ids useful for resolving ambiguous matches. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence contributes: the main purpose, the relationship to update/delete, the 31-day limit, and the parameter defaults. No redundant or filler content; the structure flows logically from what the tool does to how to use it.
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 two optional parameters and the presence of an output schema (mentioned in context), the description provides sufficient context for an agent to call the tool correctly. It covers parameter defaults, usage scenarios, and operational limits, so no missing information would cause incorrect invocation.
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 fully describes both parameters with types and defaults, and the description reinforces their behavior ('INFER — do not ask' with default values), clarifying that the agent should infer these rather than prompt the user. This adds semantic value beyond the schema's basic metadata.
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?
Clearly states the action ('List wellbeing log entries') and the resource, with explicit scope ('within a date range'). It distinguishes itself from sibling tools by noting that update_wellbeing and delete_wellbeing can resolve entries on their own, making list_wellbeing specific to trend queries and id retrieval after ambiguous matches.
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?
Provides explicit when-to-use guidance: for trends over time or getting an id after an ambiguous match, and explicitly states it is not required before update/delete. Also gives operational constraints (maximum 31 days per call) and default parameter values, leaving no ambiguity.
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 annotations already mark the tool as read-only, idempotent, and non-destructive, and the description does not contradict any of these. It additionally discloses the output format (short text summary alongside visual view) and the UI preference, making the behavior fully transparent without adding any misleading side effects.
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 redundant words. It packs the key purpose, filtering capabilities, UI preference, and output summary into a compact but complete statement.
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 description gives the agent enough context to decide when to call the tool (when the user asks about progression) and what to expect (interactive chart, summary text). It also differentiates itself from text-based alternatives, covering the essential contextual needs for correct usage.
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 detailed descriptions for all three parameters, including the enum for range and the default behavior for exercise. The function description reinforces their purpose as filters/picker, and the schema coverage is 100%, ensuring the agent understands each parameter's role.
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 explicitly states the function shows 1-rep-max progression over time as an interactive line chart with filters for date range and muscle group, and an exercise picker. This makes the tool's purpose unambiguous and distinct from other workout-related tools.
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 provides clear guidance: when the user asks about this topic, prefer this tool and render the interactive app rather than describing rows in text. This directly tells the agent when and how to invoke the 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?
Beyond the readOnly and destructive annotations, the description discloses the output behavior (returns a short text summary alongside a visual view) and the preference to render an interactive app, giving full transparency.
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 yet covers purpose, usage, and output in three sentences with no redundant or vague phrasing.
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?
It provides sufficient context for an agent to decide when to use the tool, what it returns, and how to invoke it. The included field list compensates for the absence of an explicit output 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?
The single parameter 'date' is fully described with format (YYYY-MM-DD), optionality, and default behavior (most recent sleep entry), providing complete semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: showing one night of sleep in detail with specific attributes (duration, score, stages, etc.) and identifies it as preferred for last-night or specific-night queries.
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 explicitly gives when-to-use guidance ('prefer this for last-night or specific-night sleep questions') and instructs to render the interactive MCP app instead of describing rows in text, making alternatives implicit.
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

Wellness Project MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Wellness Project MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/turnnoblindeye/wellness-project-mcp/badges/card.svg)](https://glama.ai/mcp/servers/turnnoblindeye/wellness-project-mcp)

Score Badge

Copy to your README.md:

[![Wellness Project MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/turnnoblindeye/wellness-project-mcp/badges/score.svg)](https://glama.ai/mcp/servers/turnnoblindeye/wellness-project-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/turnnoblindeye/wellness-project-mcp'

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