Skip to main content
Glama

TODO 一覧

list_todos
Read-only

TODO を一覧する。date(1 日)か from/to(両端含む、YYYY-MM-DD、Account の timeZone)で絞る。省略で全期間。status の既定は pending。削除済み(deletedAt あり)は含めない。繰り返しは展開せず repeating にテンプレートとして返し、範囲内の Occurrence(回ごとの done / skipped / スヌーズ)を添える。展開はアプリ側で MCP はしない。規則(repeat): kind × interval(1=毎、2=隔)。daily は interval 日ごと、weekly は weekdays(1=日…7=土。空なら dueAt の曜日)の曜日、monthly は dueAt の日(dayOfMonth。無い月は月末)か第 n 曜日(weekdayOrdinal、ordinal -1 = 最終)、yearly は dueAt の月日。終了は end(never / until = その日を含む / count = 開始からの回数)。初回は dueAt、各回の時刻は dueAt の時分(timeZone の時計)。

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": "list_todos"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoこの日まで(含む)
dateNoこの 1 日だけ
fromNoこの日から(含む)
statusNo既定 pending。done / skipped は単発だけに効く
includeRepeatingNo既定 true。false で繰り返しテンプレートを省く

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered, but the description adds substantial non-obvious behavior: soft-deleted records (deletedAt) are excluded, and repeating todos are returned as templates rather than expanded, with per-occurrence done/skipped/snooze data attached and expansion left to the app. It stops short of stating ordering, limits, or pagination.

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

Conciseness3/5

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

The content is front-loaded correctly (purpose, filters, defaults, exclusions, then recurrence), but it is a single dense block of clauses with no structural separation, and the recurrence rules run long. Every sentence is relevant, yet the reader must parse it as one paragraph.

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?

Given no output schema, the description carries return-value burden and does explain that templates come back under 'repeating' with occurrence data attached. It leaves gaps around result ordering, any cap on returned items, and the exact shape of an occurrence, which matter for a list tool with no output schema.

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 goes beyond it: it clarifies that date is one day, from/to are inclusive, and that dates are interpreted in the Account's timeZone, none of which the schema states. The recurrence grammar (interval, weekdays numbering, ordinal -1, end semantics) further explains values that the schema leaves silent.

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?

The opening sentence 'TODO を一覧する' states a specific verb (list) and resource (TODO), and the siblings are all mutations (add/complete/delete/update/snooze), so the read-only listing role is unambiguous. The follow-on clauses immediately narrow scope to date filtering and recurrence, which no sibling does.

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 explicitly says when to use date (a single day) versus from/to (inclusive range), and that omitting both means all periods, plus the default status of pending. It does not name an alternative tool or say when NOT to use this one, but the filtering guidance is concrete enough to select the right parameters.

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.