Skip to main content
Glama
Sign In

MustDo

by jp.ltng
OverviewDiscussionsAdmin

TODO を追加

add_todo

TODO を追加する（source=mcp）。ひとことで TODO を言われたら title だけ渡す。due を省略すると明日の既定時刻（Account の timeZone での今日の翌日、Account.defaultTime、既定 09:00）になる。「明日 9 時」「今日 15 時」など利用者が時刻を言ったときだけ due を渡す（YYYY-MM-DDTHH:mm は Account の timeZone の時計、ISO8601 も可）。日付だけ言われたら due に YYYY-MM-DD を渡すと「その日の既定時刻」になる。繰り返しは repeat で（iOS カレンダーと同じ語彙: 毎日 / 毎週 月水 / 隔週 / 毎月 5 日 / 毎月 第 1 月曜 / 最終金曜 / 毎年 / 3 日ごと / 10 回で終了 / 12/31 まで）。初回は due（毎月 5 日なら due を 5 日に、毎年なら due の月日）。試用（30 日）も購読も切れていると isError + code=PAYMENT_REQUIRED。おやすみ時間（get_me の quietHours）に入る時刻は自動で終了時刻に寄せて保存する（単発は次の終了時刻、繰り返しは同じ日の終了時刻）。寄せたときは結果に quietHoursAdjusted（requested / actual / message）が付くので、そのことを利用者に伝える。

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

Input Schema

NameRequiredDescriptionDefault
dueNo鳴らす時刻。YYYY-MM-DDTHH:mm（Account の timeZone の時計）か、オフセット付き ISO8601。YYYY-MM-DD だけなら「その日の既定時刻（Account.defaultTime、既定 09:00）」。
notesNo
soundNoアラーム音。default, chime, marimba, beep, urgent, vibrateOnly, siren, klaxon, rapid, redalert, musicbox, harp, morning, bowl, droplet, breeze, horror, dread, ghost, lament, cello, rainy, fanfare, skip, sparkle
titleYes
repeatNo繰り返し（iOS カレンダーと同じ語彙）。省略した項目は既定値（interval 1・weekdays []・monthly.mode dayOfMonth・end.kind never）。範囲外は INVALID_ARGUMENT。例: 毎日 {kind:daily} / 毎週 月水 {kind:weekly, weekdays:[2,4]} / 隔週 {kind:weekly, interval:2} / 3 日ごと {kind:daily, interval:3} / 毎月 5 日 {kind:monthly}（due を 5 日に）/ 毎月 第 1 月曜 {kind:monthly, monthly:{mode:weekdayOrdinal, ordinal:1, weekday:2}} / 毎月 最終金曜 {kind:monthly, monthly:{mode:weekdayOrdinal, ordinal:-1, weekday:6}} / 毎年 {kind:yearly}（due の月日）/ 10 回で終了 {kind:daily, end:{kind:count, count:10}} / 12/31 まで {kind:weekly, weekdays:[2], end:{kind:until, until:"2026-12-31"}}

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it discloses the default due (tomorrow at Account.defaultTime, default 09:00), the quiet-hours auto-shift behavior and the quietHoursAdjusted field returned in the result, and the PAYMENT_REQUIRED error path. It stops short of covering permissions or the general response shape beyond quietHoursAdjusted.

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?

The purpose and the most common call pattern (title only) are front-loaded, and nearly every sentence carries actionable detail. The remaining text is one dense block without bullets, which makes the repeat guidance harder to scan than it needs to be.

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 create tool with a nested repeat object, no output schema and no annotations, the description covers defaulting, natural-language mapping, recurrence, error states and a side effect (quiet-hours adjustment). A brief note on the general success response or on notes/sound handling would make it complete.

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 60%, and the description compensates well by explaining due formats (local clock vs ISO8601 vs date-only), the repeat vocabulary and how natural-language phrases map to repeat structures, and the rule that the first occurrence is seeded from due. It adds little for notes and sound, 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?

States a specific verb and resource ("TODO を追加する") plus the source tag, so an agent immediately knows this is a create operation. It does not explicitly contrast itself with update_todo or complete_todo, but the create semantics are unambiguous against those 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?

Gives concrete when-to guidance: pass only title for a bare TODO request, and pass due only when the user actually states a time; a bare date goes into due as YYYY-MM-DD. It does not name alternative tools (update_todo, list_todos) or exclusions, which keeps it below a 5.

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

All MustDo toolsInspect
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