Dayze — Life Context

Create Tracker

create_tracker

Start a tracker for the user: title, tracker_type streak, sobriety, countdown or counter, start_date (default today), target_date for a countdown, target_days, emoji. Private. To reset one use reset_tracker. ($0.10; API key required)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>"
    },
    "name": "create_tracker"
  }
}

Input Schema

Name	Required	Description
`emoji`	No	Single emoji, e.g. 🎂.
`title`	Yes	Tracker title, e.g. Days sober.
`request_id`	No	Client idempotency key (retries return original result).
`start_date`	No	YYYY-MM-DD. Default today.
`target_date`	No	YYYY-MM-DD.
`target_days`	No	Number of days to reach, e.g. 30.
`tracker_type`	No	Tracker kind: streak, sobriety, countdown or counter, e.g. streak.
`idempotency_key`	No	Alias for request_id.

Output Schema

Name	Required	Description
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`created`	No
`message`	No
`event_id`	No
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 9, 2026
- addedInput schema / properties / emoji / description
```
Added value: +"Single emoji, e.g. 🎂."
```
- addedInput schema / properties / target_days / description
```
Added value: +"Number of days to reach, e.g. 30."
```
- addedInput schema / properties / title / description
```
Added value: +"Tracker title, e.g. Days sober."
```
- addedInput schema / properties / tracker_type / description
```
Added value: +"Tracker kind: streak, sobriety, countdown or counter, e.g. streak."
```
AddedNov 5, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds genuinely new context: the tracker is "Private" and the call costs "$0.10; API key required", which is important pre-invocation information. It stops short of describing limits such as whether counters need target_days or what happens on duplicate titles.

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

Conciseness5/5

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

One dense sentence covering fields, defaults, and the reset alternative, plus a short fragment for privacy and cost. It is front-loaded and contains no filler, though it is telegraphic in style.

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

Completeness4/5

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

With an output schema present, return values need not be explained, and the description covers auth, cost, privacy, and the key parameter semantics for an 8-parameter tool with only one required field. Minor gaps remain around what "Private" entails and whether non-countdown types reject target_date.

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 earns an extra point by describing conditional relationships the flat schema does not express, notably that target_date applies to a countdown and start_date defaults to today. It adds little for request_id/idempotency_key or emoji, which the schema already documents.

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 and resource ("Start a tracker") and enumerates the tracker kinds (streak, sobriety, countdown, counter), which is enough for an agent to recognize the operation. It does not distinguish itself from other create_* siblings like create_goal or create_todo, and the reset_tracker reference is a different operation rather than a true alternative, 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?

There is partial guidance: "target_date for a countdown" implies a conditional use of that field, and "To reset one use reset_tracker" routes away from this tool for resets. However, there is no explicit statement of when to choose this over create_goal or other tracking-adjacent siblings, and no prerequisites or exclusions beyond the reset pointer.

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

All Dayze — Life Context 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.