Skip to main content
Glama
mpalermiti

outlook-mcp

by mpalermiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

outlook_add_checklist_item

Add a checklist item to an existing To Do task using its task ID and display name, optionally within a specified list, to track subtasks.

Instructions

Add a checklist item (sub-step) to a To Do task.

Input Schema

NameRequiredDescriptionDefault
list_idNo
task_idYes
display_nameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.30.2
    • removedInput schema / properties / display_name / title
      Removed value: -"Display Name"
    • 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_add_checklist_itemArguments"
  2. Addedv1.22.1

TDQS

C2.7/5.0
Behavior2/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so mutation is already known; the description adds nothing about whether the item is appended to the end, whether duplicates are prevented, or what errors occur for an invalid task_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 front-loaded sentence with zero filler; concise, though the brevity is partly under-specification rather than 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?

A write tool with no output schema and undocumented parameters should at least say whether the created item's identifier is returned (needed for the follow-up update/delete checklist item calls) and how list_id relates to task_id; neither is covered.

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% across three parameters, and the description mentions none of them — notably list_id, whose purpose and relationship to task_id is entirely unexplained by either the description or 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 ('add') and resource ('checklist item (sub-step)') scoped to a To Do task, which cleanly separates it from sibling update_checklist_item and delete_checklist_item by operation 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?

No guidance on when to use this versus outlook_update_task or outlook_update_checklist_item, and no prerequisite stated (e.g. that the target task must already exist in a task list).

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