Taskaid

Set daily plan

set_daily_plan

Destructive

Write or edit the user's plan for a day. Send content for the whole plan or patch to change part of it, not both. title can go with either, or alone to rename the plan. Read the user's tasks first for context.

Input Schema

TableJSON Schema

Name	Required	Description
`date`	No	Calendar day to write the plan for, as "YYYY-MM-DD" (e.g. "2026-05-28"). A full ISO datetime is also accepted — only the date component is used. Defaults to today.
`patch`	No	Edits to the plan, applied in order and atomically — if one fails, nothing is written. Prefer this to resending `content`: text you do not send keeps its exact wording.
`title`	No	A few words naming what the day is for. Omit to keep the current title; null clears it.
`content`	No	The whole day's plan, as Markdown — headings, lists, bold, inline code. Send literal newlines and characters, not escape sequences. Replaces any existing plan; to change part of one, send `patch`.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`url`	Yes
`date`	Yes	Calendar date, "YYYY-MM-DD".
`title`	Yes
`content`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 16, 2026

addedInput schema / properties / title

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 120,
+      "minLength": 1,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "A few words naming what the day is for. Omit to keep the current title; null clears it."
+}

addedOutput schema / properties / title

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "id",
-  "url",
-  "date",
-  "content"
-]New value: +[
+  "id",
+  "url",
+  "date",
+  "title",
+  "content"
+]

Changed2 schema fields changedSep 16, 2026

removedOutput schema / properties / date / format
```
Removed value: -"date"
```

removedOutput schema / properties / date / pattern

Removed value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$"

First observedSep 7, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true, and the description consistently describes a write/edit operation. Beyond annotations, it discloses the mutual exclusivity of content and patch and clarifies that title can accompany either or stand alone — useful behavioral constraints not carried by the annotation alone.

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?

Three short sentences carry all essential information: the core action, the parameter usage modes, and a practical prerequisite. Every sentence earns its place and the main verb+resource is front-loaded.

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?

For a 4-parameter tool with 100% schema coverage, an output schema, and annotations covering destructiveness, the description is complete. It covers all parameter relationships and adds the read-tasks-first context without needing to duplicate schema details or return-value documentation.

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 parameters are already documented. The description adds valuable cross-parameter semantics, especially the 'not both' rule for content/patch and the flexibility of title, which are not fully evident from individual schema property descriptions.

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 description opens with a specific verb and resource: 'Write or edit the user's plan for a day.' This clearly distinguishes it from siblings like view_daily_plan (read) and save_task/save_list (different resources).

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 provides clear internal guidance on when to use content vs. patch ('Send `content` for the whole plan or `patch` to change part of it, not both') and adds the precondition 'Read the user's tasks first for context.' It does not explicitly route to a sibling alternative, but none of the siblings write daily plans.

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

All Taskaid tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?