Taskaid is built for you and your agents to get work done together.
Scored across 7 tools
Tools are mostly distinct: save_list/save_task handle writes, view_* handle reads, search_tasks is the query entry point. However, save_task and set_daily_plan both support 'patch' semantics, which could cause slight confusion about which to use when modifying content, though they operate on different entities.
All tool names follow a consistent 'verb_noun' pattern (save_, view_, search_, set_). The verbs are clear and uniform, and there are no mixed cases or inconsistent verb styles.
Seven tools is a reasonable, focused count for a personal task/planning domain. Each tool covers a distinct operation (CRUD for tasks and lists, plus daily plan read/write). It's not overly heavy, and every tool seems necessary.
The surface covers create/read/update for tasks and lists (no explicit delete, but upsert could potentially handle via nulls or omissions). There is no search for lists, no ability to list tasks without searching, nor a way to view multiple tasks at once. The daily plan has read/write but no separate history. Minor gaps but workable.
Upsert a list. Omit id to create a new one (name required). Pass id to rename or change the emoji on an existing list. 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. | |
| 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 | |
| emoji | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false and destructiveHint=true already signaling mutation, the description adds concrete behavioral context: the upsert semantics, the exact fields changed on update, and that it returns the saved list. It doesn't cover permission requirements, but annotations already carry the safety signal.
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?
Two tight sentences with no filler. The core behavior is front-loaded, followed by the create/update distinction and 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?
For a moderately simple upsert tool with fully documented parameters, a descriptive output schema, and annotations covering the destructive nature, the description supplies the missing operational semantics (how to choose create vs update). Nothing essential is missing.
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 applies. The description restates the conditional relationship between omitting id and requiring name, but this is already present in the parameter descriptions; it doesn't add new parameter-level meaning beyond the 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?
Description opens with the verb 'Upsert' and the resource 'list', then details the two modes: create without id and update with id (rename/change emoji). This clearly separates save_list from sibling tools like save_task and view_lists.
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 explicitly tells an agent when to create (omit id) versus update (pass id), which is the key routing decision. It doesn't name siblings like view_lists as alternatives for read-only access, so it stops short of full exclusion guidance.
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. | |
| 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, so the mutation risk is known. The description adds meaningful behavioral context beyond annotations: it explains the upsert semantics, patch atomicity ('applied in order and atomically — if one fails, nothing is written'), and the exact side effect of completing a task ('True stamps completedAt with the time of the call, never the time the work finished'). This enriches the agent's understanding well beyond the structured hints.
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?
Every sentence earns its place: the first sentence defines the operation, the next two give create and update rules, one covers patch, another covers unlink, and the final states the return. The key decision points are front-loaded before param details, and there is no filler or repetition of schema content.
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?
The description is complete enough for a 9-parameter mutation tool with an output schema. It covers create/update selection, patch semantics, unlink behavior, return value, and the completedAt nuance. Slight gap: it doesn't enumerate every field (matching row title).
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 89%, so the schema already documents nearly all parameters. The description adds value by clarifying the create/update logic for id and name, explaining that patch supersedes note for partial edits, and highlighting that listId null means unlink. It also consolidates the note-rendering detail into the flow of choosing note vs patch. Given the baseline of 3 for high coverage, the description's guidance on mode selection and patch semantics earns a 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?
The description opens with 'Upsert a task,' a specific verb plus resource that immediately distinguishes create from update behavior, and it names the key input that selects between the two modes ('Omit id... Pass id...'). The tool's purpose is completely clear and lets an agent distinguish it from sibling tools like save_list or view_task without needing to inspect schemas.
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 explicit when-to-use guidance for both main modes: create requires name and omitted id; update passes id and can take any subset of fields. It also gives precise routing for sub-behaviors: use patch instead of note for partial note edits, use null on listId to unlink. While it doesn't explicitly name sibling altornatives, the create/update mode distinction is effectively the tool's usage contract and leaves little ambiguous.
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 establish the read-only, non-destructive profile. The description adds behavioral context beyond that: a bare call returns tasks from every list, and text search is optional. This helps the agent predict the tool's default behavior without restating the full schema.
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 sentences, each earning its place: a clear verb-resource statement, a crucial scoping default, and a routing hint. No redundancy with the schema's detailed parameter descriptions.
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 all six parameters fully documented in the schema, an output schema present, and annotations covering safety, the description covers the remaining contextual needs: default behavior, optional text search, and how to obtain a list id. Nothing essential is missing.
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 the baseline is 3, but the description adds value by connecting listId to a concrete sibling operation ('Use view_lists to resolve a list to its id'). This is a meaningful cross-tool hint that the schema alone doesn't provide.
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?
Description opens with a specific verb and resource ('Search the user's tasks') and immediately clarifies scope: a bare call returns tasks from every list. It distinguishes itself from siblings like view_task and view_lists by framing search as a collection-level operation and by naming view_lists as the list-resolution tool.
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 a clear routing hint: 'Use view_lists to resolve a list to its id,' which tells the agent when to consult a sibling tool. It does not explicitly state when to prefer search_tasks over view_task, but the context is sufficient for a sensible selection.
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 flag destructiveHint=true, and the description consistently describes a write/edit operation. Beyond annotations, it discloses the mutual exclusivity of content and patch and clarifies that title can accompany either or stand alone — useful behavioral constraints not carried by the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences carry all essential information: the core action, the parameter usage modes, and a practical prerequisite. Every sentence earns its place and the main verb+resource is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with 100% schema coverage, an output schema, and annotations covering destructiveness, the description is complete. It covers all parameter relationships and adds the read-tasks-first context without needing to duplicate schema details or return-value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already documented. The description adds valuable cross-parameter semantics, especially the 'not both' rule for content/patch and the flexibility of title, which are not fully evident from individual schema property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Write or edit the user's plan for a day.' This clearly distinguishes it from siblings like view_daily_plan (read) and save_task/save_list (different resources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear internal guidance on when to use content vs. patch ('Send `content` for the whole plan or `patch` to change part of it, not both') and adds the precondition 'Read the user's tasks first for context.' It does not explicitly route to a sibling alternative, but none of the siblings write daily plans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
The annotations already declare readOnlyHint=true, destructiveHint=false, so the read-only nature is covered. The description adds the meaningful behavioral detail 'Defaults to today' and describes the scope as a single day, which is useful beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences earn their place, with the core action first and the practical usage context second. No filler or redundancy beyond what schema already contains.
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 simple tool with one optional parameter fully documented in the schema, annotations covering safety, and an output schema present, the description provides enough operational context with the 'before regenerating' hint. Nothing an agent needs is missing.
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?
The input schema already documents the only parameter completely with format, accepted datetime form, date-component behavior, and default. Since schema coverage is 100%, the description doesn't need to add much; it only confirms the default. Baseline 3 is appropriate.
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 ('read') and resource ('the user's plan for a given day'), which clearly distinguishes it from siblings like set_daily_plan (write) and view_lists/view_task (different resources). It is immediately obvious what the tool does without needing 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?
It gives explicit usage context with 'Useful before regenerating so an agent can see what is already in place.' This tells the agent when to invoke it. It doesn't explicitly list alternatives, but the sibling set_daily_plan implies the write counterpart, so the guidance is clear if not exhaustive.
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.
| 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 cover readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds the user-scoped nature of the lists, but no further behavioral details such as pagination or ordering. This is consistent with 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?
The description is a single, front-loaded sentence with no redundant wording. For a zero-parameter read tool, this is appropriately sized.
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 simple read-only tool with no parameters and an output schema, the description is largely complete. It could better clarify how 'lists' relate to sibling resources like tasks, but no critical invocation details are missing.
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?
The input schema has zero parameters, so there are no parameter semantics to document. Per the rubric, a zero-parameter tool receives a baseline of 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?
The description uses a specific verb ('Read') and a clear resource ('the user's lists'), and the resource name distinguishes it from siblings like view_tasks and view_daily_plan. The intent is immediately identifiable.
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?
There is no guidance on when to use this tool versus alternatives such as view_tasks or view_daily_plan. The description merely states what it does, leaving the agent to infer selection criteria.
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=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior context about note truncation relative to search_tasks, but says nothing about pagination, size limits, or error behavior on a bad id. Adequate given annotations carry the safety burden.
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 sentence with zero filler, front-loading the action and following with the differentiating constraint. Nothing redundant with the title 'View a task'.
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 one-parameter read tool with full schema coverage, complete annotations, and an output schema, the description supplies exactly the missing piece an agent needs: the truncation caveat that routes it away from search_tasks.
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 id parameter already documents the accepted reference formats (TASKAID-45, #45, 45). The description adds no parameter-level meaning 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') with an explicit scope qualifier ('including its whole note'), and immediately distinguishes itself from the sibling search_tasks. An agent can pick this over search_tasks without opening either 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?
It gives the selection condition implicitly but effectively: use this when you need the untruncated note, because search_tasks truncates. It stops short of naming other siblings (save_task, view_lists) or stating when-not to use it, so it is clear but not exhaustive.
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.
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.
One board for every AI you use: agents claim tasks and finish with proof you accept or return.
Add one secure layer between your agents and this server.
