Taskaid

Create or update a list

save_list

Destructive

Upsert a list. Omit id to create a new one (name required). Pass id to rename an existing list, change its emoji or rewrite its note. Returns the saved list.

Input Schema

Name	Required	Description
`id`	No	List id. Pass to update an existing list; omit to create a new one.
`name`	No	Required when creating. On update, omit to keep the current name.
`note`	No	A note about the list, as Markdown, up to 500 characters: what it is for and how its tasks are handled. Replaces the whole note; null clears it.
`emoji`	No	A single emoji shown before the list name. Defaults to 📋 when creating; omit on update to keep the current one.

Output Schema

Name	Required	Description	Default
`id`	Yes
`name`	Yes
`note`	Yes
`emoji`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 3, 2026

removedInput schema / properties / note / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / note / type

Added value: +[
+  "string",
+  "null"
+]

removedOutput schema / properties / note / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / note / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Changed3 schema fields changedOct 14, 2026

addedInput schema / properties / note

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "A note about the list, as Markdown, up to 500 characters: what it is for and how its tasks are handled. Replaces the whole note; null clears it."
+}

addedOutput schema / properties / note

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

changedOutput schema / required

Previous value: -[
-  "id",
-  "emoji",
-  "name"
-]New value: +[
+  "id",
+  "emoji",
+  "name",
+  "note"
+]

Changed2 schema fields changedSep 7, 2026

addedInput schema / properties / emoji / description

Added value: +"A single emoji shown before the list name. Defaults to 📋 when creating; omit on update to keep the current one."

addedInput schema / properties / name / description

Added value: +"Required when creating. On update, omit to keep the current name."

First observedSep 7, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is known. The description adds that the call returns the saved list and that updates are partial (omit to keep current values), but it never states the genuinely destructive behavior — that saving a note replaces the entire previous note — nor what happens when an unknown `id` is passed. With annotations covering the mutation risk, this is adequate rather than rich.

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, front-loaded with the verb and the mode-switching rule, then the return value. Nothing is repeated and no sentence is expendable.

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?

With a fully documented schema, an output schema, and annotations, the description covers what an agent needs to choose the create or update path. The one real gap is error/conflict behavior for a nonexistent or stale `id`, which is documented nowhere in the definition.

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 coverage is 100% and every parameter carries its own description, including the note-replacement and emoji-default rules, so the schema does the heavy lifting. The description restates the create/update meaning of `id` but adds no format, length, or edge-case detail beyond 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?

The description names a specific operation (upsert) on a specific resource (a list), and immediately splits the two modes: omit `id` to create, pass `id` to update. It also enumerates which fields an update can touch (name, emoji, note), so an agent can distinguish this from save_task/save_plan without opening the schema.

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?

The trigger condition for the create path vs the update path is stated explicitly, which is the main branching decision for an upsert tool. It does not name siblings or say when to prefer `view_lists` for reading instead, so it stops short of full alternative routing.

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

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

Need Help?