This server implements 8 Outlook/Teams tools with HTTP transport but critical gaps in schema visibility, parameter descriptions, and output documentation prevent confident production deployment. While naming conventions are sound (verb_noun structure: list_messages, get_message, send_message, create_draft, list_calendar_events, get_calendar_event, create_calendar_event, search_people), the source code provided does NOT contain the actual tool registration with input schemas or detailed parameter descriptions. The tools are INFERRED from directory structure (src/tools/mail.ts, src/tools/calendar.ts, src/tools/people.ts) but explicit tool definitions with Zod schemas, descriptions, and output documentation are not visible in the provided excerpts. Per hard scoring rule: 'If you cannot see the actual tool definition in the source (only inferred): cap that tool's overall at 50.' Additionally, parameter descriptions and output schemas cannot be verified from the code snippet. The Dockerfile and server.ts show solid infrastructure (Node 22, express, StreamableHTTPServerTransport, bearer auth, rate limiting, keep-alive for SSE, CORS), but tool-level quality cannot be assessed without schema visibility.

• Provide complete tool definitions from src/tools/mail.ts, src/tools/calendar.ts, and src/tools/people.ts showing explicit Zod schema registration, parameter types, and descriptions.
• Add 50-200 character descriptions to every tool explaining WHAT it does, WHEN to use it, and WHEN to prefer it over similar tools (e.g., distinguish list_messages from search_messages).
• Document all input parameters with type, required/optional status, constraints (min/max/enum), and format hints. Example: 'folder: string (required, one of: inbox, drafts, sent, archive), which folder to list from'.
• Document output schemas for each tool. Example for list_messages: 'Returns {messages: [{id, sender, subject, timestamp, preview}], total_count, next_cursor}'.
• Add pagination (limit, offset/page, total_count, next_cursor) to list_messages and list_calendar_events to prevent context explosion.
• Implement dry-run or confirmation pattern for send_message and create_calendar_event. Example: add a 'dry_run: boolean' param or a separate 'confirm_send_message' tool.
• Add error messages that guide recovery. Instead of returning raw error codes, return: 'User not found. Try search_people() with a partial name, or provide an exact email address.'
• Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to all tools to signal intent to clients. Mark send_message and create_draft as destructiveHint=true.
• Document parameter relationships. Example: if create_calendar_event accepts optional attendees, explain format (email list? Display name + email?).

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry