Govern AI Outreach With MCP Approvals

Review access for each action: reads require matching permissions, record changes need previews and retry keys, and sends also require an active owner-reviewed policy. Keep consent, suppression, licensing, and jurisdiction checks in the review.

Which risk tier applies to each write?

Use tools/list to discover the tools available to your connection. Availability depends on the granted permissions and workspace access. Start with read scopes; ask a workspace administrator to review missing access rather than requesting broad permissions.

How should a team preview and approve a draft?

1. Build the candidate list from source-backed reads and deduplicate against CRM records and suppression.
2. Call the write with dry_run: true and a generated UUID idempotency_key. Review validation and policy responses without creating records.
3. Have the owner check audience, source provenance, claims, personalization, sender, consent and suppression, restricted uses and jurisdictions, and licensing before activating the send policy.
4. Retry with dry_run: false and the same key after the policy is ACTIVE. A repeated key returns the original result instead of a duplicate.

Signals -> Leads -> Enrichment -> Decision -> Outreach -> Pipeline

A shipment record supports research; it does not prove demand or permission to contact a person. Keep that caveat in the review note.

What does a send policy review require?

Before enabling sends, have an owner review the audience, sender, message claims, consent, suppression, applicable jurisdictions, licensing, and budget caps. Use an active standing policy_id for permitted sends and preview with dry_run: true. A standing policy may authorize multiple sends; it does not mean a person approves each message individually. Pause work when eligibility or authorization is unclear.

How do you audit and revoke?

Review access grants, policy changes, and available activity records before expanding access. Keep only redacted request IDs and operational metadata in shared notes. Remove the connection when the project ends or access is no longer needed; revoke and replace any credential that may have leaked.

What are common questions about MCP outreach governance?

Should every draft need approval?

Drafts need owner review; sends need an ACTIVE standing policy plus the policy’s human review before activation. Keep both steps even for small volumes.

What happens when the same write is sent twice?

Reusing the idempotency_key returns the first result. A new key creates a new record or send, so never rotate keys on retry.

Can a token be limited to drafts without sends?

Yes. Grant leads:create or campaigns:create without emails:send or sms:send. Missing send tools in tools/list confirm the boundary.

Which replies need a person?

Opt-outs, objections, referrals, and ambiguous or sensitive replies go to a person. Pause rules should stop further sends on bounces, complaints, and poor fit.

What belongs in the policy review record?

Account reason, source, contact role, message claims, sender, policy ID, idempotency key, reviewer, and next action.

When should access be removed?

Remove grants at project end, role change, vendor change, or any suspected leak. Keep the request_id history for the review.