Skip to main content
Glama
mpalermiti

outlook-mcp

by mpalermiti

outlook_complete_task

Mark an Outlook To Do task as completed by task ID, optionally specifying its list ID, to update task status through Microsoft Graph.

Instructions

Mark a To Do task as completed.

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_complete_taskArguments"
  2. Addedv1.14.0
  3. Removedv1.12.0
  4. First observedv1.11.0

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation/non-destructive profile is covered structurally. The description adds nothing beyond that: it does not say whether completion is reversible, what happens if the task is already completed, or how the task is located (by id alone or within list_id).

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?

A single short sentence with the action front-loaded and no filler. It is appropriately sized for the operation, though its brevity is partly under-specification rather than true economy.

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 two-parameter mutation tool with 0% schema description coverage and no output schema, the description is too thin — the meaning and necessity of list_id, and the result of the call, are left entirely unaddressed.

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

Parameters2/5

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

Schema description coverage is 0%, so the description carries the burden and fails: it never explains task_id's format or whether list_id is required to disambiguate the task lookup. At best 'a To Do task' weakly implies task_id identifies the target, which is a marginal addition over the schema.

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?

States a specific verb and resource ('Mark a To Do task as completed'), which is unambiguous about the effect. It does not distinguish itself from the sibling outlook_update_task, which could plausibly also set completion status, so an agent has no basis for choosing between them from the text alone.

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?

There is no when-to-use guidance, no mention of prerequisites (does the task need to exist in a specific list?), and no reference to alternatives such as outlook_update_task. The agent must infer everything about selection from the tool name.

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