Skip to main content
Glama
mpalermiti

outlook-mcp

by mpalermiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

outlook_list_inbox_delta

Read-only

Return only inbox changes since the last call using a delta token, so recurring agents can poll without full inbox scans. Reuse tokens to fetch more changes and drop tombstones for deleted messages.

Instructions

List only inbox changes since the last call.

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

Example: first call: outlook_list_inbox_delta(); next: outlook_list_inbox_delta(delta_token=). is_deleted=True items are tombstones (drop cached payload). has_more=True means drain immediately by passing the returned delta_token back.

Input Schema

NameRequiredDescriptionDefault
folderNoinbox
page_sizeNo
delta_tokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 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 / folder / title
      Removed value: -"Folder"
    • removedInput schema / properties / page_size / title
      Removed value: -"Page Size"
    • removedInput schema / title
      Removed value: -"outlook_list_inbox_deltaArguments"
  2. Addedv1.14.0
  3. Removedv1.12.0
  4. First observedv1.11.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true; the description adds substantive behavior beyond that: the ~10x cost advantage after the first call, the tombstone semantics of is_deleted=True, and the requirement to drain immediately when has_more=True. These are non-obvious operational traits an agent cannot infer from the schema.

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?

Front-loaded with the core scope statement, then cost rationale, then a concrete example, then edge-case flags. Every sentence carries distinct information; the repeated delta_token mention in the example and the has_more line serve different purposes (syntax vs. control flow).

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 responsibly discloses the key response fields (delta_token, is_deleted, has_more) and how to act on them. The gap is minor: folder and page_size behavior is never described, so a caller cannot tell how scoping or paging interacts with delta tracking.

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

Parameters3/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 full burden. It explains delta_token thoroughly via the example sequence, but folder (default 'inbox') and page_size (default 50) are never mentioned, leaving two of three parameters undocumented anywhere.

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 with an explicit scope qualifier ('List only inbox changes since the last call'), which immediately separates it from a full snapshot. It also names the sibling it replaces, outlook_list_inbox, so the agent can distinguish them 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 prescribes when to use it ('polling/recurring agents') and when not ('Use outlook_list_inbox for one-shot snapshots'), naming the alternative. The concrete first-call/next-call example removes any remaining ambiguity about how to sequence calls.

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