Outlook SNDS MCP server (stdio, zero dependencies). Exposes the Smart Network Data Services REST API behind a Microsoft-account OAuth (auth-code + PKCE, loopback) sign-in.
Five tools with complete schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (snds_authenticate, get_data_report). Descriptions are present (avg 180 chars) and explain WHAT the tool does, but lack WHEN to use it and dependency hints. Critical issue: get_data_report and get_ip_status lack documented output schemas, LLMs cannot plan downstream operations or extract structured data. Parameters in get_data_report have descriptions but lack format constraints (date regex, IP validation rules). No error recovery guidance. Auth tools (snds_authenticate, snds_sign_out) are well-described but lack confirmation/dry-run patterns for destructive operations.
Get the SNDS IP Data report (per-IP traffic and reputation metrics: RCPT/DATA commands, message recipients, spam filter result, complaint rate, trap hits, sample HELO/MAIL, comments). With no arguments it returns the most recent available report. Optionally pass a date (yyyy-MM-dd) for a specific day, and optionally an IPv4 address to filter to a single IP (a date is required to filter by IP). Calls GET /api/report/data/{date?}/{ip?}.
Get the SNDS IP Status report for the IPs you own — the set of IPs with an abnormal status at Outlook.com (e.g. Blocked, Bot, Junked) as of the last 24 hours. Calls GET /api/report/status/ip.
Check whether you are currently signed in to SNDS, which account is cached, and when the access token expires.
Sign in to Outlook SNDS. Opens your browser for a Microsoft-account login (OAuth 2.0 authorization-code + PKCE, loopback redirect) and caches the tokens for later calls. Run this once before fetching reports; tokens are refreshed automatically afterward.
Delete the cached SNDS tokens from disk (sign out). You will need to run snds_authenticate again to fetch data.
Output schemas not documented. get_data_report and get_ip_status return HTTP responses formatted as text, but LLMs cannot parse structure or plan downstream operations. No field definitions for report data (RCPT/DATA commands, complaint rate, trap hits, etc.).
Parameter format constraints missing. get_data_report 'date' param lacks regex pattern (yyyy-MM-dd); 'ip' param lacks IPv4 validation rule. Descriptions mention formats but JSON Schema lacks pattern/format fields. LLMs cannot validate before calling.
No error recovery guidance. formatResponse() returns HTTP status codes (404, 400, 200) but does not tell LLM what to do next. E.g., 'HTTP 404 Not Found, no data available for that query' does not suggest retry, check date format, or call snds_auth_status.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Destructive operation (snds_sign_out) lacks confirmation pattern. No dry-run or confirmation step before deleting cached tokens. Agents may accidentally sign out mid-workflow.
No dependency hints in descriptions. snds_authenticate description does not state 'Run this before calling get_data_report or get_ip_status.' get_data_report does not hint 'Call snds_auth_status first if unsure of login state.' Agents may call tools in wrong order.