Skip to main content
Glama
outlook-mcp

outlook-mcp

by ajs117

sender_summary

Groups every message in a folder by sender and reports counts plus opened versus unread rates, giving evidence to decide which senders to keep or delete before acting.

Instructions

Group a whole folder by sending address and report, per sender, how many messages there are and how many were actually opened.

This is the tool to reach for before proposing anything for deletion. A sender's read rate is measured evidence of whether the mailbox owner wants their mail; guessing from the brand name is not, and gets it wrong.

Returns rows {sender, brand, domain, count, read, unread, read_pct, newest, oldest, sample_ref}, biggest sender first. brand is a heuristic display label — never group or delete by it. brand_shared: true marks a row whose brand label also belongs to another address in the result (e.g. a billing subdomain and a marketing subdomain of one company): those are different senders and must stay separate.

Args: folder: folder id or well-known name. min_count: drop senders with fewer than this many messages. top: return at most this many sender rows (after sorting by count). max_results: cap on messages scanned. unread_only: summarise only unread mail.

Input Schema

NameRequiredDescriptionDefault
topNo
folderNoinbox
min_countNo
max_resultsNo
unread_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses return fields, sorting order, the max_results scan cap, and important caveats about heuristic brand labels and shared brands. It does not cover error behavior or permissions, but for a read-only summary tool this is substantially transparent.

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?

The purpose is front-loaded, then usage rationale, return shape, and caveats follow in a logical order. The length is justified by the grouping semantics and the brand-label warning.

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?

No output schema or annotations exist, yet the description explains the returned row fields, ordering, and the key grouping caveat around brand and brand_shared. That is enough for an agent to invoke and interpret the summary correctly.

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 description coverage is 0%, but the Args block explains all five parameters, including folder identification, min_count filtering, top row limits, max_results message scanning, and unread_only. This adds clear meaning beyond the bare schema titles and defaults.

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: group a folder by sending address and report per-sender message/read counts. The scope is precise enough to distinguish it from generic message-listing or folder-summary siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use it before proposing deletion and explains why read-rate evidence matters. It does not name sibling alternatives such as find_newsletters or protective-sender tools, so it stops short of full when/when-not routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.