Skip to main content
Glama
mpalermiti

outlook-mcp

by mpalermiti

outlook_get_task

Read-only

Retrieve full details for a single To Do task, including notes, checklist items, due date, and recurrence flag, to inspect sub-steps and notes.

Instructions

Get full To Do task details: notes (body), checklist items, due, recurrence flag.

Use this for one task's sub-steps and notes; use outlook_list_tasks for overviews. checklist_items are ordered unchecked-first, matching the To Do client. list_id is only needed when the task lives in a non-default list.

Input Schema

NameRequiredDescriptionDefault
list_idNo
task_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.30.2
    • removedInput schema / properties / list_id / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / list_id / default
      Removed value: -null
    • removedInput schema / properties / list_id / title
      Removed value: -"List Id"
    • addedInput schema / properties / list_id / type
      Added value: +"string"
    • removedInput schema / properties / task_id / title
      Removed value: -"Task Id"
    • removedInput schema / title
      Removed value: -"outlook_get_taskArguments"
  2. Addedv1.22.1

TDQS

A4.6/5.0
Behavior4/5

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

readOnlyHint=true already declares this a safe read, so the bar is lower; the description still adds real context by naming the returned fields and explaining that `checklist_items` are ordered unchecked-first to match the To Do client. It does not cover failure behavior (e.g., missing task_id or list_id), which is the only notable gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with what is returned and immediately followed by the sibling routing rule. Every sentence carries distinct information; no filler.

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?

With no output schema, the description compensates by listing the returned fields, and the checklist ordering note prevents misinterpretation of results. Only error/not-found behavior and `task_id` format are unaddressed, which is a minor gap for a two-parameter read tool.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate — and it does for `list_id` by stating it is only required for non-default lists, plus it maps the notes field to `body`. `task_id` is left implicit as the obvious identifier, which is acceptable but not fully documented.

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?

States a specific verb and resource ('Get full To Do task details') and enumerates the fields returned: notes (`body`), checklist items, due, recurrence flag. It also names the sibling outlook_list_tasks, so the agent can distinguish single-task retrieval from list overviews without opening either schema.

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 routes the agent: 'Use this for one task's sub-steps and notes; use outlook_list_tasks for overviews.' It also gives the condition for the optional parameter ('`list_id` is only needed when the task lives in a non-default list'), leaving nothing to inference.

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

Deploy Server

Other Tools