Skip to main content
Glama
Sign In
Microsoft To Do MCP

Microsoft To Do MCP

by jordanburke
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

create-task

Creates a new task in a specific Microsoft To Do list with title, description, due date, status, and optional recurrence for repeating items.

Instructions

Create a new task in a specific Microsoft Todo list. A task is the main todo item that can have a title, description, due date, and other properties. Pass recurrence to make the task repeat (e.g. monthly bill payments, birthdays, weekly reviews).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "listId": "<listId>",
      "title": "<title>"
    },
    "name": "create-task"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoDescription or body content of the task
titleYesTitle of the task
listIdYesID of the task list
statusNoStatus of the task
categoriesNoCategories associated with the task
importanceNoTask importance
recurrenceNoRecurrence rule. Omit for a one-off task. Requires `dueDateTime` to be set (the recurrence derives its first occurrence from it).
dueDateTimeNoDue date in ISO format (e.g., 2023-12-31T23:59:59Z)
isReminderOnNoWhether to enable reminder for this task
startDateTimeNoStart date in ISO format (e.g., 2023-12-31T23:59:59Z)
reminderDateTimeNoReminder date and time in ISO format

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • addedInput schema / properties / recurrence
      Added value: +{
+  "additionalProperties": false,
+  "description": "Recurrence rule. Omit for a one-off task. Requires `dueDateTime` to be set (the recurrence derives its first occurrence from it).",
+  "properties": {
+    "pattern": {
+      "additionalProperties": false,
+      "properties": {
+        "dayOfMonth": {
+          "description": "Day of month for absoluteMonthly / absoluteYearly.",
+          "maximum": 31,
+          "minimum": 1,
+          "type": "integer"
+        },
+        "daysOfWeek": {
+          "description": "Days of week for weekly / relativeMonthly / relativeYearly.",
+          "items": {
+            "enum": [
+              "sunday",
+              "monday",
+              "tuesday",
+              "wednesday",
+              "thursday",
+              "friday",
+              "saturday"
+            ],
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "firstDayOfWeek": {
+          "description": "Which day is the start of the week (defaults to sunday).",
+          "enum": [
+            "sunday",
+            "monday",
+            "tuesday",
+            "wednesday",
+            "thursday",
+            "friday",
+            "saturday"
+          ],
+          "type": "string"
+        },
+        "index": {
+          "description": "Ordinal position for relativeMonthly / relativeYearly (e.g. 'second' Tuesday).",
+          "enum": [
+            "first",
+            "second",
+            "third",
+            "fourth",
+            "last"
+          ],
+          "type": "string"
+        },
+        "interval": {
+          "description": "How often the pattern repeats (1 = every period, 2 = every second, ...).",
+          "maximum": 255,
+          "minimum": 1,
+          "type": "integer"
+        },
+        "month": {
+          "description": "Month for absoluteYearly / relativeYearly (1-12).",
+          "maximum": 12,
+          "minimum": 1,
+          "type": "integer"
+        },
+        "type": {
+          "description": "Recurrence pattern type. daily | weekly | absoluteMonthly (e.g. 15th of every N months) | relativeMonthly (e.g. 2nd Tuesday of every N months) | absoluteYearly | relativeYearly.",
+          "enum": [
+            "daily",
+            "weekly",
+            "absoluteMonthly",
+            "relativeMonthly",
+            "absoluteYearly",
+            "relativeYearly"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "type",
+        "interval"
+      ],
+      "type": "object"
+    },
+    "range": {
+      "additionalProperties": false,
+      "properties": {
+        "endDate": {
+          "description": "Required when type=endDate; ISO date YYYY-MM-DD.",
+          "type": "string"
+        },
+        "numberOfOccurrences": {
+          "description": "Required when type=numbered; how many occurrences before stopping.",
+          "minimum": 1,
+          "type": "integer"
+        },
+        "recurrenceTimeZone": {
+          "description": "IANA timezone for the recurrence. In one live test Microsoft To Do stored 'Asia/Kolkata' as UTC, and it keeps only the due date's day, not its time.",
+          "type": "string"
+        },
+        "startDate": {
+          "description": "Required for endDate/numbered; ISO date YYYY-MM-DD. Defaults to the task due date if omitted.",
+          "type": "string"
+        },
+        "type": {
+          "description": "How long the recurrence repeats: endDate (stops at endDate), noEnd (forever), numbered (stops after N occurrences).",
+          "enum": [
+            "endDate",
+            "noEnd",
+            "numbered"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "type"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "pattern",
+    "range"
+  ],
+  "type": "object"
+}
  2. First observedv1.1.3

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose required permissions, side effects of creating a task, what happens if listId is invalid, whether duplicate tasks are allowed, or what the response contains. That is a significant gap for a mutation tool.

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?

The description is three sentences and front-loads the core action and scope. The definitional sentence about what a task is adds some value, though it is partly redundant with the schema.

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?

The rich input schema covers parameter semantics thoroughly, which compensates for the short description. But with no annotations and no output schema, the description should ideally mention the return value (e.g., the created task) or error behavior; those omissions leave gaps for an agent invoking a write operation.

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%, so the schema already documents all 11 parameters in detail, including the nested recurrence structure. The description adds only example use cases for recurrence and does not meaningfully extend parameter semantics 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 states a specific verb (Create), resource (task), and scope (in a specific Microsoft Todo list), and it distinguishes the tool from siblings like create-task-list and create-checklist-item. The added explanation of what a task is clarifies the resource further.

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

Usage Guidelines3/5

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

It gives concrete examples for when to use the recurrence parameter (monthly bills, birthdays, weekly reviews), which is helpful context. However, it does not explain when to choose this tool over siblings or mention prerequisites such as needing an existing listId or authentication.

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

Deploy Server

Other Tools