Vitamin D Explorer

log_sun_session

Sets a day's answer in the signed-in user's history calendar. Three values: confirmed=true (went out, the default), confirmed=false (had usable sun but stayed in), confirmed=null (clear the answer). Defaults to today. Requires OAuth (scope history:write).

Input Schema

Name	Required	Description
`date`	No	Day to set, YYYY-MM-DD; defaults to today
`minutes`	No	Minutes the user reports having spent in the sun (acknowledged, not stored)
`confirmed`	No	true (default) the user went out; false they had sun but stayed in; null clears the answer

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 27, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

Changed2 schema fields changedJul 30, 2026

addedInput schema / properties / confirmed

Added value: +{
+  "description": "true (default) the user went out; false they had sun but stayed in; null clears the answer",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

changedInput schema / properties / date / description

Previous value: -"Day to confirm, YYYY-MM-DD; defaults to today"New value: +"Day to set, YYYY-MM-DD; defaults to today"

First observedJul 27, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that this mutates the user's history calendar, requires OAuth with scope history:write, and defaults the date to today. It stops short of saying whether an existing answer is overwritten, whether the call is idempotent, or what is returned.

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 with zero filler, front-loading the action and then the value semantics and auth requirement. Every sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-required-parameter mutation with no output schema, the description covers action, value states, date default, and auth scope — enough to invoke correctly. Only the overwrite/return behavior is left unstated, which is a minor gap.

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 all three parameters are already documented, including the tri-state confirmed value and the today default. The description restates those semantics faithfully but adds no format or edge-case detail beyond the schema, so the baseline of 3 applies.

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?

States a concrete verb and resource: 'Sets a day's answer in the signed-in user's history calendar', which is clearly distinguishable from read-oriented siblings like get_my_history or get_current_status. It does not name an alternative sibling explicitly, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The three-value breakdown (went out / had sun but stayed in / clear the answer) effectively guides which value to send, which is implied usage guidance. However, there is no statement about when to prefer this tool over siblings such as estimate_sun_session or set_history_location, nor any exclusions.

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

All Vitamin D Explorer tools Inspect

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

Need Help?