Taskaid

by ai.taskaid

Overview Discussions Admin

Server Details

Taskaid is built for you and your agents to get work done together.

Ownership verified

Status: Healthy
Uptime: 99.6% over 63 days
OAuth: Works in Glama
Last Tested: 2026-11-07 09:12
Transport: Streamable HTTP · MCP 2025-11-25
URL
ChatGPT: Taskaid
Claude: –

TDQS

A3.7/5.0

Scored 2026-11-03 17:45 across 7 tools

Disambiguation4/5

Each tool targets a distinct resource (list, task, plan) and a distinct action, so misselection is unlikely. The only soft spot is the read side: search_tasks vs view_task overlap in purpose (search truncates notes, view_task returns the whole note), and save_list (singular) vs view_lists (plural) for the same resource adds a small mental wrinkle, though descriptions resolve both.

Naming Consistency4/5

A clear verb_noun pattern runs throughout: save_*, view_*, search_*. The minor deviation is singular/plural inconsistency on the same resource (save_list vs view_lists) and the asymmetric read verbs (view_task vs search_tasks), but the overall convention is predictable and readable.

Tool Count5/5

Seven tools covering three resources (lists, tasks, plans) with writes and reads for each is well-scoped, with no filler. Each tool earns its place and the set stays comfortably in the 3-15 sweet spot.

Completeness3/5

Create, read, and update are covered for all three resources via upsert-style saves, and patching is supported. However, there is no delete operation for tasks, lists, or plans — unlinking a task with a null listId is the only removal path, which is a notable lifecycle gap for a task manager.

Available Tools

7 tools

save_listCreate or update a listA

Destructive

Inspect

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.

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
`id`	Yes
`name`	Yes
`note`	Yes
`emoji`	Yes

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.

save_planCreate or update a daily planA

Destructive

Inspect

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.

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

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

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds the mutual-exclusivity constraint and the read-tasks-first prerequisite, but never warns that sending content overwrites the existing plan, which is the main destructive behavior an agent should know about.

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 write action and the content-versus-patch choice before the optional title and the workflow hint. No filler or redundant restatement of the title.

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?

An output schema exists, so return values need no explanation, and the parameter schema is fully documented. The remaining gap is behavioral: nothing in the description tells the agent that a full-content write discards the prior plan, which matters for a destructive, no-required-parameter tool.

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 would be 3, but the description adds genuine meaning the schema lacks: content and patch are mutually exclusive, and title alone means rename. That constraint is not expressed anywhere in the property definitions.

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?

The description opens with a specific verb and resource, 'Write or edit the user's plan for a day', which distinguishes it from the read-side sibling view_plan by naming the mutation plainly. It does not explicitly name a sibling as an alternative, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the selection rule outright: send content for the whole plan or patch to change part of it, 'not both', and explains that title can accompany either or stand alone to rename. It also supplies a prerequisite workflow hint, telling the agent to read the user's tasks first for context.

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

save_taskCreate or update a taskA

Destructive

Inspect

Upsert a task. Omit id to create a new one (name required). Pass id to update an existing task — any subset of fields. To change part of the note, pass patch instead of note. Use null on listId to unlink a task from its list. Returns the saved task.

Name	Required	Description
`id`	No	Task reference: TASKAID-45, #45 or 45. Pass to update an existing task; omit to create a new one.
`name`	No	Required when creating. On update, omit to keep the current name. A few words naming the action; the day goes in `when`, the detail in `note`.
`note`	No	Task notes, as Markdown, up to 15,000 characters — rendered as rich text in the app. Headings, lists, bold, and inline code are supported. Send literal newlines and characters, not escape sequences.
`when`	No	The day the task is scheduled for, as "YYYY-MM-DD" (e.g. "2026-05-21"). Omit or pass null when creating to leave the task in Inbox; pass null when updating to move it back there.
`patch`	No	Edits to the note, applied in order and atomically — if one fails, nothing is written. Only on update, in place of `note`: text you do not send keeps its exact wording.
`listId`	No	Pass null to unlink the task from its list.
`starred`	No
`duration`	No	Estimated duration in minutes, up to a day. Null clears the estimate.
`reminder`	No	A time of day for a reminder, "HH:MM" in 24-hour time (e.g. "15:00"), on the task's `when` day in the user's time zone. Moving the task moves it; null removes it. At that time Taskaid sends the `task.reminded` event to subscribed assistants.
`completed`	No	Marks the task done. True stamps `completedAt` with the time of the call, never the time the work finished.

Output Schema

Name	Required	Description
`id`	Yes
`url`	Yes
`list`	Yes
`name`	Yes
`note`	Yes
`when`	Yes	Calendar date, "YYYY-MM-DD", or null for Inbox.
`source`	Yes
`starred`	Yes
`duration`	Yes
`reminder`	Yes	Time of day on the `when` day, "HH:MM", or null for none.
`completed`	Yes
`updatedAt`	Yes
`completedAt`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description explains the source of that destructiveness implicitly by directing callers to `patch` when they want to preserve unmentioned note text, and it states the return ("Returns the saved task"). It does not spell out permission requirements or what an update does to fields that are omitted, leaving some behavioral inference to the schema.

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?

Five short sentences, front-loaded with the create/update split, then the note-editing rule, then the unlink rule, then the return. No filler and no repetition.

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 10-parameter destructive upsert with an output schema, it covers the decisions an agent actually has to make: create vs update, note replacement vs patch, and unlinking via null. Parameters like `starred`, `duration`, and `completed` are left entirely to the schema, which is acceptable given 90% coverage.

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 90%, so the baseline is 3 and the schema already documents almost every parameter's meaning. The description reinforces the critical create-vs-update contract for `id` and the `note`/`patch`/`listId` semantics, but adds little beyond the already-rich schema text.

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 precise verb+resource ("Upsert a task") and immediately splits the two modes: create when `id` is omitted, update when it is passed. The resource noun cleanly separates it from save_list and save_plan, and the upsert/save verb separates it from view_task and search_tasks.

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?

Explicit routing is given for the two in-tool paths (omit `id` to create with `name` required; pass `id` to update with any subset of fields) and for the note-editing choice ("pass `patch` instead of `note`"). It does not mention sibling workflows, e.g. using search_tasks or view_task to obtain the `id` before calling this, so it stops short of a full when-to-use map.

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

search_tasksSearch tasksA

Read-only

Inspect

Search the user's tasks. A bare call returns tasks from every list. Text search is optional. Use view_lists to resolve a list to its id.

Name	Required	Description
`when`	No	Narrow by scheduled day. Each bound is a day, "2026-09-19", or an ISO 8601 duration from today in the user's timezone: "P0D" is today, "P1D" tomorrow, "-P1D" yesterday, "P2W" two weeks out. Inbox tasks have no day and never match.
`limit`	No	Max results. Defaults to 50, up to 100.
`query`	No	Narrow to tasks matching this text. Every whitespace-separated word must appear in the task's name or note (case-insensitive, any order), so extra words narrow the results rather than widening them — pass distinctive keywords, not a full sentence.
`cursor`	No	Continue from a previous response's nextCursor, with the same filters. Omit for the first page.
`listId`	No	Narrow to a single list. Omit to span every list.
`completed`	No	Narrow to finished (true) or open (false) tasks. Omit for both.

Output Schema

Name	Required	Description
`tasks`	Yes
`nextCursor`	No	Pass as cursor, with the same filters, to read the next page. Absent on the last page.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare a safe read-only, closed-world operation, and the description adds real behavior: the default unfiltered scope and the optionality of text search, which an agent would otherwise have to infer. Pagination exists in the schema but the description's single cursor sentence is only covered via the parameter, not explained here.

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 purpose and default behavior, followed by the optionality note and the sibling cross-reference. No redundant wording and nothing buried.

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?

Output schema covers return values and the full schema covers filter syntax, so the description only needs to set scope and prerequisites, which it does. A brief note on result ordering or default sort would close the remaining gap.

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, but the description adds genuine value for listId by telling the agent to resolve a list to its id via view_lists first. It also clarifies that query is optional and that a bare call needs no parameters.

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 ("Search the user's tasks") and clarifies scope with "A bare call returns tasks from every list." It does not explicitly contrast itself with view_task, but the mention of view_lists for id resolution shows awareness of the sibling set.

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 clear when-to-use context: omit filters to span every list, text search is optional, and call view_lists first to resolve a list name to an id. It stops short of naming when another sibling (e.g. view_task) should be used instead.

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

view_listsView listsB

Read-only

Inspect

Read the user's lists and their notes.

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`lists`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds only the hint that notes accompany lists in the result, and says nothing about ordering, pagination, volume limits, or whether all lists are returned unconditionally.

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?

A single eight-word sentence with no filler and the verb front-loaded, so it is efficient by any measure. Its brevity tips into under-specification, but that cost is already captured in the usage and completeness dimensions rather than being wasted wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and there are no parameters to document, which lowers the burden considerably. Still, for a zero-argument entry point in a family of seven sibling tools, the definition gives no sense of result scope or how an agent should choose it over view_task or search_tasks.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly implies no input is needed to perform the read.

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 ('Read') and resource ('the user's lists and their notes'), so an agent can tell this is the read counterpart to save_list. However, it never distinguishes itself from siblings like view_plan, view_task, or search_tasks, so the scope of what 'lists' covers remains implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no exclusion of alternatives, and no mention of how this differs from search_tasks or view_task. The agent must infer that this is the retrieval path for lists versus the save_list write path.

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

view_planView daily planA

Read-only

Inspect

Read the user's plan for a given day. Defaults to today. Useful before regenerating so an agent can see what is already in place.

Name	Required	Description	Default
`date`	No	Calendar day to read 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.

Output Schema

Name	Required	Description
`plan`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the pre-regeneration workflow context; it says nothing about what the plan contains or how an absent plan is represented. A 3 reflects modest added value on top of the annotations.

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, zero filler, with the core action and default stated first and the usage rationale last. Every clause carries information.

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 an output schema, rich annotations, and a fully documented optional parameter, the definition covers what an agent needs to call it correctly. It could still say what a returned plan looks like or how an empty day behaves, but that is largely the output schema's job.

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 description coverage is 100% and the single 'date' parameter already documents the YYYY-MM-DD format, ISO datetime tolerance, and today default. The description merely repeats the default, adding no meaning beyond the schema, so the baseline of 3 applies.

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 ('Read the user's plan') with a scope qualifier ('for a given day', 'Defaults to today'). The resource name 'plan' implicitly separates it from siblings like view_task and view_lists, but the description never names or contrasts an actual sibling.

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?

Provides a concrete use condition: 'Useful before regenerating so an agent can see what is already in place.' That clearly situates it ahead of save_plan in a workflow. It stops short of explicit when-not guidance or naming alternatives such as search_tasks.

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

view_taskView taskA

Read-only

Inspect

Read one task, including its whole note — search_tasks truncates notes.

Name	Required	Description	Default
`id`	Yes	Task reference: TASKAID-45, #45 or 45.

Output Schema

Name	Required	Description
`id`	Yes
`url`	Yes
`list`	Yes
`name`	Yes
`note`	Yes
`when`	Yes	Calendar date, "YYYY-MM-DD", or null for Inbox.
`source`	Yes
`starred`	Yes
`duration`	Yes
`reminder`	Yes	Time of day on the `when` day, "HH:MM", or null for none.
`completed`	Yes
`updatedAt`	Yes
`completedAt`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real value by disclosing that the note is returned in full rather than truncated. It says nothing about behavior for a missing or invalid id, which is the remaining gap.

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?

A single sentence with the resource first and the differentiating detail second; no filler, and the most decision-relevant fact is not buried.

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 an output schema present and a fully documented single required parameter, the description covers what the agent needs to select and call it. Only the not-found/error behavior is left unspecified, a small omission for a simple read tool.

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 the id parameter already documents all accepted reference formats (TASKAID-45, #45, 45), so the description need not repeat them. It adds only the singular 'one task' framing, which is the baseline expectation.

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?

States a specific verb and resource ('Read one task') plus the scope of what is returned ('its whole note'), which distinguishes it from search_tasks and from the save_* siblings without needing to open 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 clause 'search_tasks truncates notes' tells the agent exactly when to prefer this tool over the sibling search tool. It gives no explicit exclusions or error conditions, but the selection cue is concrete.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesNov 3, 2026

Changedsave_list4 fields changed

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"
+]
```

Changedsave_plan2 fields changed

removedOutput schema / properties / title / anyOf

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

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

Changedsave_task18 fields changed

removedInput schema / properties / listId / anyOf

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

addedInput schema / properties / listId / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedInput schema / properties / note / anyOf

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

addedInput schema / properties / note / type

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

removedInput schema / properties / when / anyOf

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

addedInput schema / properties / when / type

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

removedOutput schema / properties / completedAt / anyOf

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

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

removedOutput schema / properties / duration / anyOf

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

addedOutput schema / properties / duration / type
```
Added value: +[
+  "number",
+  "null"
+]
```

removedOutput schema / properties / note / anyOf

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

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

removedOutput schema / properties / reminder / anyOf

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

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

removedOutput schema / properties / source / anyOf

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

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

removedOutput schema / properties / when / anyOf

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

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

Changedsearch_tasks12 fields changed
- removedOutput schema / properties / tasks / items / properties / completedAt / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / tasks / items / properties / completedAt / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / tasks / items / properties / duration / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / tasks / items / properties / duration / type
```
Added value: +[
+  "number",
+  "null"
+]
```
- removedOutput schema / properties / tasks / items / properties / note / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / tasks / items / properties / note / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / tasks / items / properties / reminder / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / tasks / items / properties / reminder / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / tasks / items / properties / source / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / tasks / items / properties / source / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / tasks / items / properties / when / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / tasks / items / properties / when / type
```
Added value: +[
+  "string",
+  "null"
+]
```
Changedview_lists2 fields changed
- removedOutput schema / properties / lists / items / properties / note / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / lists / items / properties / note / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Changedview_plan1 field changed

changedOutput schema / properties / plan / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "content": {
-        "type": "string"
-      },
-      "date": {
-        "description": "Calendar date, \"YYYY-MM-DD\".",
-        "type": "string"
-      },
-      "id": {
-        "type": "string"
-      },
-      "title": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "url": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "id",
-      "url",
-      "date",
-      "title",
-      "content"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "content": {
+        "type": "string"
+      },
+      "date": {
+        "description": "Calendar date, \"YYYY-MM-DD\".",
+        "type": "string"
+      },
+      "id": {
+        "type": "string"
+      },
+      "title": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "url",
+      "date",
+      "title",
+      "content"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

Changedview_task12 fields changed

removedOutput schema / properties / completedAt / anyOf

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

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

removedOutput schema / properties / duration / anyOf

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

addedOutput schema / properties / duration / type
```
Added value: +[
+  "number",
+  "null"
+]
```

removedOutput schema / properties / note / anyOf

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

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

removedOutput schema / properties / reminder / anyOf

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

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

removedOutput schema / properties / source / anyOf

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

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

removedOutput schema / properties / when / anyOf

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

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

3 tool updatesOct 29, 2026

Changedsave_task3 fields changed

addedInput schema / properties / reminder

Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^(?:[01]\\d|2[0-3]):[0-5]\\d$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "A time of day for a reminder, \"HH:MM\" in 24-hour time (e.g. \"15:00\"), on the task's `when` day in the user's time zone. Moving the task moves it; null removes it. At that time Taskaid sends the `task.reminded` event to subscribed assistants."
+}

addedOutput schema / properties / reminder

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Time of day on the `when` day, \"HH:MM\", or null for none."
+}

changedOutput schema / required

Previous value: -[
-  "id",
-  "url",
-  "name",
-  "completed",
-  "starred",
-  "when",
-  "note",
-  "duration",
-  "completedAt",
-  "updatedAt",
-  "source",
-  "list"
-]New value: +[
+  "id",
+  "url",
+  "name",
+  "completed",
+  "starred",
+  "when",
+  "reminder",
+  "note",
+  "duration",
+  "completedAt",
+  "updatedAt",
+  "source",
+  "list"
+]

Changedsearch_tasks2 fields changed

addedOutput schema / properties / tasks / items / properties / reminder

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Time of day on the `when` day, \"HH:MM\", or null for none."
+}

changedOutput schema / properties / tasks / items / required

Previous value: -[
-  "id",
-  "url",
-  "name",
-  "completed",
-  "starred",
-  "when",
-  "note",
-  "duration",
-  "completedAt",
-  "updatedAt",
-  "source",
-  "list"
-]New value: +[
+  "id",
+  "url",
+  "name",
+  "completed",
+  "starred",
+  "when",
+  "reminder",
+  "note",
+  "duration",
+  "completedAt",
+  "updatedAt",
+  "source",
+  "list"
+]

Changedview_task2 fields changed

addedOutput schema / properties / reminder

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Time of day on the `when` day, \"HH:MM\", or null for none."
+}

changedOutput schema / required

Previous value: -[
-  "id",
-  "url",
-  "name",
-  "completed",
-  "starred",
-  "when",
-  "note",
-  "duration",
-  "completedAt",
-  "updatedAt",
-  "source",
-  "list"
-]New value: +[
+  "id",
+  "url",
+  "name",
+  "completed",
+  "starred",
+  "when",
+  "reminder",
+  "note",
+  "duration",
+  "completedAt",
+  "updatedAt",
+  "source",
+  "list"
+]

2 tool updatesOct 14, 2026

Changedsave_list3 fields changed

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"
+]

Changedview_lists2 fields changed

addedOutput schema / properties / lists / items / properties / note

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

changedOutput schema / properties / lists / items / required

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

4 tool updatesOct 8, 2026
- Addedsave_plan
- Removedset_daily_plan
- Removedview_daily_plan
- Addedview_plan

1 tool updateSep 29, 2026

Changedsave_task1 field changed

changedInput schema / properties / name / description

Previous value: -"Required when creating. On update, omit to keep the current name."New value: +"Required when creating. On update, omit to keep the current name. A few words naming the action; the day goes in `when`, the detail in `note`."

1 tool updateSep 24, 2026

Changedsearch_tasks3 fields changed

changedInput schema / properties / completed / description

Previous value: -"Read finished tasks instead of active ones. Omit for active tasks."New value: +"Narrow to finished (true) or open (false) tasks. Omit for both."

changedInput schema / properties / when / properties / gte / description

Previous value: -"Inclusive lower bound. Omit it for overdue work."New value: +"Inclusive lower bound. Omit it to include every earlier day."

changedInput schema / properties / when / properties / lte / description

Previous value: -"Inclusive upper bound. \"P0D\" alone reads today and everything overdue."New value: +"Inclusive upper bound. With `completed: false`, \"P0D\" alone reads today and everything overdue."

2 tool updatesSep 16, 2026

Changedset_daily_plan3 fields changed

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"
+]

Changedview_daily_plan1 field changed

changedOutput schema / properties / plan / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "content": {
-        "type": "string"
-      },
-      "date": {
-        "description": "Calendar date, \"YYYY-MM-DD\".",
-        "type": "string"
-      },
-      "id": {
-        "type": "string"
-      },
-      "url": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "id",
-      "url",
-      "date",
-      "content"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "content": {
+        "type": "string"
+      },
+      "date": {
+        "description": "Calendar date, \"YYYY-MM-DD\".",
+        "type": "string"
+      },
+      "id": {
+        "type": "string"
+      },
+      "title": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "url",
+      "date",
+      "title",
+      "content"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

2 tool updatesSep 16, 2026

Changedset_daily_plan2 fields changed

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])))$"

Changedview_daily_plan1 field changed

changedOutput schema / properties / plan / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "content": {
-        "type": "string"
-      },
-      "date": {
-        "description": "Calendar date, \"YYYY-MM-DD\".",
-        "format": "date",
-        "pattern": "^(?:(?:\\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])))$",
-        "type": "string"
-      },
-      "id": {
-        "type": "string"
-      },
-      "url": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "id",
-      "url",
-      "date",
-      "content"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "content": {
+        "type": "string"
+      },
+      "date": {
+        "description": "Calendar date, \"YYYY-MM-DD\".",
+        "type": "string"
+      },
+      "id": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "url",
+      "date",
+      "content"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

1 tool updateSep 15, 2026

Changedsearch_tasks5 fields changed

addedInput schema / properties / cursor

Added value: +{
+  "description": "Continue from a previous response's nextCursor, with the same filters. Omit for the first page.",
+  "type": "string"
+}

addedInput schema / properties / when

Added value: +{
+  "description": "Narrow by scheduled day. Each bound is a day, \"2026-09-19\", or an ISO 8601 duration from today in the user's timezone: \"P0D\" is today, \"P1D\" tomorrow, \"-P1D\" yesterday, \"P2W\" two weeks out. Inbox tasks have no day and never match.",
+  "properties": {
+    "gte": {
+      "description": "Inclusive lower bound. Omit it for overdue work.",
+      "type": "string"
+    },
+    "lte": {
+      "description": "Inclusive upper bound. \"P0D\" alone reads today and everything overdue.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

removedOutput schema / properties / hasMore

Removed value: -{
-  "type": "boolean"
-}

addedOutput schema / properties / nextCursor

Added value: +{
+  "description": "Pass as cursor, with the same filters, to read the next page. Absent on the last page.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "tasks",
-  "hasMore"
-]New value: +[
+  "tasks"
+]

1 tool updateSep 11, 2026
- Changedsearch_tasks3 fields changed
  - addedInput schema / properties / limit / default
```
Added value: +50
```
  - changedInput schema / properties / limit / description
```
Previous value: -"Max results."New value: +"Max results. Defaults to 50, up to 100."
```
  - changedInput schema / properties / limit / maximum
```
Previous value: -9007199254740991New value: +100
```
2 tool updatesSep 11, 2026
- Addedsearch_tasks
- Removedview_tasks

2 tool updatesSep 7, 2026

Changedsave_list2 fields changed

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."

Changedsave_task2 fields changed

addedInput schema / properties / completed / description

Added value: +"Marks the task done. True stamps `completedAt` with the time of the call, never the time the work finished."

addedInput schema / properties / name / description

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

7 tool updatesSep 7, 2026
- First observedsave_list
- First observedsave_task
- First observedset_daily_plan
- First observedview_daily_plan
- First observedview_lists
- First observedview_task
- First observedview_tasks

Related MCP Connectors

DotpadA
ai.dotpad
Shared pads, chat and tasks for your team and their agents. Any agent can join.
Communication Project Management Workplace & Productivity
1
https://www.dotpad.ai/mcp
Masaro
ai.masaro
Task management for teams building with AI agents. Agents claim tasks and report progress.
Project Management Agent Orchestration
2
https://masaro.ai/api/mcp/mcp
AgentSiteA
io.github.figgy-ops
Task-first cross-agent collaboration for discussions, review, referrals, and reusable knowledge.
Knowledge & Memory Search
51
https://agentsite-live.vercel.app/mcp
mcp
com.faunakit
Your shared chats, calendar, Drive, groups and memory, so a team's agents stay in step.
Workplace & Productivity Communication Knowledge & Memory
1
https://mcp.faunakit.com/mcp

Related MCP Servers

Taskschmiede
Project Management Autonomous Agents Workplace & Productivity
QuestFinTech
A
license
Not graded
quality
C
maintenance
Taskschmiede is an agent-first work management system where humans and AI agents are equal participants. They can own tasks, create demands, collaborate in shared endeavours, and communicate through built-in messaging.
Updated 7 months ago (2026-03-25 13:24 UTC)
4
Apache 2.0
pith
Project Management Workplace & Productivity
SiluPanda
A
license
Not graded
quality
D
maintenance
MCP server for task management that enables AI agents to read, create, update tasks, and track work sessions, allowing agents and humans to collaborate on the same task board.
Updated 7 months ago (2026-03-24 11:33 UTC)
2 npm
11
MIT
Casefile
Developer Tools Knowledge & Memory Project Management
azimov777
A
license
A
quality
B
maintenance
Self-hosted task tracker and MCP server for AI coding agents. Append-only case files preserve decisions, failed attempts, questions, and check results across sessions. A live web board lets people track progress and answer agents. Runs locally in Docker and connects to Claude Code, Codex, Cursor, and other Streamable HTTP MCP clients. MIT licensed.
Updated a day ago (2026-11-06 02:13 UTC)
30
6
MIT
Archipelago
Project Management Knowledge & Memory
AlexReiner98
A
license
C
quality
A
maintenance
A living map of all your work: projects, tasks, decisions and what waits on whom, kept by you and your agents through the same tools, with every change logged.
Updated 3 days ago (2026-11-04 19:52 UTC)
10
7 npm
1
MIT

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?