Taskaid is built for you and your agents to get work done together.
Scored across 7 tools
Each tool targets a distinct resource+action: save_* upsert lists/plans/tasks, view_* read them, and search_tasks is a query. The only potential overlap (search_tasks vs view_task) is explicitly resolved in the descriptions, noting that search truncates notes while view_task returns the full note.
Every tool follows a clean verb_noun snake_case pattern (save_list, save_plan, save_task, search_tasks, view_lists, view_plan, view_task). No mixed conventions or vague verbs.
Seven tools is well-scoped for a personal task/list/plan manager, with a balanced read/write surface where each tool earns its place. No redundant or filler tools.
Create, read, and update are covered via the upsert save_* tools and view_*/search, but there is no delete operation for tasks, lists, or plans anywhere in the surface. This is a notable lifecycle gap that would block agents from removing stale items.
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 | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| note | Yes | |
| emoji | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, so the agent knows updates can overwrite. The description notes that note is replaced entirely and emoji/name can be kept, which adds context beyond annotations. It doesn't mention permissions, reversibility, or rate limits, but covers the mutation semantics reasonably.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: verb+resource first, then create/update conditions, then return value. Every sentence earns its place and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description doesn't need to explain returns. It covers create/update logic well, but for a destructive mutation it could mention what happens to unspecified fields (though the schema covers it). Overall, adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter meanings are fully documented in the schema. The description reinforces the id semantics and the note replacement behavior, adding some value, but doesn't exceed what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (upsert) and resource (list), and distinguishes create from update by the presence of id. An agent can tell it apart from the sibling save_plan, save_task, and view_list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly explains the create vs. update conditions ('Omit id to create... Pass id to rename...'), but it doesn't explicitly say when to use this tool versus the sibling save_task or save_plan, which might be confusing for an agent. Still, the create/update guidance is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Default |
|---|---|---|---|
| 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`. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| date | Yes | Calendar date, "YYYY-MM-DD". |
| title | Yes | |
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this overwrites user data. The description adds the content/patch exclusivity and the read-tasks-first workflow cue, but does not itself say that a full content send is irreversible or what happens to prior plan text. With the safety profile carried by annotations, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each doing distinct work — purpose, parameter interaction rule, then prerequisite — with the primary verb and resource front-loaded. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 explained, and annotations cover the destructive/read-only profile. Combined with the mutual-exclusion rule and the read-tasks-first precondition, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description earns an extra point by stating a cross-parameter constraint the schema never encodes: content and patch are mutually exclusive, and title composes with either. Omission of the date parameter costs nothing since the schema documents it fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb pair (write/edit) and a specific resource (the user's daily plan), plus the three operative modes (whole-content, patch, title-only rename). It is trivially distinguishable from view_plan (read) and from save_task/save_list (different resources) without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit selection rules: content XOR patch ('not both'), title usable with either or alone, and a prerequisite ('Read the user's tasks first for context'). Nothing about how to choose between the write paths is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Default |
|---|---|---|---|
| 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. | |
| completed | No | Marks the task done. True stamps `completedAt` with the time of the call, never the time the work finished. |
| 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 | |
| completed | Yes | |
| updatedAt | Yes | |
| completedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds the upsert semantics, the null-unlink behavior for listId, and that patch is atomic ('if one fails, nothing is written' is in schema, but description states 'Returns the saved task'). It could say more about what destructive means here (e.g. overwrite vs append), but it covers the key mutation traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short sentences, front-loaded with the upsert core and then the notable edge cases (patch, null listId, return value). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and 89% schema coverage, the description needn't explain returns or every param. It is complete enough for a 9-param upsert tool, though it could note that `name` is required on create (it does) and clarify destructive scope slightly more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 89%, so the schema carries most parameter detail. The description still adds meaning: null-on-listId unlinking, patch-instead-of-note, and id-omit-creates. It doesn't re-explain every field, which is appropriate given the rich schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Upsert a task') and immediately distinguishes create vs update via the `id` parameter, which separates it from sibling `search_tasks`/`view_task` reads and from `save_list`/`save_plan`. The agent can identify exactly what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear create-vs-update routing ('Omit id to create', 'Pass id to update') and a specific sub-case ('To change part of the note, pass patch instead of note'). It does not explicitly name sibling tools as alternatives, but the when-to-use for create vs update is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| tasks | Yes | |
| nextCursor | No | Pass as cursor, with the same filters, to read the next page. Absent on the last page. |
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. The description adds that filtering is optional and that results span every list, but says nothing about pagination behavior or result ordering. That is a modest but real addition 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each front-loading the most important fact: what it searches, the default scope, and how to filter by list. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations carrying the safety profile and an output schema present, return values need not be explained. The description covers default scope and the one cross-tool dependency (view_lists for listId), leaving only pagination/ordering behavior unstated, which the cursor field already implies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in detail (duration syntax, word-AND matching, limit bounds, cursor usage). The description reinforces only the omission semantics of listId and query, adding little beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 immediately defines the default scope ('a bare call returns tasks from every list'). The cross-reference to view_lists clarifies how it relates to a sibling tool rather than duplicating it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: text search is optional, a filterless call spans all lists, and listId must be resolved via view_lists. It lacks an explicit when-not-to-use statement (e.g. use view_task for a single known task), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the user's lists and their notes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| lists | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that notes are included, which is slight extra context, but it says nothing about authentication, scope, pagination, or refresh behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no wasted words, front-loaded with the action and resource. It is appropriately sized for a simple read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool with an output schema and safety annotations, the description is nearly sufficient: it says what is read. The one missing piece is explicit routing versus sibling view/search tools, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero input parameters, so parameter semantics carry no additional descriptive burden. The baseline score for a no-parameter tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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), making it clearly distinct from save_list and from view_task/view_plan by resource. It does not explicitly contrast with siblings, but the resource boundary is clear enough for an agent to select it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, prerequisites, or alternatives. It does not say when to choose view_lists over view_task, view_plan, or search_tasks, leaving routing entirely to inference from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
| Name | Required | Description |
|---|---|---|
| plan | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds only the 'today' default and the pre-regeneration rationale; it says nothing about scope of the plan, whether an empty day returns nothing, or freshness of the data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the core action front-loaded, then default, then purpose. No filler and nothing that needs to be hunted for.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape need not be explained, and the only parameter is fully documented in the schema. For a simple read-only tool this is nearly complete; only the behavior on days with no plan is unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 is fully documented there, including the YYYY-MM-DD format, the ISO-datetime tolerance and the today default. The description only restates the default, adding no new format or edge-case detail 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.
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 defined scope ('for a given day'). It implicitly distinguishes itself from write siblings like save_plan, but never explicitly contrasts with view_task or view_lists, which also read and could plausibly surface plan data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete usage context: call it before regenerating to see what is already in place. That is a clear situational cue, though it names no alternative tool or exclusion condition (e.g. that this is read-only and save_plan is the mutation counterpart).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one task, including its whole note — search_tasks truncates notes.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task reference: TASKAID-45, #45 or 45. |
| 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 | |
| completed | Yes | |
| updatedAt | Yes | |
| completedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description still adds behavioural value by disclosing the completeness of the returned note relative to search_tasks; it omits error behaviour for a bad id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero waste, with the core capability front-loaded and the differentiator in a trailing clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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; the description covers what is fetched, how complete it is, and when to prefer it over the search sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema itself documents the accepted id formats (TASKAID-45, #45, 45). The description adds nothing beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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') and adds scope ('including its whole note'), which distinguishes it from the sibling search_tasks. An agent can pick it apart from the other view_* and search_tasks tools 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative (search_tasks) and the condition that selects this tool over it (truncated notes). No when-not condition or prerequisite is stated, but the routing guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
save_list3 fields changedInput schema / properties / noteAdded 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."
+}Output schema / properties / noteAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "id",
- "emoji",
- "name"
-]New value: +[
+ "id",
+ "emoji",
+ "name",
+ "note"
+]view_lists2 fields changedOutput schema / properties / lists / items / properties / noteAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / lists / items / requiredPrevious value: -[
- "id",
- "emoji",
- "name"
-]New value: +[
+ "id",
+ "emoji",
+ "name",
+ "note"
+]save_planset_daily_planview_daily_planview_plansave_task1 field changedInput schema / properties / name / descriptionPrevious 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`."search_tasks3 fields changedInput schema / properties / completed / descriptionPrevious 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."Input schema / properties / when / properties / gte / descriptionPrevious value: -"Inclusive lower bound. Omit it for overdue work."New value: +"Inclusive lower bound. Omit it to include every earlier day."Input schema / properties / when / properties / lte / descriptionPrevious 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."set_daily_plan3 fields changedInput schema / properties / titleAdded 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."
+}Output schema / properties / titleAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "id",
- "url",
- "date",
- "content"
-]New value: +[
+ "id",
+ "url",
+ "date",
+ "title",
+ "content"
+]view_daily_plan1 field changedOutput schema / properties / plan / anyOfPrevious 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"
+ }
+]set_daily_plan2 fields changedOutput schema / properties / date / formatRemoved value: -"date"Output schema / properties / date / patternRemoved 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])))$"view_daily_plan1 field changedOutput schema / properties / plan / anyOfPrevious 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"
+ }
+]search_tasks5 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "Continue from a previous response's nextCursor, with the same filters. Omit for the first page.",
+ "type": "string"
+}Input schema / properties / whenAdded 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"
+}Output schema / properties / hasMoreRemoved value: -{
- "type": "boolean"
-}Output schema / properties / nextCursorAdded value: +{
+ "description": "Pass as cursor, with the same filters, to read the next page. Absent on the last page.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "tasks",
- "hasMore"
-]New value: +[
+ "tasks"
+]search_tasks3 fields changedInput schema / properties / limit / defaultAdded value: +50Input schema / properties / limit / descriptionPrevious value: -"Max results."New value: +"Max results. Defaults to 50, up to 100."Input schema / properties / limit / maximumPrevious value: -9007199254740991New value: +100search_tasksview_taskssave_list2 fields changedInput schema / properties / emoji / descriptionAdded value: +"A single emoji shown before the list name. Defaults to 📋 when creating; omit on update to keep the current one."Input schema / properties / name / descriptionAdded value: +"Required when creating. On update, omit to keep the current name."save_task2 fields changedInput schema / properties / completed / descriptionAdded value: +"Marks the task done. True stamps `completedAt` with the time of the call, never the time the work finished."Input schema / properties / name / descriptionAdded value: +"Required when creating. On update, omit to keep the current name."save_listsave_taskset_daily_planview_daily_planview_listsview_taskview_tasksTask management for teams building with AI agents. Agents claim tasks and report progress.
Task-first cross-agent collaboration for discussions, review, referrals, and reusable knowledge.
Agent-native task management: your AI agent is the interface. Delegate to anyone by email.
Task boards for teams and their AI agents: cards, checklists, sprints, plans and proposals.
Add one secure layer between your agents and this server.
