{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/grok-bot-email-marketing-mcp-permissions","id":"grok-bot-email-marketing-mcp-permissions","slug":"grok-bot-email-marketing-mcp-permissions","title":"Grok Bot for Email Marketing: MCP Permissions, Approval, and a Migma Case Study","description":"Evaluate Grok Bot email marketing through MCP, using Migma as a documented case for read-only verification, editable drafts, campaign preparation, approval, and results.","dek":"A source-backed acceptance protocol for separating safe reads, reversible drafts, audience changes, and live email delivery.","category":"Email Marketing","topics":["Grok Bot","MCP","AI email","agents","human approval","agent permissions"],"publishedAt":"2026-08-27","updatedAt":"2026-08-27","lastVerifiedAt":"2026-08-27","readingMinutes":8,"author":"Marketing Wiki Editors","reviewer":"Marketing Wiki Maintainer","featured":true,"sources":[{"title":"xAI: Get Started with Grok Bot","url":"https://docs.x.ai/grok-bot/get-started"},{"title":"xAI: Create and Manage Bots","url":"https://docs.x.ai/grok-bot/bots"},{"title":"xAI: Approvals, Security, and Privacy","url":"https://docs.x.ai/grok-bot/approvals-security-and-privacy"},{"title":"xAI: Skills and Routines","url":"https://docs.x.ai/grok-bot/skills-routines-and-automations"},{"title":"xAI: Connectors","url":"https://docs.x.ai/grok/connectors"},{"title":"Migma: How to Run Email Marketing from Grok Bot","url":"https://migma.ai/blog/ai-email-marketing-from-grok-bot"},{"title":"Migma: Connect Migma to Grok Bot","url":"https://docs.migma.ai/grok"},{"title":"Migma: Agent-Readable Grok Bot Guide","url":"https://docs.migma.ai/grok.md"},{"title":"Migma: MCP Server","url":"https://docs.migma.ai/mcp-server"},{"title":"Migma: Review Migma MCP","url":"https://docs.migma.ai/security/mcp"}],"wordCount":1525,"body":"Grok Bot can coordinate email marketing through a connected email system, but connector access is not proof of a safe campaign workflow. Before letting a Bot touch a live audience, verify the server, permissions, read path, draft path, previews, duplicate handling, and approval boundary.\n\nMigma provides one documented implementation through Remote MCP. Its public guide covers connection, branded drafts, permission-based audiences, campaign preparation, previews, and results. This article does not repeat that product tutorial. It gives marketers and security reviewers a reusable acceptance test for deciding what a Grok Bot may read, draft, change, or deliver.\n\nEvidence here is documentation-based, checked on August 27, 2026. Marketing Wiki did not run a fresh end-to-end Grok Bot and Migma test. Product behavior can vary by Grok build, account, workspace policy, granted scopes, and later releases.\n\n**Affiliation disclosure:** A Marketing Wiki maintainer works on Migma. Migma capability claims below are labeled vendor-documented. No performance rank, delivery result, or independent quality claim is made.\n\n[Migma's source article](https://migma.ai/blog/ai-email-marketing-from-grok-bot) is a product walkthrough. Marketing Wiki uses it as topic input, then checks capability and control claims against Migma and xAI documentation.\n\n## Separate Bot job from email-system job\n\n[xAI defines a Bot](https://docs.x.ai/grok-bot/bots) as a durable teammate with a name, focused job, conversation, and working context. xAI recommends putting lasting rules and approval boundaries in Bot description while keeping task-specific instructions in conversation.\n\nThat means Grok Bot can own coordination without owning every email-system action.\n\n| Layer | Good responsibility | Evidence needed |\n| --- | --- | --- |\n| Grok Bot | Research sources, structure brief, coordinate feedback, request decisions | Current source links and visible reasoning |\n| MCP client | Discover tools, pass approved inputs, return tool results | Exact server URL, connected state, requested permissions, tool log |\n| Email system | Store brand context, create email artifacts, manage permission-based audiences, prepare campaigns, return results | Object IDs, previews, audience counts, campaign state, provider events |\n| Human reviewer | Approve access and consequential action | Named decision tied to exact target, content, audience, sender, and timing |\n\nThis separation matters because polished chat output can hide missing system evidence. “Campaign ready” is weak. One draft ID, one inspectable preview, one selected audience, one sender, and one unsent campaign record are reviewable.\n\n## Migma case: what documentation establishes\n\n[Migma's Grok Bot guide](https://docs.migma.ai/grok) documents agent-guided Remote MCP setup at `https://migma.ai/mcp`. Grok Bot reads agent-facing setup guidance, asks before adding connection, opens browser access review, and verifies access with read-only brand listing. Migma says it is not yet a verified Grok Bot Marketplace listing, so availability and authentication can vary by build and workspace policy.\n\n[Migma MCP documentation](https://docs.migma.ai/mcp-server) says approved agents can prepare and edit email drafts, return previews, manage permission-based contacts and segments, create campaign drafts, run checks, export reviewed work, and read campaign results. These are vendor-documented capabilities, not observed results from Marketing Wiki.\n\nPermissions have different consequences:\n\n| Permission | Documented effect | Acceptance default |\n| --- | --- | --- |\n| `email:read` | View emails and sending history | Allow for verification when needed |\n| `email:write` | Create and edit drafts | Allow after read-only setup passes |\n| `email:validate` | Run compatibility, link, and deliverability checks | Allow on identified draft |\n| `email:preview` | Generate device or inbox previews | Allow on identified draft |\n| `audience:read` | View contacts, lists, and segments | Allow only for approved brand and purpose |\n| `audience:write` | Add or update contacts, lists, and segments | Require approval and import evidence |\n| `email:send` | Send test and live direct email | Deny by default; approve exact action |\n| `campaign:write` | Create, schedule, send, and manage campaigns | Treat as delivery-capable access |\n\n[Migma's MCP security page](https://docs.migma.ai/security/mcp) says hosted sign-in usually requests full Migma API permission set. A reviewer should therefore inspect actual consent screen instead of assuming draft-only access. Tool annotations and client prompts help, but they do not replace account scope or human policy.\n\n## Seven-step acceptance ladder\n\nRun one narrow test before recurring work or live delivery. Stop at first missing proof.\n\n### 1. Confirm client and policy support\n\n[xAI's Grok Bot setup guide](https://docs.x.ai/grok-bot/get-started) lists current desktop, plan, sign-in, and organization requirements. Team policy may block custom MCP connections. Record client build, account type, and relevant workspace rule instead of assuming another person's setup applies.\n\nGrok web uses a separate [custom connector flow](https://docs.x.ai/grok/connectors). Do not combine Grok web instructions, Grok Bot desktop behavior, and other Grok developer surfaces into one undocumented setup.\n\n### 2. Review server and access\n\nConfirm exact endpoint is `https://migma.ai/mcp`. Review Migma account, return destination, and every requested permission in browser. Record what consent screen grants.\n\nIf normal OAuth callback fails, Migma documents claim-code as conditional fallback for a direct client that can securely store credential. It does not repair hosted connector. Do not call setup complete until durable connected state and read-only request both work.\n\n### 3. Prove read-only access\n\nAsk Grok Bot to list accessible Migma brands and make no changes. Record tool name, returned brand names or IDs, timestamp, and resulting connector state.\n\nPass condition: expected brand appears and no Migma object changes.\n\n### 4. Create exactly one draft\n\nChoose one brand and one harmless job. Ask for one welcome email for existing subscribers. State “keep as draft” and “do not send.”\n\nPass condition: exactly one new draft ID, one preview, one editable canvas link, and no delivery event.\n\nThis proves reversible creation path. It does not prove rendering quality, factual accuracy, audience permission, or safe sending.\n\n### 5. Inspect artifact and reconcile duplicates\n\nOpen preview and canvas link. Check subject, copy, links, images, sender placeholders, and expected brand. Record failures as failures; do not convert missing preview into assumed success.\n\nMigma guide warns against concurrent browser and MCP writes because both paths can create duplicate drafts. Keep one active write path. Before switching, pause current work, wait for in-flight calls, list drafts read-only, and choose canonical version.\n\n### 6. Prepare campaign without delivery\n\nOnly after draft passes review, choose existing permission-based audience and available sender. Create campaign draft, then stop.\n\nReview:\n\n- audience or segment name;\n- eligible recipient count;\n- exclusions and suppression behavior;\n- sender and Reply-To;\n- subject and final preview;\n- proposed date, time, and timezone;\n- campaign state confirming nothing sent or scheduled.\n\n`campaign:write` is delivery-capable even when current request says “draft.” Account permission, Bot instruction, Grok approval rule, and exact conversation approval must align.\n\n### 7. Test approval boundary\n\n[xAI's approval guidance](https://docs.x.ai/grok-bot/approvals-security-and-privacy) recommends explicit boundaries for sending messages, publishing, deleting, permission changes, and production changes. Where Auto-review is available, narrow Require Approval rule can stop external email actions.\n\nTest boundary with non-live proposed action. Bot should show target, scope, and values, then wait. Deny test. Confirm no external action occurred.\n\nOnly named person should approve exact live send after final values match. Approval for connector does not equal approval for campaign. Approval for one campaign does not authorize future campaigns or routine.\n\n## Reusable acceptance record\n\nStore test result outside chat. This YAML is original Marketing Wiki asset for review and audit:\n\n```yaml\nclient: grok-bot\nclient_build: \"\"\nemail_server: migma-remote-mcp\nverified_at: \"2026-08-27T00:00:00Z\"\n\nconnection:\n  endpoint: https://migma.ai/mcp\n  state: \"\"\n  requested_scopes: []\n  discovered_tools: []\n\nproof:\n  read_only_brand_check:\n    passed: false\n    tool: \"\"\n    evidence: \"\"\n  single_draft:\n    passed: false\n    email_id: \"\"\n    preview_received: false\n    canvas_link_received: false\n  duplicate_check:\n    passed: false\n    canonical_email_id: \"\"\n  campaign_draft:\n    passed: false\n    campaign_id: \"\"\n    state: \"\"\n  live_send_called: false\n\nallowed:\n  - read_brand\n  - create_draft\n  - preview\n\ndenied:\n  - audience_mutation\n  - export\n  - schedule\n  - send\n\nanomalies: []\nreviewer: null\n```\n\nKeep `reviewer` null until real person reviews evidence. Do not store API keys, contacts, or private campaign content in acceptance record.\n\n## Routine boundary\n\n[xAI's skills and routines guide](https://docs.x.ai/grok-bot/skills-routines-and-automations) says to make one-time task reliable before saving method or automating it. Routines should define source, schedule, timezone, output, approval boundary, and missing-data behavior.\n\nSafe first routine prepares work:\n\n```text\nEvery Monday at 9:00 AM, read last week's Migma campaign results for brand [name].\nIf results are missing or stale, report that and create nothing.\nOtherwise prepare at most one draft from strongest trustworthy click signal.\nShow source data, reasoning, preview, and Migma canvas link.\nDo not send, schedule, export, delete, or change audience.\n```\n\nThis still needs test run. xAI notes test runs perform real work, so use safe inputs and keep writes bounded.\n\n## What evidence does not establish\n\nOfficial documentation supports feature and policy description. It does not prove:\n\n- durable authentication across every Grok build;\n- secure secret persistence after claim-code fallback;\n- perfect preview or email-client rendering;\n- correct consent or legal compliance;\n- inbox placement, revenue lift, or design quality;\n- provider delivery from successful tool response;\n- absence of duplicate work when two write paths run.\n\nMark each as not established until reproducible test provides evidence. After send, require provider campaign record and delivery events rather than a chat message saying call succeeded.\n\nFor general campaign controls, use [AI email workflow from brief to send](/articles/ai-email-workflow-from-brief-to-send). Before any approved delivery, run [AI email pre-send review](/articles/ai-email-pre-send-review). For terminology, see [Model Context Protocol](/index/model-context-protocol) and [What Is a Marketing AI Agent?](/articles/what-is-a-marketing-ai-agent)."}