Skip to main content
Glama
XMV-Solutions-GmbH

microsoft-tasks-mcp

by XMV-Solutions-GmbH
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

tasks_login_begin

Idempotent

Starts the OAuth device code login process for accessing Microsoft Planner and To Do tasks. Returns a user code and verification URL for manual sign-in.

Instructions

Drive the OAuth Device Code flow as an MCP tool. Returns immediately, non-blocking. Surfaces user_code + verification_url so the agent can show them; polls Microsoft Identity in the background until the user completes sign-in OR the device code expires (~15 min cap). The agent then polls tasks_login_status until it flips to signed_in (or to a terminal expired / failed). REQUIRED parameter account_type: pass 'personal' for outlook.com / hotmail.com / live.com / msn.com (Microsoft To Do works; Planner does NOT — requires a work/school M365 group), or 'work_or_school' for any Microsoft 365 tenant account incl. B2B guests (both To Do and Planner work). The choice determines which Microsoft Device Code landing page the user is sent to (https://www.microsoft.com/link vs https://login.microsoft.com/device) — there is no auto-detection before sign-in. If you don't know, ASK THE USER first. Calling without account_type returns a structured error explicitly instructing you to elicit the choice. Idempotent: a non-expired pending session for the profile is returned as-is unless force=True. force=True cancels the in-flight session and starts a fresh flow. Returns the session's public view: session_id, user_code, verification_url, verification_url_complete, expires_at, time_remaining_s, status, signed_in_user_upn, error. AGENT_INSTRUCTIONS: Present the verification code to the user inside a fenced code block (so it can be copied with one click) and present the verification URL as a plain markdown link on its own line. Do not paraphrase, do not embed the code inside prose, do not wrap the URL in bold. Example:

Code:
```
ABCD-1234
```

Sign-in URL: https://www.microsoft.com/link

Rationale: in a chat UI, a code inside a fenced block gets a one-click copy button; a bare URL becomes clickable; bold-wrapped links and inline codes do not.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_typeNo
forceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Tool Definition Quality

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description discloses non-blocking, polling in background, expiry ~15 min, idempotent, and error behavior. Annotations include `idempotentHint=true` and `readOnlyHint=false`, which match. No contradiction.

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?

Description is comprehensive but somewhat lengthy. However, it is front-loaded with a clear summary and every sentence adds value, including agent instructions and example. Could be slightly more concise but still effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of OAuth flow and the presence of an output schema, the description covers initiation, polling, parameters, errors, agent actions, and example. It references sibling `tasks_login_status` for follow-up.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has no descriptions (0% coverage). Description fully explains `account_type` with values 'personal' and 'work_or_school', including implications for URL and functionality. It also explains `force` flag and its effect.

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 it 'Drive the OAuth Device Code flow as an MCP tool.' It further explains it initiates login and returns immediately. It differentiates from sibling `tasks_login_status` which polls for completion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use (for login), specifies required parameter `account_type` with guidance to ask user if unsure, describes idempotent behavior and `force` flag, and provides agent instructions for presenting the code and URL.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/XMV-Solutions-GmbH/microsoft-tasks-mcp'

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