Dayze — Life Context

Get To-dos

get_todos

Read-only

Read to-dos: actionable steps, standalone or under a goal, with linked goal and calendar sessions. due_date null means no due date, never today and never overdue. view: open (default), undated, unscheduled, upcoming, overdue, done, all. todo_id reads one; goal_id or query filters. Page with offset from next_offset. ($0.01; API key required)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_todos"
  }
}

Input Schema

Name	Required	Description
`view`	No	Which to-dos to list: open, undated, unscheduled, upcoming, overdue, done or all, e.g. open.
`limit`	No	Maximum rows to return, e.g. 20.
`query`	No	Words in the title or notes.
`offset`	No	Rows to skip for paging, e.g. 0.
`goal_id`	No	Goal id, e.g. 3f2a1b4c-8d9e-6f01-c2b3-c4d5e6f70809.
`todo_id`	No	Exact id from get_todos or create_todo. Titles are not accepted.

Output Schema

Name	Required	Description	Default
`count`	Yes
`today`	No
`todos`	Yes
`total`	Yes
`truncated`	Yes
`next_offset`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 9, 2026

addedInput schema / properties / goal_id / description

Added value: +"Goal id, e.g. 3f2a1b4c-8d9e-6f01-c2b3-c4d5e6f70809."

addedInput schema / properties / limit / description
```
Added value: +"Maximum rows to return, e.g. 20."
```
addedInput schema / properties / offset / description
```
Added value: +"Rows to skip for paging, e.g. 0."
```

addedInput schema / properties / view / description

Added value: +"Which to-dos to list: open, undated, unscheduled, upcoming, overdue, done or all, e.g. open."

AddedNov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/non-destructive annotations it discloses the two things an agent most needs: cost ($0.01) and auth (API key required). It also explains the non-obvious due_date null semantics ("never today and never overdue") and names next_offset as the paging cursor, which prevents an agent from misreading undated rows as overdue.

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?

Dense but front-loaded: the read purpose comes first, then filters, then paging, then cost/auth. The telegraphic style ("todo_id reads one; goal_id or query filters") is efficient, though the enum list is partially redundant with the schema's view description.

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 six parameters are optional and fully documented in the schema, and an output schema exists, so return shape needn't be re-explained. The description covers the remaining gaps an agent would hit: default view, null due dates, single-vs-list mode, paging, cost, and auth.

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, and the description still adds meaning: the view enum is summarized inline, todo_id is framed as single-record mode, and goal_id/query are framed as filter mode. The due_date explanation is a genuine semantic addition rather than a restatement, though limit defaults and offset mechanics are left to 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?

Opens with a specific verb and resource: "Read to-dos: actionable steps, standalone or under a goal, with linked goal and calendar sessions." That single clause defines both the entity and its scope, so an agent knows exactly what this returns without comparing it to get_goals or other siblings.

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 concrete routing rules: view selects a queue with 'open' as default, todo_id reads a single item, and goal_id or query filters the list. It stops short of explicit when-not guidance (e.g. when to prefer a search-oriented sibling, or that combining todo_id with view is pointless).

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.