Skip to main content
Glama
mpalermiti

outlook-mcp

by mpalermiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

outlook_changes_since

Read-only

Return a structured digest of mail, event, and contact changes since the last call, including counts, urgent mail, sender rollups, and new/cancelled events for recurring agent loops.

Instructions

One structured "since last call" digest across mail, events, and contacts.

Use this for recurring agent loops (morning brief, hourly inbox sweep) — one call returns counts, urgent_flagged mail, by-sender rollup, plus new/cancelled events and contacts counts. Use the three individual delta tools (outlook_list_inbox_delta, outlook_list_events_delta, outlook_list_contacts_delta) when you need raw item lists or per-resource control.

Example: first call: outlook_changes_since(); next: outlook_changes_since(delta_tokens=<delta_tokens from prior response>). First call covers the last fallback_window_hours (default 24); later calls (tokens passed back) return only what changed. Replace stored delta_tokens with the returned dict; never merge them. has_more true: a resource stopped early; pass the returned dict back. Each resource's token is independent — drop one stale token without re-syncing the others. If Graph 410s on a token (syncStateNotFound), that resource auto-resyncs and _meta.resync lists which one. urgent_flagged = high-importance OR flagged mail. by_sender = top 5 senders. Calendar modified[] is reserved for future use — modified events surface in new[] today (Graph delta doesn't distinguish them). Calendar organizer_email is also currently empty (the v1.9.0 delta formatter surfaces the organizer name only).

Input Schema

NameRequiredDescriptionDefault
delta_tokensNo
fallback_window_hoursNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.30.2
    • addedInput schema / properties / delta_tokens / additionalProperties
      Added value: +true
    • removedInput schema / properties / delta_tokens / anyOf
      Removed value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / delta_tokens / default
      Removed value: -null
    • removedInput schema / properties / delta_tokens / title
      Removed value: -"Delta Tokens"
    • addedInput schema / properties / delta_tokens / type
      Added value: +"object"
    • removedInput schema / properties / fallback_window_hours / title
      Removed value: -"Fallback Window Hours"
    • removedInput schema / title
      Removed value: -"outlook_changes_sinceArguments"
  2. First observedv1.11.0

TDQS

A4.9/5.0
Behavior5/5

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

Regardless of the readOnlyHint annotation, it discloses behavior an agent could not infer: stateful token lifecycle, token independence per resource, auto-resync on Graph 410/syncStateNotFound, and that has_more means one resource stopped early. It also defines the derived fields (urgent_flagged = high-importance OR flagged; by_sender = top 5) and flags known empty fields (calendar organizer_email, modified[]).

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 with purpose and routing before the operational detail, and nearly every sentence carries unique operational value. It is dense and runs long, with the calendar caveats tacked onto the end where they are easy to lose, but nothing is truly redundant.

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?

There is no output schema, so the description must describe return values and it does: counts, urgent_flagged, by-sender rollup, new/cancelled events, contacts counts, the returned delta_tokens dict, has_more, and _meta.resync. Combined with the token lifecycle and known-gap disclosures, an agent has everything needed to call it correctly across a multi-turn loop.

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 coverage is 0% and delta_tokens is an untyped nested object, yet the description fully specifies its semantics: omit on first call, pass back the value from the prior response, replace rather than merge stored tokens, drop individual stale tokens without re-syncing others. It also explains fallback_window_hours (default 24, window size on the first call), which the schema leaves undocumented.

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 first sentence names a specific verb and scope: one structured 'since last call' digest across mail, events, and contacts. It immediately lists the concrete payload (counts, urgent_flagged, by-sender rollup, new/cancelled events, contacts counts), so an agent can distinguish it from the per-resource delta siblings without reading 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?

It states the trigger use case explicitly (recurring agent loops: morning brief, hourly inbox sweep) and names the alternatives with the condition that selects them: the three delta tools when raw item lists or per-resource control are needed. That is when/when-not plus named alternatives, the full 5 bar.

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