Microsoft To Do MCP Server

by hoaaah

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.2/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Microsoft-To-Do-MCP-Server MCP server](https://glama.ai/mcp/servers/hoaaah/Microsoft-To-Do-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/hoaaah/Microsoft-To-Do-MCP-Server)

Score Badge

Copy to your README.md:

[![Microsoft-To-Do-MCP-Server MCP server](https://glama.ai/mcp/servers/hoaaah/Microsoft-To-Do-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/hoaaah/Microsoft-To-Do-MCP-Server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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