Skip to main content
Glama
mpalermiti

outlook-mcp

by mpalermiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

outlook_list_events_delta

Read-only

List only calendar event changes within a time window since your last call. Use it for polling agents to track incremental updates via a delta token after an initial start/end query.

Instructions

List only calendar event changes within a window since the last call.

Use this for polling/recurring agents — typically 10x cheaper than outlook_list_events after the first call. Use outlook_list_events for one-shot queries.

Example: first call: outlook_list_events_delta(start="2026-05-22T00:00:00Z", end="2026-05-29T00:00:00Z"); next: outlook_list_events_delta(delta_token=). start/end (ISO 8601) required on first call only; the cursor encodes the window thereafter. is_deleted=True items are tombstones. has_more=True means drain immediately.

Input Schema

NameRequiredDescriptionDefault
endNo
startNo
page_sizeNo
delta_tokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changedv1.30.2
    • removedInput schema / properties / delta_token / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / delta_token / default
      Removed value: -null
    • removedInput schema / properties / delta_token / title
      Removed value: -"Delta Token"
    • addedInput schema / properties / delta_token / type
      Added value: +"string"
    • removedInput schema / properties / end / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / end / default
      Removed value: -null
    • removedInput schema / properties / end / title
      Removed value: -"End"
    • addedInput schema / properties / end / type
      Added value: +"string"
    • removedInput schema / properties / page_size / title
      Removed value: -"Page Size"
    • removedInput schema / properties / start / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / start / default
      Removed value: -null
    • removedInput schema / properties / start / title
      Removed value: -"Start"
    • addedInput schema / properties / start / type
      Added value: +"string"
    • removedInput schema / title
      Removed value: -"outlook_list_events_deltaArguments"
  2. First observedv1.11.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries most of the burden and delivers: cursor encoding the window, is_deleted tombstones, and the has_more drain instruction. It omits a critical delta-API behavior — what happens when delta_token is expired or invalid (full resync vs error) — which is the main operational risk here.

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?

Front-loaded purpose sentence, then routing guidance, then a concrete two-call example that earns its place by showing the exact first/next invocation pattern. Minor redundancy between the prose statement that start/end are first-call-only and the example, and the hard-wrapped lines make it slightly longer than needed.

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?

For a 4-param tool with no output schema and no schema descriptions, the description covers the incremental cursor lifecycle, tombstone semantics, and pagination draining — enough to call it correctly. Missing page_size guidance and expired-token/error behavior keep it short of full completeness.

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 description coverage is 0%, so the description must compensate, and it does for three of four params: start/end are ISO 8601 and required on the first call only, and delta_token is the cursor that supersedes the window. page_size is never mentioned despite influencing the has_more drain loop.

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 ('List only calendar event changes within a window since the last call') and immediately distinguishes itself from the sibling outlook_list_events. An agent can tell incremental-sync semantics apart from a one-shot list without opening the 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 names the target scenario ('polling/recurring agents') and the alternative ('Use outlook_list_events for one-shot queries'), with a cost comparison to justify the choice. The when/when-not split is fully resolved.

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