This server lets Claude (or any MCP client) read and manage your Microsoft To Do lists and tasks through the Microsoft Graph API.
List task lists: View all your To Do lists (e.g., Tasks, Groceries)
Create/rename/delete lists: Manage task lists, including permanent deletion
List tasks: View tasks in a list, optionally filtered by status (notStarted, inProgress, completed, etc.)
Get task details: Retrieve full information about a single task, including notes
Create tasks: Add tasks with title, notes, due date, and importance
Update tasks: Change title, notes, due date, importance, or status
Complete tasks: Mark tasks as completed with a dedicated shortcut
Delete tasks: Permanently remove individual tasks
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Microsoft To Do MCP Server List my tasks in the Groceries list."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that connects Claude (or any MCP-compatible client) to Microsoft To Do through the Microsoft Graph API — letting Claude read and manage your task lists and tasks on your behalf.
Runs entirely on your machine over stdio. No remote server ever sees your tasks or your tokens.
Tool | Description |
| List all your task lists (Tasks, Groceries, etc.) |
| Create a new task list |
| Rename an existing list |
| Delete a list and all its tasks (destructive) |
| List tasks in a list, optionally filtered by status |
| Get the details of a single task |
| Create a task (title, notes, due date, importance) |
| Update fields on an existing task |
| Mark a task as completed |
| Delete a task (destructive) |
Related MCP server: todo-mcp
Node.js 18 or newer
A Microsoft account (personal or work/school)
Claude Desktop or another MCP-compatible client
This server authenticates as your own Azure AD app registration, so you'll need to create one (free, takes a couple of minutes):
Go to the Azure Portal → App registrations and click New registration.
Give it a name (e.g. "Microsoft To Do MCP"), and under Supported account types choose an option that includes personal Microsoft accounts, unless you only intend to use a work/school account.
Under Redirect URI, select platform "Mobile and desktop applications" and add:
http://localhost:3000/callbackClick Register, then copy the Application (client) ID from the overview page — you'll need it later.
Go to Authentication and enable "Allow public client flows", then save.
Go to API permissions → Add a permission → Microsoft Graph → Delegated permissions, and add:
Tasks.ReadWrite
offline_access
User.Read
Clone this repository, then from the project folder:
git clone https://github.com/hoaaah/Microsoft-To-Do-MCP-Server.git
cd Microsoft-To-Do-MCP-Server
npm install
npm run buildThis compiles the TypeScript source into dist/index.js.
Open your AI Client / Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the following entry, replacing PATH_TO_THIS_FOLDER with the absolute path to where you cloned this repo, and MS_TODO_CLIENT_ID with the Application (client) ID from Azure:
{
"mcpServers": {
"microsoft-todo": {
"command": "node",
"args": ["PATH_TO_THIS_FOLDER/dist/index.js"],
"env": {
"MS_TODO_CLIENT_ID": "your-azure-client-id-here"
}
}
}
}Save the file and restart Claude Desktop.
The first time Claude calls one of the todo_* tools, your default browser will open automatically, asking you to sign in with your Microsoft account and approve the Tasks.ReadWrite permission. Once you approve, the token is cached locally at:
~/.microsoft-todo-mcp/token-cache.jsonSubsequent sign-ins are silent — the cached refresh token is reused automatically as long as it hasn't expired or been revoked, so you won't need to log in again.
To force a fresh sign-in, delete the cache file:
~/.microsoft-todo-mcp/token-cache.jsonTo fully revoke the app's access to your account, go to:
account.live.com/consent/Manage for personal Microsoft accounts
Azure AD → Enterprise Applications for work/school accounts
This server runs locally on your machine over stdio — there is no remote server storing or relaying your tokens.
todo_delete_task_list and todo_delete_task are destructive and cannot be undone. Claude will ask for confirmation before calling them.
Your Azure app's client ID is not a secret and is safe to keep in your local config, but you should not commit it to a public repository alongside real task data or tokens.
Browser doesn't open on first sign-in: make sure port 3000 is free, and that the redirect URI in your Azure app registration exactly matches http://localhost:3000/callback.
"Need admin approval" error: your organization may require an admin to consent to the requested permissions — contact your Microsoft 365 administrator, or use a personal Microsoft account instead.
Claude doesn't see the tools: double-check the path in claude_desktop_config.json points to the built dist/index.js, and that you restarted Claude Desktop after editing the config.
This MCP was created by and is maintained by Heru Arief Wijaya.
Mark a task as completed (shortcut for todo_update_task with status=completed).
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | The id of the list containing the task | |
| task_id | Yes | The id of the task to complete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only status (false), idempotency, and non-destructiveness. The description adds the equivalence to todo_update_task with status=completed, which is useful context but does not elaborate on other behavioral aspects such as permissions, edge cases, or response format.
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, concise sentence that front-loads the action and includes the key shortcut relationship without any redundant or filler 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?
For a simple tool with two well-described parameters and supporting annotations, the description is sufficiently complete. It clearly conveys the purpose and relationship to the alternative, leaving no critical gaps for typical use.
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 provides full descriptions for both parameters (list_id and task_id), so the description does not add additional parameter-level meaning. It relies on the schema's 100% coverage, which is adequate.
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 clearly states the specific action ('Mark a task as completed') and reinforces it by identifying the tool as a shortcut for todo_update_task with status=completed, which distinguishes it from the sibling update 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?
It explicitly names the alternative (todo_update_task) and specifies the exact condition under which this tool should be used (when only completing a task is needed), providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task in a given Microsoft To Do list. Get list_id from todo_list_task_lists first.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Optional plain-text notes/description for the task | |
| title | Yes | The task title | |
| list_id | Yes | The id of the list to add the task to | |
| due_date | No | Optional due date in YYYY-MM-DD format | |
| importance | No | Optional importance: low, normal, or high (default: normal) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering the write/mutation safety profile. The description adds the prerequisite of obtaining list_id, which is useful context. However, it does not elaborate on behavior like duplicate creation on repeated calls, but annotations already signal non-idempotency.
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 two sentences: the first states the core purpose, the second gives crucial prerequisite guidance. Every word earns its place; no fluff or redundancy.
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 low-complexity create tool with full param descriptions and useful annotations, the description covers the essential prerequisite. It doesn't mention return values, but with no output schema and a straightforward create operation, this is acceptable. The guidance is complete enough for an agent to invoke the tool 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 each parameter is already fully described. The description adds a pointer to obtain list_id from a sibling tool, which aids understanding but does not significantly enhance parameter semantics 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?
The description clearly states the action ('Create a new task') and the resource ('in a given Microsoft To Do list'). It distinguishes itself from sibling tool todo_create_task_list by specifying the task-level operation and references todo_list_task_lists for obtaining the list_id.
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 prerequisite guidance: 'Get list_id from todo_list_task_lists first.' This clearly indicates when to use this tool (after retrieving list IDs) and points to the relevant sibling. It lacks explicit when-not-to-use or alternative scenarios, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Microsoft To Do task list with the given display name. Returns the new list's id.
| Name | Required | Description | Default |
|---|---|---|---|
| display_name | Yes | Name for the new task list, e.g. 'Groceries' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the write/safe nature is known. The description adds the return value ('Returns the new list's id'), which is useful since no output schema exists. It doesn't mention side effects like duplicate handling, but these are not critical for a simple create operation.
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, no fluff. The first sentence states the primary action and resource; the second provides the key return detail. Efficient and well-structured.
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 one-parameter create tool with no output schema, the description fully covers the purpose, the parameter via the schema, and the return value. Annotations handle safety/behavioral flags, so 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 for the single parameter is 100%, with a clear description including an example ('e.g., Groceries'). The tool description only restates 'display name' without adding extra semantics, so it meets the baseline but does not elevate above it.
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 clearly states the action ('Create a new Microsoft To Do task list') and the specific resource ('task list'), distinguishing it from sibling todo_create_task which creates a task. It also mentions the return value, which helps the agent understand the tool's outcome.
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 clearly implies when to use this tool: when a new task list is needed. It does not explicitly name alternatives or exclusions, but the focus on 'task list' versus the sibling tools (e.g., 'create task', 'rename list') provides sufficient context for selection. Lacks explicit when-not guidance, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a task. This cannot be undone. Confirm with the user before calling this.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | The id of the list containing the task | |
| task_id | Yes | The id of the task to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior. The description adds valuable context beyond that: 'Permanently delete' and 'This cannot be undone' specify irreversibility, and 'Confirm with the user' adds an interaction requirement. This goes beyond what annotations convey.
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 two short sentences with no unnecessary words. It front-loads the primary action ('Permanently delete a task') and includes critical warnings without bloat.
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 two-parameter delete tool, the description is complete: it states the action, emphasizes permanence and irreversibility, and includes a user-confirmation requirement. Annotations cover the destructive hint, and no output schema exists, so no return value explanation is needed.
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 provides complete descriptions for both parameters (list_id and task_id) with 100% coverage. The tool description does not add any parameter-specific information, so the baseline of 3 is appropriate as the schema does the heavy lifting.
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 clearly states the tool's function: 'Permanently delete a task.' This uses a specific verb and resource, distinguishing it from sibling tools like completing a task or deleting a task list. The title reinforces the purpose.
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 provides clear context that this is a permanent deletion and instructs to confirm with the user before calling, which is a strong usage guideline. It does not explicitly name alternatives or exclusions, but the context is sufficient given the tool's name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a Microsoft To Do task list AND all tasks inside it. This cannot be undone. Confirm with the user before calling this.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | The id of the list to delete (from todo_list_task_lists) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the `destructiveHint` annotation, the description adds critical behavioral context: deletion is permanent and irreversible ('cannot be undone'), and it cascades to all tasks inside the list. It also includes a safety mandate to confirm with the user. This is relevant for mutation tools and goes far beyond the annotation's minimal 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 concise sentences deliver purpose, critical safety warnings, and cascade behavior without any filler. The most important information (permanence, irreversibility, user confirmation) is front-loaded, making it easy for an agent to parse quickly.
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 destructive tool with no output schema, the description is complete: it explains what is deleted, the irreversible nature, and the confirmation requirement. Given the simplicity of the operation and the presence of robust annotations, no further details (e.g., success response) are necessary.
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 single parameter `list_id` is fully described in the schema ('The id of the list to delete (from todo_list_task_lists)'), providing source hints and clear meaning. The tool description does not add further parameter detail, so the schema carries the burden; a baseline of 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 clearly states the action ('Permanently delete a Microsoft To Do task list AND all tasks inside it'), specifies the resource (task list), and highlights cascade deletion. The scope ('all tasks inside it') distinguishes it from sibling `todo_delete_task`, which deletes only a single task.
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 provides a clear usage constraint: 'Confirm with the user before calling this.' It implicitly tells the agent to get consent before invoking the tool. However, it does not explicitly mention alternatives (e.g., when to use `todo_delete_task` instead), so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a single task, including its notes.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | The id of the list containing the task | |
| task_id | Yes | The id of the task |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by stating that the response includes 'full details' and 'notes', providing information beyond the annotations but not deeply describing failure modes or exact response structure.
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, concise sentence that directly states the action and key content (notes). Every word earns its place, with no fluff or repetition of schema details.
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?
This is a simple read-only tool with two well-documented parameters and no output schema. The description adequately communicates the core purpose and what to expect ('full details'), but falls slightly short of fully describing return format or edge cases. Given the simplicity, it is nearly 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?
The input schema provides 100% coverage with clear descriptions for both list_id and task_id. The description adds no parameter-specific information, but since the schema is fully descriptive, the baseline of 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 uses a specific verb 'Get' and clearly identifies the resource as 'a single task' with emphasis on 'full details' and 'notes', which distinguishes it from sibling tools like todo_list_tasks that handle multiple tasks. The title reinforces the single-task scope, making the purpose unambiguous.
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 implies usage for retrieving a specific task's full details, and the sibling tool list indicates an alternative (todo_list_tasks) for getting multiple tasks. However, it does not explicitly state when to prefer this over list_tasks or mention any exclusions, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Microsoft To Do task lists for the signed-in user (e.g. 'Tasks', 'Groceries'). Returns each list's display name and id. Use the id with todo_list_tasks to see tasks inside a list.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, setting a safety baseline. The description adds valuable context: the scope is 'signed-in user' and it returns each list's display name and id. This goes beyond annotations in describing output format and scope.
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 two sentences, front-loaded with the action and resource, and provides examples and output fields. Every sentence earns its place, with no redundancy.
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 zero-parameter list tool, the description is complete: it names the user scope, return fields, and links to the sibling task-listing tool. With strong annotations and no output schema, the description provides all necessary context for selection and invocation.
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 tool takes zero parameters, so the empty schema fully covers the parameter space. The description does not need to add parameter detail; the 'signed-in user' context is the only relevant implicit parameter, which is mentioned.
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 clearly states the tool lists all Microsoft To Do task lists for the signed-in user, with specific verb and resource. It distinguishes itself from sibling tools like todo_list_tasks by explicitly focusing on lists, and provides examples ('Tasks', 'Groceries').
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 clear context on how to use the returned id with todo_list_tasks to see tasks inside a list, which guides the user to the appropriate follow-up tool. However, it does not explicitly state when not to use this tool or mention alternative list-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks inside a given Microsoft To Do list. Supports filtering by status. Get list_id from todo_list_task_lists first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tasks to return (default 50) | |
| list_id | Yes | The id of the list to read from | |
| status_filter | No | Only return tasks with this status, or 'all' for every task (default: all) | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false. The description adds no behavioral context beyond what the schema and annotations provide. It does not disclose pagination behavior, ordering, or response format; the only extra is the dependency note, which is not a behavioral trait.
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 sentences with no redundancy. The first sentence states the primary action, and the second adds a key prerequisite and capability. Fully front-loaded and efficient.
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 list tool with a fully documented schema and helpful annotations, the description covers the essential purpose and prerequisite. It doesn't explain return format or pagination, but given the simplicity and annotation hints, this is acceptable.
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 baseline is 3. The description adds value by explaining that list_id should be obtained from todo_list_task_lists and mentions status filtering, which reinforces the status_filter parameter. This slight extra guidance justifies 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 states 'List tasks inside a given Microsoft To Do list' with a specific verb and resource, and distinguishes it from siblings like todo_list_task_lists (which lists lists) and todo_get_task (which gets a single task). The intent is unambiguous.
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 provides clear context by instructing the user to get list_id from todo_list_task_lists first, which implies when to use this tool (after you have the list_id). However, it does not explicitly state when not to use it or mention alternatives, so it stops short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename an existing Microsoft To Do task list.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | The id of the list to rename (from todo_list_task_lists) | |
| display_name | Yes | The new list name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral context such as side effects, prerequisites, or return value. It only restates the action without enriching the agent's understanding beyond 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?
The description is a single, concise sentence that clearly states the action. No unnecessary words or repetition, achieving maximum economy.
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 2-parameter rename operation with full schema coverage and safety annotations, the description is adequate. It lacks explicit return-value info, but no output schema exists, and the operation's simplicity makes this acceptable.
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 descriptions cover both parameters (list_id and display_name) fully (100% coverage). The description itself adds no parameter-level detail, but the schema already provides sufficient meaning, so a baseline of 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 uses the specific verb 'rename' and clearly identifies the resource ('Microsoft To Do task list'). This distinguishes it from sibling tools like create, delete, and list operations.
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 explicitly states 'existing task list,' implying the tool is for modifying an already-created list, not creating a new one. While it doesn't name alternatives, the operation is distinct and straightforward, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update fields on an existing task (title, notes, due date, importance, or status). Only the fields you provide are changed. To mark a task done, prefer todo_complete_task.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | New plain-text notes | |
| title | No | New title | |
| status | No | New status | |
| list_id | Yes | The id of the list containing the task | |
| task_id | Yes | The id of the task to update | |
| due_date | No | New due date in YYYY-MM-DD format | |
| importance | No | New importance level |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The critical statement 'Only the fields you provide are changed' discloses partial-update semantics, which is valuable beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false). It does not mention error conditions, but the key behavioral trait is covered.
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 sentences convey the purpose, scope, partial update behavior, and an alternative. Front-loaded with the verb and resource, with no filler or redundant information.
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 tool with 7 parameters and no output schema, the description is complete enough: it states what fields can be updated, that it's a partial update, and when to use a different tool. The absence of an output schema is not a gap for a mutation tool.
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 provides 100% parameter coverage with descriptions for every field (title, notes, due_date, importance, status, list_id, task_id). The description merely lists the same fields without adding extra semantic detail, so it adds no value 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?
The description uses the specific verb 'Update' and identifies the resource as 'an existing task', then enumerates the exact fields that can be modified. This clearly distinguishes it from sibling tools like todo_complete_task, which is explicitly mentioned as an alternative.
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 an explicit alternative: 'To mark a task done, prefer todo_complete_task.' This gives a clear when-not scenario and points to the correct sibling, satisfying the requirement for alternatives.
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. Dates show when Glama detected each change.
v1.0.0todo_complete_tasktodo_create_tasktodo_create_task_listtodo_delete_tasktodo_delete_task_listtodo_get_tasktodo_list_task_liststodo_list_taskstodo_rename_task_listtodo_update_taskEach tool targets a distinct resource and action: task lists vs. tasks, and operations like list, create, rename, delete, get, update, complete are clearly separated. The only potential overlap is todo_complete_task being a shortcut for todo_update_task, but the description explicitly clarifies this.
All tool names follow a consistent todo_verb_noun pattern, with verbs like list, create, rename, delete, get, update, complete applied uniformly to the two resources (task lists and tasks). This makes the API predictable and easy to navigate.
10 tools is well-scoped for a Microsoft To Do server, covering both task list management and task management without unnecessary bloat. Each tool serves a clear, distinct purpose and earns its place.
The server provides full CRUD coverage for task lists (list, create, rename, delete) and tasks (list, get, create, update, complete, delete), covering the core lifecycle. The complete_task shortcut is a sensible addition for a common operation.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hoaaah/Microsoft-To-Do-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
