Skip to main content
Glama

Dayze — Life Context

Create To-do

create_todo

Save an actionable step the user asked for, standalone or under a goal_id. Dates are optional: omit what was not stated. A due date is a deadline, not calendar time, and no event is created. Breaking down a goal: propose steps first and save the ones the user accepts. ($0.05; 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_todo"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleYesTo-do title, e.g. Renew passport.
goal_idNoGoal id, e.g. 3f2a1b4c-8d9e-6f01-c2b3-c4d5e6f70809.
due_dateNoDue date YYYY-MM-DD; null clears, e.g. 2026-10-31.
due_timeNoHH:MM in the given time zone.
priorityNoPriority level: high, medium or low, e.g. medium.
request_idNoClient idempotency key (retries return original result).
descriptionNoTo-do details, e.g. Bring the signed form.
due_timezoneNoIANA time zone, e.g. Asia/Singapore.
idempotency_keyNoAlias for request_id.

Output Schema

NameRequiredDescriptionDefault
todoNo
accountNoThe Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
messageYes
todo_idYes
verifiedYes
provenanceNoWhich connector wrote the record and which connected Dayze account received it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / description / description
      Added value: +"To-do details, e.g. Bring the signed form."
    • addedInput schema / properties / due_date / description
      Added value: +"Due date YYYY-MM-DD; null clears, e.g. 2026-10-31."
    • addedInput schema / properties / goal_id / description
      Added value: +"Goal id, e.g. 3f2a1b4c-8d9e-6f01-c2b3-c4d5e6f70809."
    • addedInput schema / properties / priority / description
      Added value: +"Priority level: high, medium or low, e.g. medium."
    • addedInput schema / properties / title / description
      Added value: +"To-do title, e.g. Renew passport."
  2. Added

TDQS

A4/5.0
Behavior4/5

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

The annotations already state that this is a write operation that is not destructive and not open-world. The description adds useful context the annotations do not: a due date creates no calendar event, each call costs $0.05, and an API key is required. Return behavior is left to the output schema.

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?

Four short sentences, front-loaded with the purpose, followed by parameter and workflow guidance, then cost and auth in a closing parenthetical. Every sentence adds something, and none repeat the tool name or schema.

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

Completeness4/5

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

This is a 9-parameter create tool with full schema documentation and an output schema. The description covers the purpose, when dates apply, the event-free behavior, the goal-breakdown workflow, cost, and authentication. Return values are left to the output schema, and no critical gap remains.

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 the parameters are already fully documented and the baseline is 3. The description adds only the opt-in rule for dates and the deadline-versus-time distinction. That goes slightly beyond the schema, but does not justify more than the baseline.

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 gives a specific verb and resource: "Save an actionable step the user asked for, standalone or under a goal_id." This clearly distinguishes a to-do item from a goal or a calendar event. It stops short of naming a sibling, so it earns a 4 rather than 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 Guidelines4/5

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

It clearly says when to omit dates ("omit what was not stated") and separates a due date from calendar time ("no event is created"). For breaking down a goal, it also says to propose steps before saving accepted ones. There are no explicit exclusions beyond that, but the guidance is enough to call the tool correctly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.