{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/email-agent-mcp-startup-readiness","id":"email-agent-mcp-startup-readiness","slug":"email-agent-mcp-startup-readiness","title":"Verify Email Agent Tools Before the First Scheduled Turn","description":"Gate a headless task on actual tool availability and a read-only brand check. A startup state machine and cold-start rehearsal.","dek":"Gate a headless task on actual tool availability and a read-only brand check. A startup state machine and cold-start rehearsal.","category":"Agent Operations","topics":["Migma","email marketing","agent operations"],"publishedAt":"2026-09-18","updatedAt":"2026-09-18","lastVerifiedAt":"2026-09-18","readingMinutes":4,"author":"Marketing Wiki Research Automation","reviewer":null,"featured":false,"sources":[{"title":"Migma: MCP server","url":"https://docs.migma.ai/mcp-server?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-agent-mcp-startup-readiness"},{"title":"Anthropic: Claude Code v2.1.274 release","url":"https://github.com/anthropics/claude-code/releases/tag/v2.1.274"}],"wordCount":751,"body":"A scheduled agent should verify that Migma's required tools are available before attempting its first creative action. A process that starts successfully can still begin a turn before an MCP connection has finished, or discover a tool that its granted permissions cannot use.\n\n> **Editorial disclosure:** Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 18, 2026.\n\n> **Affiliation disclosure:** Marketing Wiki’s commissioning maintainer also maintains Migma. This guide is published directly by automation without independent review.\n\nThe official [Claude Code v2.1.274 release](https://github.com/anthropics/claude-code/releases/tag/v2.1.274), dated September 17, adds `CLAUDE_CODE_MCP_STARTUP_WAIT_MS` for first-turn waiting in non-interactive sessions and fixes a case where a cloud session began before SDK-hosted MCP tools arrived. This is a client release, not a Migma outage or a universal cure for connection failures.\n\nMigma's [MCP guide](https://docs.migma.ai/mcp-server?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-agent-mcp-startup-readiness) documents context and capability checks, brand discovery and troubleshooting for stale tools. We recommend making a read-only context check a separate readiness condition in unattended email work. This confirms something more useful than a green “process running” status without creating a draft merely to test access.\n\n## Model startup as a sequence of facts\n\nUse these application states as an original design proposal; they are not Migma API status names:\n\n```text\nprocess_started\n  -> connection_observed\n  -> required_tools_discovered\n  -> read_only_brand_check_passed\n  -> task_may_begin\n```\n\nEvery transition needs evidence. Connection observation may come from the client's own diagnostics. Tool discovery should identify the exact operation the task needs. The brand check should return the intended workspace and brand, rather than merely proving that some account is reachable.\n\nKeep readiness separate from authority to act. A successful context read does not grant permission to send, modify audiences or schedule a campaign. Those operations still depend on the task's approved scope and the connection's permissions.\n\n## Use a cold-start rehearsal\n\nA fictional agency runs a morning draft-preparation job for one brand. Its rehearsal starts a fresh client rather than reusing yesterday's warm session. The test records client version, transport, connection start, required-tool availability and the successful brand check.\n\nExercise three conditions: normal startup, deliberately delayed availability in a controlled harness, and an unavailable required tool. The harness should withhold the creative step until readiness succeeds. If the deadline expires, save an understandable blocked result and stop the job before any write.\n\nDo not “recover” by asking a different connected brand to supply context. A fallback that changes identity is a different task, not a successful retry. Likewise, switching from remote to local MCP may change configuration and credential ownership; it deserves an explicit operational decision.\n\n## Distinguish waiting from denied permission\n\n| Observation | Interpretation to investigate | Safe response |\n| --- | --- | --- |\n| Tool absent during connection | Discovery may be incomplete | Wait within the configured startup budget |\n| Tool still absent after readiness deadline | Configuration or discovery problem | Stop and preserve diagnostics |\n| Read-only context names another brand | Wrong target or scope | Stop before drafting |\n| Tool call reports insufficient scope | Permission boundary | Route to the connection owner |\n| Generation already returned an operation ID | Creative work began | Track that operation rather than restarting startup |\n\nClaude Code's same release also improves reporting for an MCP insufficient-scope response. That supports separating permission diagnosis from sign-in expiry. It does not authorize broadening a key just to make the morning task run.\n\n## Choose a budget from the job's purpose\n\nThe startup wait setting controls a particular client behavior. It is not the remote generation deadline, the campaign delivery deadline, or proof that every deferred tool is present. Record the chosen value and why it leaves enough time for the remaining job.\n\nFor a draft-only morning task, missing the preparation window may justify reporting “draft preparation blocked.” It should not justify skipping readiness and generating from stale context. Keep the failure visible enough that a human can resume the same intended work later.\n\nThe [generation waiting guide](/articles/email-generation-polling-deadline-budget) begins after a remote operation exists. This guide ends before the first creative write. Keeping the two boundaries distinct helps avoid duplicate generations caused by treating an unknown startup state as a failed job.\n\nNo Claude Code process, MCP connection or Migma generation was exercised for this article. The state machine is a proposed integration control supported by current client and server documentation. Rehearse the exact installed client and configuration before relying on the control for unattended work."}