Skip to main content
Glama

Wellness Project

by ai.wellnessproject
OverviewDiscussionsAdmin

log_rest_day

Idempotent

Mark a date with user-selected day context: Rest Day, Sick Day, or Travel Day. Use Rest Day when the user intentionally takes the day off training, Sick Day when they say they are sick/recovering, and Travel Day when they say they are traveling. This context is visible to the AI team and workout-history reads.

Rest/Sick retain the existing rest-day training behavior. Travel is context-only: it does not mean the user skipped training and can coexist with a workout.

INFER — do not ask:

  • date: parse the user's reference; default to today

  • day_type: infer rest, sick, or travel from the user's wording; default to rest

Calling again on the same date updates the status in place. To remove the status, use cancel_rest_day.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoThe date to mark. Format: YYYY-MM-DD. Default: today.
day_typeNoUser-selected day context. Default: rest.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYesHuman-readable result text returned by the tool.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / date / description
      Previous value: -"The date to mark as a rest day. Format: YYYY-MM-DD. Default: today."New value: +"The date to mark. Format: YYYY-MM-DD. Default: today."
    • addedInput schema / properties / day_type
      Added value: +{
+  "description": "User-selected day context. Default: rest.",
+  "enum": [
+    "rest",
+    "sick",
+    "travel"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (idempotentHint=true, destructiveHint=false, readOnlyHint=false), and the description reinforces idempotency by stating a repeat call updates status in place. It adds non-obvious behavior: visibility to the AI team and workout-history reads, and that Travel is context-only and can coexist with a workout. Strong given the annotations already carry the safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose before branching into day_type semantics, with a clear INFER block and a closing note on idempotency/removal. Every sentence carries information, though it is slightly verbose for a two-parameter 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?

With an output schema present, return values need not be described. The description covers date interpretation, all enum semantics, idempotent re-call behavior, cross-system visibility, and the removal path via cancel_rest_day, leaving no gap for correct 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 coverage is 100%, so the baseline is 3, but the description earns more by explaining how to derive each parameter: parse the user's date reference defaulting to today, and infer day_type from wording defaulting to rest. This adds interpretation guidance the schema does not provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Mark) and resource (a date with day context), and enumerates the three day types. It distinguishes itself from the sibling cancel_rest_day and is trivially separable from log_wellbeing/log_sleep. An agent knows exactly what this tool produces.

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 maps each day_type to the user condition that selects it (takes day off, sick/recovering, traveling), and names cancel_rest_day for the removal case. It even prescribes inference over asking, which removes ambiguity about behavior at call time.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Wellness Project toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources