macOS/Cloud hosted tool policy enforcement system for Outlook, Slack, and Calendar integrations with MCP-based tool execution and permission hooks
Sentient OS exhibits significant definition quality gaps across 27 tools. While tool names follow verb_noun conventions (outlook_calendar_read, send_email, slack_send_message), descriptions are present but often generic and lack actionable context. Critical issues: (1) Input schemas visible in the provided sample show basic type declarations but lack comprehensive constraint documentation (e.g., no enums for operation types, no min/max for numeric fields). (2) Many parameters lack sufficient description depth, 'purpose' in outlook_calendar_read is described as 'Purpose of the read operation (iterative or context)' but does not explain when to use each value or consequences. (3) Output schemas are not documented in the provided source, LLMs cannot predict what fields are returned. (4) Error handling guidance is absent, no recovery hints or error classification. (5) Duplicate/overlapping tools (e.g., send_email, outlook_send_mail, outlook_create_draft, draft_email) suggest composition issues. (6) Security-sensitive operations (calendar creation, email sending) lack confirmation/dry-run patterns. Baseline: 94% of A+ tools have docstrings; this server has descriptions but they are shallow. Average param description in A+ tools is 72 chars; many here are 30-50 chars.
Create a forward draft for an email message
Create a reply draft for an email message
Create an email draft with subject, body, and recipients
Fetch a specific calendar event by event ID
Forward an email message to recipients
Get list of granted OAuth scopes
Get mailbox configuration settings
Duplicate and overlapping tools reduce clarity and force LLM disambiguation. send_email, outlook_send_mail, draft_email, outlook_create_draft, and outlook_send_mail all perform similar operations with inconsistent naming. This violates the single-responsibility principle and wastes LLM reasoning cycles.
Output schemas are not documented. LLMs cannot predict what fields are returned by tools like outlook_calendar_read, list_events, or get_profile. This forces agents to guess at response structure and breaks tool chaining when downstream tools expect specific fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Get current user profile information
Get user profile details
List calendar events within a date range with ordering and limit parameters
List email messages with filtering, ordering, and pagination
Create a calendar event with subject, time, attendees, body, and location validation
Read calendar events within a specified time window with optional purpose and context validation
Search calendar events with query, date range, limit, offset, and ordering parameters
Create an Outlook email draft
Create an Outlook reply-all draft
Create an Outlook reply draft
Search emails with query, date range, limit, offset, and cursor parameters
Forward an Outlook email message
Send an Outlook email message
Read a calendar resource by URI
Reply to an email message with body content validation
Send an email message with validation of recipients and body content
Create a new Slack conversation/channel
Schedule a message to be sent to Slack at a future time
Send a message to a Slack channel with message hash validation
Send a Slack message draft
Parameter descriptions lack actionable constraints. 'purpose' in outlook_calendar_read is described as 'Purpose of the read operation (iterative or context)' but does not explain when to use each value, what each implies, or consequences. No enums declared for constrained values. No min/max for numeric fields like limit, offset, top.
No error handling guidance. Tools like send_email and slack_send_message lack recovery hints. If a send fails, the LLM has no guidance on whether to retry, ask the user, or escalate. No error classification (retryable vs. user-fixable vs. fatal).
Destructive operations (send_email, outlook_calendar_create, slack_send_message) lack confirmation or dry-run patterns. Agents can irreversibly send emails or create calendar events without a safety gate. No idempotency guarantees documented.