ℹ
Purpose & Capability
The name/description (Outlook delegate via Microsoft Graph) align with the instructions: the docs explain delegated OAuth flows, required delegated Graph permissions, Exchange mailbox delegate commands, and use of the /users/{owner} endpoint. The skill asks for the expected credentials (client_id/client_secret) and owner/delegate emails. Minor inconsistency: registry metadata lists no required env vars/primary credential, but the SKILL.md expects a local config file containing the client_id/client_secret — this is plausible but not declared in metadata.
⚠
Instruction Scope
The SKILL.md instructs running several scripts (./scripts/outlook-token.sh, outlook-mail.sh, outlook-calendar.sh) and using a config path (~/.outlook-mcp/config.json) but the skill bundle contains no code files — those scripts are not present. That means following these instructions would require the user to create or fetch additional code from elsewhere. The doc also advises storing client_secret directly in a plaintext config file and using mail/calendar FullAccess or SendOnBehalf permissions — both are functional for the purpose but present clear security and privilege implications that the user must accept intentionally.
✓
Install Mechanism
No install spec and no code files are present; the skill is instruction-only, so nothing is automatically downloaded or written by an installer. That lowers installer risk but means the agent cannot actually run the referenced scripts unless the user or an external source supplies them.
ℹ
Credentials
Requested secrets (client_id and client_secret) are appropriate for OAuth delegated access and are proportionate to the stated functionality. However, the SKILL.md recommends storing client_secret in plaintext at ~/.outlook-mcp/config.json, and the Exchange commands require high privileges (Add-MailboxPermission, Set-Mailbox). The skill does not request unrelated credentials, but it does require the owner/admin to grant broad mailbox/calendar access — a high-privilege action that should be limited and audited.
ℹ
Persistence & Privilege
always is false and the skill does not request permanent platform-level privileges. It does instruct creation of a per-user config file and use of refresh tokens (offline_access) — meaning long-lived tokens may be stored locally. Combined with FullAccess or SendOnBehalf permissions, those tokens could be used to operate on the owner's mailbox until revoked, so the persistence implications are significant even if the skill itself is not marked always:true.