Microsoft To Do MCP

Server Quality Checklist

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

Latest release: v1.1.3
Disambiguation3/5
There is overlap between get-task-lists and get-task-lists-organized, which both retrieve task lists but with different presentation formats. Other tools are distinct, but test-graph-api-exploration is vague and could be confused with exploration tasks. Overall, most tools are clearly delineated, but the near-duplicate pair creates ambiguity.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (get-, create-, update-, delete-). Minor deviations include 'auth-status' (noun-like) and 'test-graph-api-exploration' (unusual object phrase), but these are slight and the majority are consistent. The pattern is mostly predictable.
Tool Count3/5
With 16 tools, the server sits at the borderline of what feels heavy for a Todo-focused MCP. It includes CRUD for lists, tasks, and checklist items, but also a redundant list retrieval and an exploratory tool, pushing the count slightly high. Still, the core coverage justifies the number.
Completeness4/5
The server provides full CRUD for task lists, tasks, and checklist items, which covers the main domain operations. Minor gaps include no singular 'get-task' or 'get-checklist-item' tools and no arbitrary task-moving operation, but these can be worked around with existing tools. Archiving and auth status round out the surface.
Average 3.8/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This server has been verified by its author.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must explain behavioral traits, but it only says 'allows changing any properties' without covering partial vs full update, error handling, required resources, or permissions. The phrase 'any properties' is also misleading because the schema restricts updatable fields.
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 two short sentences with key information front-loaded. It is concise, though the second sentence is somewhat generic and could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no annotations, and no output schema, the description is insufficient. It fails to explain partial update semantics, the necessity of listId/taskId, error conditions, or what a successful update returns.
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 fully documents all 11 parameters. The description adds marginal value by naming a few examples ('title, due date, importance') but does not provide additional semantics beyond what the schema already contains.
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 ('Update') and resource ('existing task in Microsoft Todo'), clearly distinguishing it from sibling tools like create-task and delete-task. It also mentions scope (Microsoft Todo), making the tool's 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 phrase 'Update an existing task' implies use when modifying an existing task rather than creating or deleting one, but it does not explicitly state when to prefer this tool over alternatives. No exclusions or alternative tool names are provided.
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?
With no annotations, the description must disclose behavior. It omits critical details such as that checklist items are not returned and require a separate call, and it does not mention pagination defaults, filtering behavior, or response format. The statement about containing subtasks could mislead an agent into thinking subtasks are included.
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, front-loaded with the core purpose. The second sentence adds useful context about subtasks without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description is under-specified. It fails to explain how top/skip/filter/orderby relate to use cases, the separation of checklist items, or what a response looks like. The description leaves the agent with significant gaps in understanding the tool's full behavior.
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 baseline is 3. The description adds no additional parameter meaning beyond the schema; 'specific Microsoft Todo list' only restates listId's purpose without enhancing 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 ('Get tasks') and the resource ('from a specific Microsoft Todo list'), distinguishing it from sibling tools like get-task-lists (lists) and get-checklist-items (subtasks). The additional phrase 'main todo items' reinforces the hierarchy.
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 top-level tasks rather than subtasks, but does not explicitly name alternatives or provide exclusions. It offers clear context about the task type but leaves the when-to-use guidance 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?
No annotations are provided, and the description does not disclose behavioral traits such as required permissions, side effects, idempotency, or return values. It only states the action and purpose, leaving the full burden on the description for a write 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?
The description is two concise sentences. The first states the action clearly, and the second adds useful context about the tool's purpose. There is no unnecessary wording, and it is front-loaded with the main verb and resource.
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?
Given that there is no output schema and no annotations, the description is adequate for a simple create operation but lacks additional context such as return value or prerequisites. The schema covers all parameters, so the main gap is behavioral context.
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 has 100% description coverage for all four parameters, so the baseline is 3. The description adds no additional parameter-specific meaning beyond what the schema already states; it merely reiterates the overall action.
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 'Create' and clearly identifies the resource as 'a new checklist item (subtask) for a task.' It further explains the purpose ('break down a task into smaller, manageable steps'), which distinguishes it from siblings like create-task and create-task-list.
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 provides only implied usage: 'Help break down a task into smaller, manageable steps' suggests when to use it, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention that this is a mutating action, whether any permissions are needed, what happens on success (e.g., return value), or any potential side effects. The description mainly restates the obvious 'create' operation without deeper behavioral context.
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, front-loaded with the action and resource. Every word adds value, and there is no redundant or filler content. It is appropriately concise.
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?
Given 10 parameters and no output schema, the description is a bit thin. It does not explain the return value or mention that listId and title are required (though the schema handles that). It also lacks any guidance on error scenarios or authentication. However, the schema covers parameter details, and the core purpose is clear, making it minimally viable.
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 all parameters are already documented. The description mentions 'title, description, due date, and other properties,' which provides a high-level overview but adds little beyond the schema. Baseline 3 is appropriate since 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 creates a new task in a specific Microsoft Todo list. The verb 'Create' plus the resource 'task' and scope 'specific Microsoft Todo list' make the purpose unambiguous. It is clearly distinguished from sibling tools like 'create-task-list' (creates a list) and 'update-task' (modifies an existing task).
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: one needs a list ID and wants to add a todo item. However, it does not explicitly specify when to use this over alternatives, nor does it mention any prerequisites or exclusion criteria. The context is somewhat implied rather than stated.
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?
With no annotations provided, the description must carry the burden of behavioral disclosure. It only says 'Update the name' without mentioning permissions, side effects, or behavior when the list does not exist. This is minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the verb and resource, and contains no filler. It is highly concise while conveying the essential action.
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 tool has only two required parameters and no output schema, so its simplicity lowers the need for extensive context. However, the description could mention expected outcome or error handling, though the existing reference to 'existing task list' provides some prerequisite context.
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 descriptions for both listId and displayName, achieving 100% coverage. The description adds no additional meaning beyond the schema field names, so the baseline score 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 ('Update the name') and the specific resource ('an existing task list'), with the qualifier 'top-level container' distinguishing it from task-level operations. It is specific and differentiates well from siblings like update-task.
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 phrase 'existing task list' implies this is for renaming an already-created list, and 'top-level container' clarifies scope, but there is no explicit guidance on when to use this tool over alternatives or exclusions. The intended use is reasonably clear but not formally contrasted with siblings.
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?
No annotations are provided, so the description carries full burden. It mentions 'testing queries' but does not disclose potential side effects (e.g., whether it makes read-only requests, requires special permissions, or could alter state), nor what the output looks like. This is a significant gap for an exploratory tool.
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, well-structured sentence that front-loads the action and purpose. It contains no filler or redundant information, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is exploratory with a single enum parameter and no output schema or annotations. The description explains the goal but lacks practical guidance on how to use the test types, what results to expect, or any safety/behavioral warnings, making it incomplete for an agent to invoke effectively.
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 is 100% with a description for testType, so the baseline is 3. The description does not add any meaning beyond the schema, and the schema's description ('Type of test to run') is minimal, but the enum values are present. No improvement provided by tool description.
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 ('Test') and resource ('Graph API queries'), and clearly states the goal of discovering hidden properties or endpoints for folder/group organization. This distinguishes it from sibling CRUD tools, which perform standard 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 provides clear context: use this tool for exploratory discovery of hidden Graph API capabilities. It does not explicitly mention when not to use it or name alternatives, but the purpose is sufficiently distinct from siblings, so the usage is implied.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It does clarify the deletion scope (only the subtask), which is useful, but it fails to mention that deletion is permanent, what happens to the parent task, or any required permissions. This leaves important behavioral aspects undisclosed.
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, front-loaded with the action and resource. Every word contributes value—the first sentence states the core function, and the second clarifies the precise scope. There is no fluff or repetition.
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?
Given the simplicity of the operation (delete a single checklist item) and full schema coverage, the description covers the essential purpose and scope. However, since no output schema is provided, it does not explain the expected response or side effects, leaving the agent to infer behavior. A brief note on success/failure or irreversibility would improve completeness.
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 descriptions for all three parameters, achieving 100% coverage. The tool description does not add any additional parameter-level meaning beyond the schema, so a baseline score 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 ('Delete') and names the exact resource ('checklist item (subtask)'), clearly distinguishing it from sibling tools like delete-task and delete-task-list. The added clarification that it only removes the subtask, not the parent task, further disambiguates its scope.
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 provides clear context by stating what is deleted and the scope caveat ('not the parent task'), which implicitly guides the user. However, it does not explicitly mention when to use this tool versus alternatives like update-checklist-item, nor does it state when not to use it.
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?
No annotations are provided, so the description carries the full burden of explaining behavioral traits. It states what can be changed but omits key details for a write operation: whether it does a partial update or full replacement, authorization needs, idempotency, or what the response contains. This ambiguity leaves significant operational unknowns.
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, efficient sentence that immediately identifies the action and resource. It has no wasted words and is well-structured.
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 schema covers all parameters, but the description lacks information about the tool's operational behavior for a write operation (e.g., partial updates, response, prerequisites). Given no output schema and no annotations, the description is adequate for basic understanding but leaves important context gaps.
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 baseline is 3. The description adds a modest semantic layer by grouping parameters into 'text content' (displayName) and 'completion status' (isChecked), which helps conceptual mapping but doesn't add meaning beyond the schema's existing descriptions.
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 a specific verb ('Update'), resource ('checklist item (subtask)'), and scope ('changing the text content or completion status'). It distinguishes itself from sibling tools like create-checklist-item and delete-checklist-item by specifying it targets existing items.
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 implies when to use the tool via 'existing' (not for creating) and 'update' (not for deleting), and the fields it mentions give clear use cases. However, it doesn't explicitly compare with alternatives or state when not to use it, so it's clear but not fully explicit.
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?
With no annotations, the description carries the full burden of indicating safety. The verb 'Get' clearly implies a read-only operation, and the description further discloses what the return will contain (list names, IDs, default/shared status). It does not mention edge cases or limitations, but for a simple read tool this is sufficient.
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 long, front-loaded with the core action, and every word adds value. There is no repetition or unnecessary detail.
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 no parameters, no annotations, and no output schema, this description adequately covers what the tool does and what it returns. It is complete for the tool's simplicity, though it could mention the alternative organized view.
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 has zero parameters and the schema is empty, so the baseline is 4. The description does not need to explain any parameter semantics, and it correctly focuses on output rather than input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 a clear resource 'all Microsoft Todo task lists', clarifying its scope as top-level containers. However, it does not differentiate itself from the sibling tool get-task-lists-organized, which likely serves a similar or overlapping purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like get-task-lists-organized. The description simply states what it does, with no context about selection criteria, exclusions, or prerequisites.
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?
The description discloses the core behavior (moving completed tasks) and the 'preserving historical tasks' trait, but with no annotations, it does not cover side effects like whether the move is reversible, permissions required, or failure behavior. The description carries the full burden and only partially satisfies it.
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 front-load the action and purpose with no unnecessary detail. Every word earns its place, and the structure efficiently communicates the tool's function.
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 description covers the main action and use case, but the absence of an output schema and annotations means it does not explain return behavior or edge cases, leaving some context gaps. For a mutation tool with no output schema, a bit more detail on expected results would improve completeness.
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 all four parameters with clear definitions (e.g., olderThanDays default 90), so the description's mention of 'specified number of days' adds little beyond the schema. The schema already provides parameter-level semantics effectively.
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 moves completed tasks older than a specified number of days from a source list to a target archive list, distinguishing it from siblings like delete-task (which removes tasks) or update-task (which changes task fields). The verb 'Move' and resource 'completed tasks' are specific and 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 phrase 'Useful for cleaning up active lists while preserving historical tasks' provides clear context for when to use this tool, implying a maintenance/cleanup scenario. It does not explicitly describe when not to use it or name alternatives, but the context is clear enough for typical use.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does clarify that this creates a top-level container (not a nested one), which is a useful behavioral detail, and the create operation's mutating nature is evident. However, it does not disclose potential side effects, permissions required, or behavior on duplicate names, though the simplicity of the tool mitigates this gap.
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 one concise sentence, front-loaded with the action and resource. Every phrase contributes meaning, with no redundant or extraneous words. The structure is clean and easily parseable.
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?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is largely complete. It covers what the tool does and hints at the purpose. It does not explain return values, but since no output schema exists, that is not necessary. Minor omissions like error handling or authentication do not detract significantly for this straightforward create operation.
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 input schema already describes displayName with 'Name of the new task list' (100% coverage). The tool description adds semantic context by suggesting the name should reflect a 'category or project', which guides the agent on what value to provide for the parameter. This goes beyond the schema's minimal definition.
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') and the specific resource ('a new task list (top-level container)') within Microsoft Todo. It also conveys the purpose ('organize your tasks into categories or projects') and 'top-level container' distinguishes it from creating tasks or subtasks, making it distinct from siblings like create-task.
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 when to use this tool (when you need to create a top-level container for tasks) but does not explicitly contrast it with alternatives like create-task or update-task-list. The phrase 'top-level container' hints at the distinction, but there is no direct guidance on when not to use it or when to prefer a sibling tool.
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?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: the task and all its checklist items (subtasks) will be removed. However, it does not mention irreversibility, required permissions, or failure behavior, leaving some uncertainty about side effects.
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, directly states the action, and includes the important nuance about subtasks in the second sentence. There is no redundant or unnecessary information.
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?
Given the tool's simplicity (two parameters, no output schema), the description covers the essential behavior and side effects. It could mention permanence or prerequisites, but the current level is adequate for a straightforward delete 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?
The input schema describes both required parameters (listId and taskId) with their purposes, achieving 100% coverage. The tool description adds no additional parameter-specific semantics, so it relies on the schema, which is already sufficient.
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 'Delete' and identifies the resource as 'a task from a Microsoft Todo list,' making it clear what action is performed. It also mentions the cascading removal of checklist items, which distinguishes it from sibling tools like delete-task-list and delete-checklist-item.
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 indicates this tool is for deleting individual tasks within a Todo list, providing context that implies the appropriate use case. It does not explicitly contrast with sibling delete operations or state when not to use it, but the resource scope is unambiguous enough to guide selection.
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?
With no annotations, the description must convey behavioral traits. 'Get' implies a read-only operation, but it does not explicitly disclose whether there are side effects, pagination, or the shape of the returned data. It explains the nature of checklist items, which adds some context, but not enough for higher transparency.
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 concise sentences, front-loaded with the purpose. It avoids unnecessary wording and earns its place.
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 retrieval tool with two documented parameters and no output schema, the description is largely complete. It could improve by mentioning that the result is a list of checklist item objects, but it is adequate for correct selection and invocation.
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 descriptions for both listId and taskId. The description does not add additional parameter semantics beyond what the schema already states, so it meets the baseline for high schema coverage.
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 function: 'Get checklist items (subtasks) for a specific task.' It uses a specific verb ('Get'), names the resource ('checklist items'), and defines scope ('for a specific task'). It also clarifies the concept of subtasks, which distinguishes it from sibling tools like create/update/delete-checklist-item.
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 implies when to use this tool (when needing to retrieve checklist items for a task) and the verb 'Get' contrasts with mutation siblings. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a full guideline.
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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It explicitly describes the grouping logic (naming patterns, emoji prefixes, sharing status) and the hierarchical output, but it does not mention whether the operation is read-only, pagination behavior, or potential limitations of the heuristics. For a read list operation, this is partially adequate but lacks some safety/caveat context.
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 concise sentences, front-loaded with the action ('Get all task lists'), and includes the key behavior (organized/folder-like). No filler or redundant details, appropriate size for the tool's complexity.
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?
Given the simple tool with two optional parameters, high schema coverage, and no output schema, the description covers the primary function and grouping inputs. It lacks explicit guidance on when to use it versus the sibling 'get-task-lists' and does not detail the return structure, but the provided information is sufficient for a basic read-oriented listing tool.
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 coverage is 100% (both groupBy and includeIds have descriptions), which establishes a baseline of 3. The description adds extra meaning by explaining that 'category' grouping is based on naming patterns and emoji prefixes, and 'shared' relates to sharing status. However, it does not clarify the 'type' enum value beyond the schema's own description, so it adds value but not comprehensively.
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 retrieves all task lists and organizes them into logical folders/categories based on naming patterns, emoji prefixes, and sharing status. This specific verb+resource+unique organizational behavior distinguishes it from the sibling 'get-task-lists' tool.
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 use when a hierarchical, organized view of task lists is desired, but it does not explicitly mention when to use this versus alternatives like plain get-task-lists, nor does it state when not to use. It provides implied usage but no explicit exclusions or alternatives.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It explicitly states that deleting the list removes all tasks within it, which is a critical destructive side effect. This goes beyond the minimal and provides useful warning.
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, front-loaded with the main action and then the key side effect. No filler or redundant information. Every sentence adds value.
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 deletion tool with no output schema, the description sufficiently explains what happens (deletes list and all contained tasks). It covers the essential context without needing to explain return values or pagination. The cascading delete is the main behavioral nuance and is disclosed.
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 has 100% coverage for the only parameter 'listId' with the description 'ID of the task list to delete'. The tool description does not add any extra meaning beyond what the schema already provides, so the baseline score 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 'Delete' and clearly identifies the resource as 'a task list (top-level container) from Microsoft Todo', which distinguishes it from sibling tools like 'delete-task'. The additional sentence about removing all tasks within the list further clarifies the tool's scope.
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 deleting a task list but does not explicitly mention alternatives or when-not-to-use cases. The context is clear from the tool name and the top-level container description, but no direct comparison with sibling tools like 'delete-task' is provided.
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?
With no annotations provided, the description carries the full burden. It discloses what the tool returns (token status, expiration time, refresh indication) and implicitly indicates it is a non-mutating check. However, it does not clarify whether it makes network calls or could trigger a refresh, which would enhance transparency.
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 primary purpose, and contains no redundant information. Every clause adds value, making it highly concise 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 status-check tool with no parameters, the description is complete enough. It explains what the tool does and what information it provides, without requiring an output schema. The low complexity means the description fully covers the context.
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 has zero parameters, so the input schema is fully covered. The baseline for 0 parameters is 4, and the description adds no parameter-related info, which is appropriate. No additional meaning is needed for non-existent parameters.
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 checks authentication status with Microsoft Graph API, showing token status, expiration time, and refresh need. It uses a specific verb and resource, and is clearly distinct from all sibling tools, which are task-related.
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 the tool should be used to verify authentication, but does not explicitly state when to use it, any prerequisites, or exclusions. There are no alternative auth tools among siblings, so it doesn't name alternatives, but it also doesn't provide contextual guidance like 'use before making API calls.'
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-todo-mcp-server MCP server](https://glama.ai/mcp/servers/jordanburke/microsoft-todo-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/jordanburke/microsoft-todo-mcp-server)

Score Badge

Copy to your README.md:

[![microsoft-todo-mcp-server MCP server](https://glama.ai/mcp/servers/jordanburke/microsoft-todo-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/jordanburke/microsoft-todo-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/jordanburke/microsoft-todo-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server