Microsoft Todo MCP Service

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity, as they are organized around specific resources (task lists, tasks, checklist items) and actions (create, get, update, delete). For example, create-task and create-checklist-item target different levels of the hierarchy, and operations like delete-task-list and delete-task are clearly separated by scope.
Naming Consistency5/5
The tool names follow a highly consistent verb_noun pattern throughout, such as create-task, get-tasks, update-checklist-item, and delete-task-list. All tools use hyphen-separated lowercase names, making them predictable and easy to understand without any deviations in style.
Tool Count5/5
With 13 tools, the count is well-scoped for managing Microsoft Todo, covering CRUD operations for task lists, tasks, and checklist items. Each tool earns its place by addressing specific needs in the domain, avoiding both redundancy and significant gaps.
Completeness5/5
The tool surface provides complete CRUD/lifecycle coverage for the Microsoft Todo domain, including authentication status, and operations on task lists, tasks, and checklist items. There are no obvious gaps or dead ends, enabling agents to handle all core workflows effectively.
Average 3.3/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 ISC 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'creates' without disclosing behavioral traits like permissions needed, whether it's idempotent, error conditions, or what happens on success/failure. It mentions checklist items help with task breakdown, but this is functional purpose, not operational behavior.
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?
Two sentences that are front-loaded with the core action and purpose. No wasted words, though the second sentence could be considered slightly explanatory rather than essential.
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?
For a creation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral details (e.g., what's returned, error handling) and usage context, relying heavily on the schema for parameters but not compensating for other 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 parameters are well-documented in the schema. The description adds no parameter-specific information beyond implying 'displayName' is for text content and context for 'listId' and 'taskId'. This 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new checklist item (subtask) for a task'), with additional context about purpose ('break down a task into smaller, manageable steps'). It doesn't explicitly differentiate from siblings like 'create-task' or 'update-checklist-item', but the focus on subtasks is reasonably distinct.
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 explicit guidance on when to use this tool versus alternatives like 'create-task' or 'update-checklist-item'. The description implies usage for subtasks but doesn't specify prerequisites (e.g., needing an existing task) or exclusions, leaving the agent to infer context from parameter names alone.
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 carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention permissions required, whether it's idempotent, error conditions, or what happens on success (e.g., returns task ID). The description only covers basic functionality without behavioral traits.
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 appropriately concise with two sentences that directly address the tool's purpose. It's front-loaded with the core action and avoids unnecessary elaboration. However, the second sentence could be slightly more focused on tool usage rather than general task definition.
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?
For a creation tool with 10 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like authentication needs, error handling, or return values. While the schema covers parameters well, the description lacks context about the tool's operation in the broader system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description mentions some properties ('title, description, due date, and other properties') but adds minimal semantic value beyond what's in the schema. Baseline 3 is appropriate when schema does heavy lifting.
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 clearly states the action ('Create a new task') and resource ('in a specific Microsoft Todo list'), with additional context about what a task is. However, it doesn't explicitly differentiate from sibling tools like 'create-checklist-item' or 'create-task-list', which would be needed for a score of 5.
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?
The description provides no guidance on when to use this tool versus alternatives like 'create-checklist-item' or 'update-task'. It mentions the context ('in a specific Microsoft Todo list') but doesn't specify prerequisites, exclusions, or comparison with sibling tools.
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 describes what the tool does (retrieves checklist items) but lacks behavioral details: it doesn't specify if this is a read-only operation, what permissions are needed, how results are returned (e.g., pagination, format), or error handling. For a retrieval tool with zero annotation coverage, this is a significant gap.
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 concise sentences that efficiently state the purpose and clarify what checklist items are. It's front-loaded with the main action and avoids unnecessary details. However, it could be slightly more structured by explicitly mentioning parameters or usage context.
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 tool's low complexity (2 required parameters, no output schema), the description is minimally adequate. It covers the basic purpose but lacks completeness in behavioral aspects (e.g., return format, error cases) and usage guidelines. With no annotations and no output schema, it should do more to compensate, but the simplicity keeps it at a baseline level.
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%, with clear descriptions for listId and taskId. The description adds minimal value beyond the schema by clarifying that checklist items belong to a 'specific task', reinforcing the parameter roles. Since the schema already documents parameters well, the baseline is 3, and the description doesn't add significant extra meaning.
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 clearly states the verb 'Get' and the resource 'checklist items (subtasks)', specifying they belong to a parent task. It distinguishes checklist items as subtasks, which helps differentiate from sibling tools like get-tasks or get-task-lists. However, it doesn't explicitly contrast with create-checklist-item or update-checklist-item, keeping it at 4 instead of 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing listId and taskId), exclusions, or comparisons to sibling tools like get-tasks (which might return tasks without checklist details). Usage is implied from the purpose but lacks explicit context.
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 carries the full burden of behavioral disclosure. It mentions that tasks 'can contain checklist items,' which adds some context about the data structure, but fails to describe key behaviors like pagination (implied by 'top'/'skip' parameters), rate limits, authentication needs, or what the output looks like (e.g., list of tasks). This is a significant gap for a read operation with multiple parameters.
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 appropriately sized with two sentences that are front-loaded and efficient. The first sentence states the core purpose, and the second adds useful context about checklist items without redundancy. It earns its place but could be slightly more structured for clarity.
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 the complexity (7 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral details (e.g., output format, pagination), usage guidelines, and doesn't fully leverage the opportunity to add value beyond the schema. For a tool with rich filtering options, more context is needed to guide effective 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?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds no parameter-specific information beyond implying tasks relate to checklist items, which doesn't clarify any parameters. Baseline 3 is appropriate as the schema handles the heavy lifting, but the description doesn't compensate with additional semantic context.
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 clearly states the verb ('Get') and resource ('tasks from a specific Microsoft Todo list'), and distinguishes tasks from checklist items by noting they 'can contain checklist items (subtasks).' However, it doesn't explicitly differentiate from sibling tools like 'get-task-lists' or 'get-checklist-items' beyond the resource scope.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a list ID), exclusions, or comparisons to siblings like 'get-task-lists' for listing lists or 'get-checklist-items' for subtasks, leaving usage context implied at best.
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 carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't cover permissions needed, whether changes are reversible, error handling, or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 front-loads the purpose and key capabilities without waste. Every word contributes to understanding the tool's function, making it appropriately sized and well-structured.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, side effects), response format, and usage context relative to siblings. While the schema covers parameters well, the overall context for safe and effective use is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value by mentioning 'text content' (mapping to displayName) and 'completion status' (mapping to isChecked), but doesn't provide additional syntax or context beyond what the schema offers. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states the verb ('update') and resource ('existing checklist item/subtask'), specifying what can be changed ('text content or completion status'). It distinguishes from siblings like create-checklist-item or delete-checklist-item by focusing on modification rather than creation or removal, though it doesn't explicitly contrast with update-task or update-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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like update-task or update-task-list, nor does it mention prerequisites or exclusions. It implies usage for modifying subtasks but lacks context about sibling relationships or specific scenarios.
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 carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) and mentions what can be changed, but lacks critical information: whether this requires specific permissions, if changes are reversible, what happens to unspecified properties (partial vs. full updates), error conditions, or response format. For a mutation tool with 11 parameters, this is insufficient.
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 a single, efficient sentence that front-loads the core purpose. It wastes no words but could be slightly more structured by separating usage context from capability listing. Every part earns its place, though it's brief given the tool's complexity.
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 the tool's complexity (mutation with 11 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose but lacks behavioral context (permissions, side effects), usage guidelines, and output expectations. For a tool that modifies data in a system like Microsoft Todo, this leaves significant gaps for an AI agent.
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 with their types, descriptions, enums, and required status. The description adds minimal value beyond the schema by generically mentioning 'any properties including title, due date, importance, etc.' but provides no additional syntax, format details, or constraints. This 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing task in Microsoft Todo'), and specifies the scope ('allows changing any properties'). It distinguishes from siblings like create-task or delete-task by focusing on modification of existing tasks. However, it doesn't explicitly differentiate from update-checklist-item or update-task-list, which are similar update operations on different resources.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing listId and taskId), when to choose update-task over create-task for similar outcomes, or any constraints on usage. The agent must infer usage from the tool name alone.
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 carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't describe permissions needed, whether changes are reversible, rate limits, error responses, or what happens on success. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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 with zero wasted words. It's front-loaded with the core purpose and includes necessary context ('Microsoft Todo', 'top-level container'). Every element earns its place without redundancy.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral implications. While the schema covers parameters well, the overall context for using this update operation remains incomplete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (listId and displayName). The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain format requirements, constraints, or examples. Baseline 3 is appropriate when the schema does all the parameter documentation work.
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 clearly states the action ('Update'), the resource ('name of an existing task list'), and the platform context ('Microsoft Todo'). It specifies this is for 'top-level container' task lists, which helps distinguish it from other list-like resources. However, it doesn't explicitly differentiate from sibling 'update-task' or 'update-checklist-item' tools beyond the resource type.
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?
The description provides no guidance on when to use this tool versus alternatives like 'update-task' or 'update-checklist-item'. It doesn't mention prerequisites (e.g., needing an existing list ID), error conditions, or when not to use it. The only contextual clue is 'existing task list', implying the list must already exist.
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. It states this creates a 'top-level container,' implying a write operation, but doesn't disclose behavioral traits like required permissions, whether it's idempotent, error conditions, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap.
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 a single, efficient sentence that front-loads the core action ('Create a new task list') and purpose. It avoids redundancy, but could be slightly more structured by separating usage context. Every word earns its place, making it concise.
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 the tool is a mutation (create operation) with no annotations, no output schema, and 1 parameter, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or response format, which are critical for an AI agent to invoke it correctly. The purpose is clear, but operational details are lacking.
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 schema description coverage is 100%, with the parameter 'displayName' documented as 'Name of the new task list.' The description adds no additional parameter semantics beyond this, such as format constraints or examples. With high schema coverage, the baseline is 3, 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.
Purpose4/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 list') and resource ('in Microsoft Todo'), with the purpose to 'organize your tasks into categories or projects.' It distinguishes from siblings like 'create-task' (individual tasks) and 'create-checklist-item' (items within lists), but doesn't explicitly contrast with 'get-task-lists' (read-only) or 'update-task-list' (modify existing).
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 organizing tasks into categories/projects, suggesting when to use it. However, it lacks explicit guidance on when not to use it (e.g., vs. 'create-task' for standalone tasks) or alternatives like 'update-task-list' for modifying existing lists. The context is clear but not comprehensive.
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. It states this is a deletion operation, implying mutation, but does not disclose behavioral traits such as whether deletion is permanent, requires specific permissions, has side effects (e.g., affecting task completion status), or error conditions. This is a significant gap for a mutation tool with zero annotation coverage.
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 with zero waste: the first states the action and resource, and the second clarifies scope. It is front-loaded and appropriately sized, earning its place efficiently.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It covers purpose and scope but lacks details on behavior, permissions, or return values. However, the schema fully documents parameters, and the description differentiates from siblings, making it minimally adequate but with clear gaps for a deletion operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (listId, taskId, checklistItemId) with clear descriptions. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or relationships between parameters, meeting 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 specific action ('Delete a checklist item') and resource ('from a task'), distinguishing it from siblings like delete-task or delete-task-list by specifying it removes only the subtask, not the parent task. This provides precise differentiation.
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 usage context by stating it deletes 'just the specific subtask, not the parent task,' which helps differentiate from delete-task. However, it does not explicitly mention when to use alternatives like update-checklist-item or get-checklist-items, nor does it specify prerequisites like needing the listId and taskId first.
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 full burden. It discloses the destructive behavior ('remove the task and all its checklist items'), which is crucial for a deletion operation. However, it doesn't mention permissions required, whether deletion is reversible, rate limits, or what happens if the task doesn't exist. The description adds some behavioral context but leaves significant gaps for a destructive 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 two concise sentences that efficiently convey the core action and important side effect. Every word earns its place - the first sentence states the primary purpose, the second clarifies the scope of deletion. No wasted words or unnecessary elaboration.
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?
For a destructive tool with no annotations and no output schema, the description provides basic purpose and scope but lacks important context. It doesn't explain what happens on success/failure, whether there's confirmation required, or what permissions are needed. The description is minimally adequate but leaves the agent with significant unknowns about the tool's behavior and outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (listId and taskId) with clear descriptions. The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline of 3 when schema coverage is high, but doesn't provide additional semantic context.
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 ('Delete'), target resource ('a task from a Microsoft Todo list'), and scope ('remove the task and all its checklist items'). It distinguishes from siblings like delete-checklist-item (which only removes subtasks) and delete-task-list (which removes entire lists).
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 when needing to permanently remove a task and its subtasks, but doesn't explicitly state when to use this vs. alternatives like archiving or when not to use it (e.g., for temporary removal). It mentions the effect on checklist items, which helps differentiate from delete-checklist-item, but lacks explicit guidance on prerequisites or comparisons to other deletion tools.
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 discloses the destructive behavior ('remove the list and all tasks within it'), which is critical, but lacks other behavioral traits like authentication needs, error conditions, or confirmation requirements. The description is minimal but correctly indicates a destructive 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 sentences, front-loaded with the core action and resource, followed by scope clarification. Every word earns its place with no redundancy or fluff, making it highly efficient and easy to parse.
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?
For a destructive tool with no annotations and no output schema, the description is adequate but incomplete. It covers the purpose and scope well, but lacks context on permissions, irreversibility, or response format. Given the complexity (destructive operation) and minimal structured data, it should provide more behavioral guidance.
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% for the single parameter 'listId', so the schema already documents it fully. The description doesn't add parameter-specific details beyond implying the parameter's role in identifying the list to delete. With 0 parameters needing extra semantics, baseline is 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 clearly states the specific action ('Delete'), target resource ('task list (top-level container) from Microsoft Todo'), and scope ('remove the list and all tasks within it'). It distinguishes this from sibling tools like 'delete-task' (individual tasks) and 'delete-checklist-item' (checklist items).
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 entire task lists with all contained tasks, but doesn't explicitly state when to use this versus alternatives like 'delete-task' for individual tasks or provide exclusions (e.g., cannot be undone, requires list ownership). No prerequisites or warnings are mentioned.
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 full burden. It discloses that this is a read-only diagnostic tool (implied by 'Check' and 'Shows') and describes what information it returns. However, it doesn't mention potential error conditions, rate limits, or whether this operation requires any specific permissions, leaving some behavioral aspects unclear.
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 perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, the second elaborates on what information is returned. There's zero wasted text, and the information is front-loaded with the most important detail first.
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 zero-parameter diagnostic tool with no output schema, the description provides good context about what information will be returned (token status, expiration time, refresh indication). However, without annotations or output schema, it could benefit from more detail about the exact format of the returned information or potential error states, preventing a perfect score.
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 with 100% schema description coverage. The description appropriately doesn't waste space discussing nonexistent parameters. A baseline of 4 is appropriate since there are no parameters to document, and the description focuses correctly on the tool's purpose rather than parameter details.
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 ('Check if you're authenticated'), the target resource ('Microsoft Graph API'), and the output details ('current token status and expiration time, indicates if token needs refresh'). It distinguishes itself from sibling tools which are all about task/checklist management, making its purpose uniquely about authentication status verification.
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 usage context ('Check if you're authenticated') suggesting this tool should be used to verify authentication state before performing operations that require it. However, it doesn't explicitly state when NOT to use it or name specific alternatives for different authentication scenarios, which prevents a perfect score.
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. It discloses that it retrieves all lists with names, IDs, and indicates default or shared status, which is useful behavioral context. However, it doesn't mention potential limitations like pagination, rate limits, or authentication needs, leaving gaps for a read 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 a single, well-structured sentence that efficiently conveys purpose and key details (e.g., list names, IDs, default/shared indicators) without unnecessary words. It's front-loaded with the main action and resource.
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 low complexity (0 parameters, no output schema, no annotations), the description is mostly complete for a simple read operation. It explains what is retrieved, but lacks details on output format (e.g., JSON structure) or error handling, which could be helpful despite no output schema.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds no parameter information, which is appropriate, but it doesn't compensate for any gaps since there are none. Baseline is 4 for 0 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 verb ('Get') and resource ('Microsoft Todo task lists'), specifying they are top-level containers that organize tasks. It distinguishes from siblings like get-tasks (which retrieves individual tasks) and get-checklist-items (which retrieves checklist items within tasks).
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 usage by stating it retrieves all task lists, including default or shared ones, which suggests it's for listing containers rather than items. However, it doesn't explicitly state when to use this versus alternatives like get-tasks or when not to use it (e.g., for creating or updating lists).
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:

[![todoMCP MCP server](https://glama.ai/mcp/servers/jhirono/todoMCP/badges/card.svg)](https://glama.ai/mcp/servers/jhirono/todoMCP)

Score Badge

Copy to your README.md:

[![todoMCP MCP server](https://glama.ai/mcp/servers/jhirono/todoMCP/badges/score.svg)](https://glama.ai/mcp/servers/jhirono/todoMCP)

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/jhirono/todoMCP'

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