This MCP server enables Claude to manage Microsoft Planner via the Microsoft Graph API. Key capabilities include:
Authentication
Initiate OAuth 2.0 device code flow (auth_start) and poll for completion (auth_poll), with token persistence.
Plans
List all plans (list_plans), retrieve plan details (get_plan), and get extended info including category/label descriptions (get_plan_details).
Buckets
List buckets within a plan (list_buckets) and create new buckets (create_bucket).
Tasks
List (list_tasks): Filter by plan, bucket, priority (Urgent/Important/Medium/Low), due/creation/completion dates, completion percentage, assigned users, categories, and search keywords; supports pagination.
Get (get_task): Retrieve detailed task info, optionally including description, checklist, and references.
Create (create_task): Add tasks with title, description, priority, due/start dates, assignments, categories, and checklist items.
Update (update_task): Modify title, description, priority, bucket, dates, completion percentage, assignments, categories, and checklist items.
Delete (delete_task): Permanently remove a task.
Checklists: Add, update, or remove checklist items on tasks.
Users & Groups
Retrieve the signed-in user's profile (get_me) and list members of a Microsoft 365 group (list_group_members), with filtering and search support.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Planner MCP Server Show my urgent tasks in the 'Project Alpha' plan."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables Claude to interact with Microsoft Planner through the Microsoft Graph API.
Authentication: OAuth 2.0 device code flow for secure authentication
Plans Management: List and view Planner plans
Buckets Management: List, create, and manage buckets within plans
Tasks Management: Create, update, delete, and view tasks
Checklists: Add, update, and remove checklist items on tasks
Token Persistence: Stores access tokens across server restarts
Related MCP server: Microsoft Planner MCP
Node.js 18+ or newer
npm or yarn
Microsoft account with access to Planner
Clone or download this repository
Install dependencies:
cd planner-mcp
npm installBuild the project:
npm run buildBefore using the Planner tools, you need to authenticate:
Start the authentication flow by calling the auth_start tool
Visit the displayed verification URL
Enter the provided code
Sign in with your Microsoft account
Use the auth_poll tool to check if authentication is complete
The access token will be saved locally and reused for future sessions.
claude mcp add --transport stdio planner node /path/to/planner-mcp/build/index.jsAdd this server to your Claude Desktop configuration file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"planner": {
"command": "node",
"args": ["/path/to/planner-mcp/build/index.js"]
}
}
}Note: Replace
/path/to/planner-mcp/build/index.jswith the actual path to your cloned repository.
auth_start: Start the Planner authentication flow (device code)
auth_poll: Check if authentication is complete
list_plans: List all Microsoft Planner plans for the current user
get_plan: Get detailed information about a specific plan
list_buckets: List all buckets in a plan
create_bucket: Create a new bucket in a plan
list_tasks: List tasks in a plan or bucket with filtering options (priority, due date, status, etc.)
get_task: Get detailed information about a specific task
create_task: Create a new task in a bucket with title, description, priority, and due date
update_task: Update an existing task (title, description, priority, bucket, due date, checklist, etc.)
delete_task: Delete a task
Checklist parameter (on create_task and update_task): pass checklist as an object keyed by item ID, same style as assignments:
To add an item, use any unique string as the key with {"title": "...", "isChecked": false}
To update an item, use its existing item ID (from get_task/list_tasks with includeDetails: true) with just the fields to change
To remove an item, set its ID's value to null
Example:
{
"taskId": "your-task-id",
"checklist": {
"buy-milk": { "title": "Buy milk", "isChecked": false },
"existing-item-id-from-get-task": { "isChecked": true },
"item-id-to-remove": null
}
}Checklist items are visible on any task fetched via get_task or list_tasks with includeDetails: true (under details.checklist, keyed by item ID).
Priority Levels:
1 = Urgent (highest priority)
3 = Important (high priority)
5 = Medium (normal priority)
9 = Low (lowest priority)
The Microsoft Graph API requires the following permissions for Planner:
Group.Read.All - To list plans and buckets
Tasks.ReadWrite - To read, create, update, and delete tasks
List plans: list_plans
List buckets in a plan: list_buckets with the plan ID
Create a task: create_task with plan ID, bucket ID, title, and priority (1=urgent, 3=important, 5=medium, 9=low)
Example:
{
"planId": "your-plan-id",
"bucketId": "your-bucket-id",
"title": "Complete project proposal",
"description": "Write and submit the Q1 project proposal",
"priority": 1,
"dueDateTime": "2026-03-30T17:00:00Z"
}Get task details: get_task
Update task: update_task with the new bucket ID
List tasks with priority filter: list_tasks with plan ID and priority parameter
Example:
{
"planId": "your-plan-id",
"priority": 1
}This will show only urgent tasks (priority 1).
Get task details: get_task
Update task: update_task with the new due date in ISO 8601 format (e.g., "2025-12-31T23:59:59Z")
If authentication fails, try these steps:
Delete the .access-token.txt file
Call auth_start again
Make sure you're using a Microsoft account that has access to Planner
If you get a "Not authenticated" error:
Make sure you've completed the authentication flow
Check that the .access-token.txt file exists and contains a valid token
If the token has expired, run auth_start again
If you get permission errors:
Make sure your Microsoft account has access to the specified plan
Check that the required permissions are granted in your Azure AD app
npm run buildnpm run watchnpm startISC
Contributions are welcome! Please feel free to submit issues or pull requests.
Check if the authentication is complete. Only call this after auth_start returned a verification URL and the user has completed sign-in on the Microsoft website. Do NOT call this unless you just ran auth_start and it returned a code/URL for the user to visit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the dependency on auth_start and the user action, but does not mention behavior like polling frequency, timeout, or what happens if authentication fails. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. Every sentence adds essential value: the purpose and the usage constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description provides necessary context about when to call. However, it could mention what the response indicates (e.g., success/failure) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description need not add parameter details. Baseline is 4 due to no parameters; the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Check if the authentication is complete', specifying the verb and resource. It distinguishes from the sibling tool 'auth_start' by mentioning it is called after auth_start returns a verification URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to call ('after auth_start returned a verification URL and the user has completed sign-in') and when not to call ('Do NOT call this unless you just ran auth_start and it returned a code/URL'). This clearly differentiates usage from auth_start.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the Planner authentication flow. IMPORTANT: Only call this tool when you receive an authentication error (e.g. 'Not authenticated') from another tool, or when the user explicitly requests re-authentication. Do NOT call this proactively before using other Planner tools - they automatically use the stored token. If a valid token already exists, this returns immediately without starting a new auth flow.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Force re-authentication even if a valid token exists (default: false) | |
| clientId | No | Azure AD application client ID (optional, uses Microsoft Graph Explorer by default) | |
| tenantId | No | Azure AD tenant ID (optional, uses 'common' by default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fully discloses key behaviors: immediate return if valid token exists, effect of force parameter, and that it does not need to be called proactively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise paragraph of 5 sentences with no fluff. It is front-loaded with purpose and usage conditions, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple auth flow start tool without output schema, the description covers when to call, behavior, and parameter usage. However, it does not mention what the tool returns (e.g., authorization URL), which could be useful for follow-up actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds context for the force parameter (when to force re-auth) and clarifies defaults for clientId and tenantId, providing meaningful addition beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts the Planner authentication flow, using a specific verb ('Start') and resource ('Planner authentication flow'). It distinguishes from sibling tools that are for Planner operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (only on authentication error or user request) and when not to use (proactively before other tools). It clarifies that other tools automatically use stored tokens, providing excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new bucket in a plan
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Bucket name | |
| planId | Yes | Plan ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states 'create' which implies mutation, but no details on side effects, permissions required, idempotency, or limits. This is insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 7 words with no waste. However, it misses important details that could be added without becoming verbose, so it's not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, the description should indicate what on success (e.g., returns the created bucket ID), error conditions, or any constraints. It provides only the most basic information, leaving the agent uninformed about the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no extra meaning beyond what the schema provides, but baseline of 3 is appropriate since the schema already documents parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (bucket in a plan) with a specific verb+resource structure. While it doesn't differentiate from siblings, the sibling list contains no other creation tools for buckets, so confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use the tool versus alternatives (e.g., list_buckets for reading, or update for modifying). No exclusions, prerequisites, or contextual usage hints are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task in a bucket
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Task title | |
| planId | Yes | Plan ID | |
| bucketId | Yes | Bucket ID where to create the task | |
| priority | No | Priority: 1=urgent, 3=important, 5=medium, 9=low (optional) | |
| assignments | No | Assignments keyed by user ID. Use null to remove, or plannerAssignment object to add/update. | |
| description | No | Task description (optional) | |
| dueDateTime | No | Due date in ISO 8601 format (optional) | |
| startDateTime | No | Start date in ISO 8601 format (optional) | |
| percentComplete | No | Percentage of task completion 0-100 (optional) | |
| appliedCategories | No | Labels/categories as JSON string with category names as keys and boolean values. To ADD a tag set it to true (e.g., '{"category1":true}'). To REMOVE a tag you MUST set it to false (e.g., '{"category1":false}') — sending {} will NOT remove anything. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'create', omitting behavioral traits such as validation, side effects, permissions, rate limits, or idempotency. Essential information is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise. However, it sacrifices informative content for brevity. It is not front-loaded with critical information and contains no structural elements like bullet points or sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, nested objects, no output schema, no annotations), the description is insufficient. It does not cover return values, error conditions, or practical usage examples. Sibling tools exist but are not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 is appropriate. The description does not add any value beyond the schema; it does not explain parameter relationships or usage context. The schema descriptions are present but the tool description does not enhance them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new task in a bucket' clearly states the action (create) and the resource (task) with a location hint. It distinguishes from siblings like create_bucket (bucket creation) and update_task (update). However, it could be more specific about the system (e.g., Planner).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like update_task or create_bucket. There are no prerequisites, exclusions, or context provided. The agent must infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a task
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'Delete a task,' omitting details like permanence, authorization needs, or cascading effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, and front-loaded. However, it is minimally informative, so not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with no annotations or output schema, the description is insufficient. It lacks details on success confirmation, whether deletion is irreversible, or any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, describing taskId as 'Task ID to delete.' The description adds no extra meaning beyond the schema, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a task' uses a specific verb ('delete') and resource ('task'), clearly distinguishing it from sibling tools like create_task, update_task, and list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as prerequisites (task must exist) or when deletion is appropriate compared to update_task or list_tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current signed-in user's profile (id, displayName, mail, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| select | No | Comma-separated fields to return (e.g. 'id,displayName,mail,userPrincipalName'). Defaults to common fields. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It explicitly states 'Get', indicating a read-only operation. It does not discuss permissions or rate limits, but for a simple profile retrieval, the behavioral trait is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that starts with the verb and resource, leaving no wasted space. It is front-loaded and conveys essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides an adequate overview of what is returned via examples. It is sufficiently complete for a simple tool with one optional parameter, though it could mention that the return is a JSON object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the select parameter described. The description adds value by listing example fields (id, displayName, mail) that can be returned, which complements the schema and helps the agent understand typical usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'current signed-in user's profile', and lists example fields like id, displayName, mail. It distinguishes from sibling get_* tools which target other entities (plans, tasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit when-to-use or alternatives are mentioned, the name and context make it clear this is for retrieving the authenticated user's profile. The description is straightforward and implies use when user profile data is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific plan
| Name | Required | Description | Default |
|---|---|---|---|
| planId | Yes | Plan ID (use list_plans to find ID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose read-only nature, authentication needs, or response structure. For a retrieval tool, stating 'This does not modify any data' would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, front-loaded with key verb and resource. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description fails to specify what 'detailed information' includes. Overlap with sibling 'get_plan_details' creates confusion, making the tool's role incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the planId parameter includes a helpful hint to use 'list_plans' to find the ID. Description adds no extra meaning beyond schema, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get' and resource 'plan'. However, sibling 'get_plan_details' exists but no distinction is made, leaving ambiguity. A more precise description like 'Get summary of a plan' would differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as 'get_plan_details' or 'list_plans'. Agent must guess usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a plan including category descriptions (labels)
| Name | Required | Description | Default |
|---|---|---|---|
| planId | Yes | Plan ID (use list_plans to find ID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits such as being read-only, data limits, or side effects. It merely states it gets information, which is insufficient for a tool with no annotation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core functionality. It could benefit from slightly more detail, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too sparse. It does not explain return format, pagination, or when to prefer this over get_plan. For a simple tool, it barely meets minimal requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description adds value by hinting at the output content (category descriptions), but this does not directly enhance parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves detailed plan information including category descriptions, which implies a more detailed view than a basic get_plan. However, it does not explicitly differentiate from the sibling tool get_plan, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_plan. The only usage hint is the parameter description mentioning list_plans to find the ID, which is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific task
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID | |
| includeDetails | No | Include task details (description, checklist, references) via $expand=details |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description fails to note that the operation is read-only, nor does it mention the effect of includeDetails or any other 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no superfluous words; front-loads the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks information about return values (no output schema) and does not mention parameter behavior or prerequisites, making it incomplete for a 2-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters; the tool description adds no additional meaning, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Get') and resource ('specific task'), effectively distinguishing it from sibling tools like list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as list_tasks or get_plan; the description merely states its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all buckets in a plan
| Name | Required | Description | Default |
|---|---|---|---|
| planId | Yes | Plan ID (use list_plans to find ID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose whether the operation is read-only, if there are pagination limits, or any side effects. It simply states 'list all buckets' without behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence and no unnecessary words, appropriate for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain what the tool returns (e.g., list of bucket objects, IDs). It lacks completeness for an agent to understand the full outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond the schema's parameter description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and resource ('buckets'), and the context of 'in a plan' distinguishes it from sibling tools like list_plans or create_bucket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The schema hints to use list_plans for the planId, but the description itself lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all members of a Microsoft 365 group (users, contacts, devices, service principals, and other groups)
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Maximum number of members to return (optional, default: 100, max: 999) | |
| filter | No | OData filter expression (optional, e.g., "displayName eq 'John Doe'") | |
| search | No | Search string for displayName and description properties (optional) | |
| select | No | Comma-separated properties to return (optional, e.g., 'id,displayName,mail') | |
| groupId | Yes | Group ID (use get_plan to find the group ID from plan's container.containerId) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description mentions member types but does not disclose behavioral traits like pagination (top parameter with default 100), filtering effects, or that 'list all' might be limited by the top parameter. Some behavioral context is implied but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no redundancy. However, it could be more informative about optional parameters and behaviors without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should explain return values; it does not. Also, it omits pagination details and user guidance on using optional parameters effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only restates groupId indirectly. No additional parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists members of a Microsoft 365 group, specifying the types of members (users, contacts, etc.), and implicitly distinguishes from sibling tools like list_tasks or list_buckets by focusing on group members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, prerequisites (e.g., groupId), or typical use cases. It lacks explicit context such as 'Use when you need all members of a group'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Microsoft Planner plans for the current user
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention read-only nature, performance implications, pagination, or any constraints beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no superfluous information. It is front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is minimal but adequate. It lacks details about return format or behavior (e.g., pagination), but is arguably sufficient for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description adds no parameter information. Baseline 4 applies as there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (List) and the resource (all Microsoft Planner plans for the current user), clearly distinguishing it from sibling tools like get_plan or list_buckets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is straightforward, providing clear context. However, there is no explicit guidance on when not to use this tool or alternatives like get_plan for specific plans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks in a plan or bucket with advanced filtering
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Number of tasks to skip (for pagination, use with limit) | |
| limit | No | Maximum number of tasks to return (pagination) | |
| fields | No | Comma-separated field names to return (e.g., 'id,title,bucketId,percentComplete') - reduces token usage | |
| planId | No | Plan ID (optional - if not provided, lists tasks assigned to you) | |
| search | No | Search tasks by keyword using fuzzy matching. Matches against title, and description if includeDetails is true. | |
| bucketId | No | Bucket ID (optional - filters by bucket within the plan) | |
| dueAfter | No | Due date after this date (ISO 8601: '2026-03-27' or relative: 'today', 'tomorrow', 'next-week') | |
| priority | No | Filter by priority, supports multiple values (OR logic). e.g. [1,3] for urgent+important. Values: 1=urgent, 3=important, 5=medium, 9=low | |
| dueBefore | No | Due date before this date (ISO 8601: '2026-03-27' or relative: 'today', 'tomorrow', 'next-week') | |
| isArchived | No | Filter by archived status (true/false/undefined for both) | |
| assignedToMe | No | Filter by tasks assigned to current user (only works with planId) | |
| createdAfter | No | Created after this date (ISO 8601 or relative: 'today', 'this-week', 'last-week') | |
| createdBefore | No | Created before this date (ISO 8601 or relative: 'today', 'this-week', 'last-week') | |
| completedAfter | No | Completed after this date (ISO 8601 or relative) | |
| includeDetails | No | Include task details (description, checklist, references) via $expand=details | |
| completedBefore | No | Completed before this date (ISO 8601 or relative) | |
| percentComplete | No | Filter by percent complete. Supports comparison operators: '>50', '>=50', '<100', '<=100', or exact value '50'. Use 0 for not started, 100 for completed | |
| searchThreshold | No | Fuzzy search sensitivity: 0.0 = exact match only, 1.0 = match anything. Default is 0.4. | |
| appliedCategories | No | Filter tasks by categories, comma-separated (e.g., 'category1' or 'category1,category3'). Returns tasks that have ALL specified categories set to true. | |
| assignedToUserIds | No | Filter tasks assigned to any of the specified user IDs (OR logic). e.g. ['user-id-1', 'user-id-2'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits like pagination limits, permission requirements, or whether only accessible tasks are returned. The description is insufficient for a complex tool with many parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, though it could include more useful information without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 20 parameters, no output schema, and no annotations, the description is too brief. It does not explain the return format or how to leverage advanced filtering, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters effectively. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tasks in a plan or bucket with advanced filtering. It uses specific verb and resource, and distinguishes from siblings like get_task (single task) and list_buckets (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when listing tasks in a plan/bucket with filtering) but does not explicitly state when not to use it or provide alternatives. Context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing task
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | New task title (optional) | |
| taskId | Yes | Task ID to update | |
| bucketId | No | New bucket ID (optional) | |
| priority | No | Priority: 1=urgent, 3=important, 5=medium, 9=low (optional) | |
| assignments | No | Assignments keyed by user ID. Use null to remove, or plannerAssignment object to add/update. | |
| description | No | New task description (optional) | |
| dueDateTime | No | New due date in ISO 8601 format (optional) | |
| startDateTime | No | New start date in ISO 8601 format (optional) | |
| percentComplete | No | Percentage of task completion 0-100 (optional) | |
| appliedCategories | No | Labels/categories as JSON string with category names as keys and boolean values. To ADD a tag set it to true (e.g., '{"category1":true}'). To REMOVE a tag you MUST set it to false (e.g., '{"category1":false}') — sending {} will NOT remove anything. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. Merely says 'Update', implying mutation, but does not explain overwrite behavior, required fields beyond taskId (though schema shows others optional), or whether missing fields are left unchanged. Without these details, agent may misuse the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (4 words), but too sparse. While brevity is valued, it sacrifices useful context. A middle ground would be better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 10 parameters with nested objects and no output schema. Description fails to mention behavior like partial update semantics, permission requirements, or rate limits. For a complex mutation tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in schema. Description adds no additional meaning beyond what is in schema, but baseline of 3 is appropriate given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'update' and resource 'existing task', distinguishing from create_task and delete_task. Could be more specific about what can be updated, but sufficient for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (create_task, delete_task, get_task). No context on prerequisites, idempotency, or best practices for partial updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0auth_pollauth_startcreate_bucketcreate_taskdelete_taskget_meget_planget_plan_detailsget_tasklist_bucketslist_group_memberslist_planslist_tasksupdate_taskScored across 14 tools
Tools are generally distinct with clear purposes. There is slight overlap between get_plan and get_plan_details, but the latter includes category descriptions, reducing ambiguity. Other tools cover different resources (auth, user, plans, buckets, tasks) with no major confusion.
All tool names follow a consistent verb_noun pattern using underscores (e.g., create_task, list_buckets, get_plan). Auth tools use a verb_noun structure as well (auth_poll, auth_start). No mixing of conventions like camelCase.
14 tools cover the core functionality of a Planner server, including authentication, plans, buckets, tasks, user info, and group members. The count is well-scoped—not too many to overwhelm, yet sufficient for common operations.
Task CRUD is complete (create, read, update, delete), but bucket and plan operations are incomplete: missing create_plan, delete_plan, update_bucket, delete_bucket. No task assignment tool. These gaps may hinder some workflows.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Give Claude only the Google Drive files you choose. Every action logged.
Manage Microsoft 365 email, calendar, contacts and inbox rules via the Graph API with OAuth 2.0.
Plan trips directly into TravelOwl from a conversation with Claude.
