Aep

Adobe's MCP lets your agent *read* Experience Platform. This one lets it work.

61 tools across 14 categories. Full read AND write. Self-hosted, Apache-2.0, no invitation required. Experience Platform, Journey Optimizer and Customer Journey Analytics — from one OAuth credential.

Ingest a batch → compose a schema → activate an audience → honour an erasure. Every mutation gated by a fail-closed write guard that asks Adobe what kind of sandbox it's in.

⚡ Do it in three lines

claude mcp add aep \

-e AEP_CLIENT_ID=... -e AEP_CLIENT_SECRET=... \ -e AEP_ORG_ID=...@AdobeOrg -e AEP_SANDBOX_NAME=your-dev-sandbox \ -- npx -y @focusgts/aep-mcp-server

Then just ask your agent:

*"Create a schema with the Demographic Details field group, then a dataset on it."*

*"Ingest this NDJSON file and tell me when the batch lands."*

*"Build an audience of customers who bought twice this quarter and activate it."*

*"Delete every record for this email address — dry run first."*

Writes are off until you ask for them, and safe mode only unlocks sandboxes Adobe classifies as development.

The loop that makes it different

flowchart LR

A["📐 Compose schema from field groups"] --> B["🗂️ Create dataset"] B --> C["📥 Ingest batch · upload · complete"] C --> D["🎯 Activate segment → destination"] D --> E["🧹 Govern erasure · expiration · quota"] E -. "re-audit the tenant" .-> A

Adobe's first-party gateway can *tell you* what's in your Experience Platform tenant. It cannot create a dataset, land a batch, activate an audience, or submit an erasure. This does — and does it behind a guard that fails closed.

🧠 How it works

flowchart LR

A["AI agent (Claude · Cursor · Copilot)"] -- MCP / stdio --> B["aep-mcp-server 61 tools"] B --> W{{"write guard fail-closed"}} W --> C["Schema Registry · Catalog Ingestion · Lifecycle · Privacy"] C --> F["Your AEP sandbox platform.adobe.io"] B --> J["Journey Optimizer read-only"] J --> K["ajo campaigns"] B --> Q["Customer Journey Analytics read-only, no sandbox"] Q --> L["cja.adobe.io"]

The agent calls tools; the server talks to live Adobe APIs over OAuth Server-to-Server. The write guard sits in the HTTP client, not in each tool, so all 61 inherit it and none can forget it. Blocked calls never reach Adobe.

🛡️ Safe by default

Three postures. Reads are never restricted in any mode.

How `safe` decides — and why it's not the sandbox name.

A production sandbox can be called anything, and a sandbox called prod might not be production. Only Adobe's type field from the Sandbox Management API decides.

It fails closed. If the type can't be determined — the credential can't read sandbox metadata, the API errors, startup hasn't finished — writes are blocked. A credential must not earn write access by being *less* capable. An unrecognised AEP_MODE falls back to safe, so a typo can never grant production writes.

A sandbox literally named `prod` is refused unconditionally, before mode resolution — so AEP_MODE=production does not lift it. Override with AEP_I_UNDERSTAND_THIS_WRITES_TO_PROD=true only if that really is your sandbox's name. The inference is deliberately asymmetric: trusting a name to *allow* a write is unsafe, trusting one to *deny* a write is safe, because the worst case is a refusal you can override on purpose.

Mutations are off entirely unless AEP_ALLOW_MUTATIONS=true. That is separate from AEP_MODE on purpose: choosing a write mode should not also mean "yes, you may change my data".

Startup always states the active posture:

SAFE MODE — sandbox is a development sandbox, so writes are ENABLED.

SAFE MODE — sandbox is PRODUCTION, so writes are BLOCKED. Reads work normally. SAFE MODE — sandbox type could not be confirmed, so writes are BLOCKED (fail-closed). READ-ONLY MODE — no write, update, or delete will be performed in any sandbox. PRODUCTION MODE — writes permitted against ANY sandbox, including production.

Per-tool confirmation gates

Writes are not *uniformly* gated — uniform gating makes an agent useless. Gates sit where an action is irreversible and wide-reaching, and every one is checked before any network call:

Confirmations name their target. A phrase carrying the dataset id — and for record delete, a hash of the identities too — cannot be copied from one call to another. A generic "I understand this is irreversible" approves *any* deletion once you've typed it once.

Identity values never leave the process. aep_create_record_delete returns a count, the namespace names, and a digest — never the email addresses or device IDs you passed it. A record-delete request is by nature a list of real people; a tool that echoes them copies them into every transcript and log sink it touches.

Batch creation and file upload are ungated on purpose: those writes are additive and recoverable. An unwanted batch can be left uncompleted, and data that did land can be removed with the Data Hygiene tools.

Tool annotations

Every tool ships MCP annotations — readOnlyHint, destructiveHint, idempotentHint, openWorldHint — derived from the same metadata that builds its description, so the two cannot drift.

These are hints *for the client*, not enforcement — the guards above enforce. Their value is that a client like Claude Desktop uses destructiveHint to decide when to interrupt and ask a human. Without them aep_delete_profile looks identical to aep_list_schemas. A test asserts the destructive list exactly, so a ninth is a deliberate act rather than an oversight.

🛠️ The 61 tools

All prefixed aep_, verb_noun naming. 🔒 changes state · 🔥 destructive.

Data modelling & ingestion

Schemas (4)

• list_schemas
• get_schema
• create_schema 🔒
• update_schema 🔒

Datasets (4)

• list_datasets
• get_dataset
• create_dataset 🔒
• delete_dataset 🔥

Ingestion (7)

• create_batch 🔒
• upload_batch_file 🔒
• complete_batch 🔥
• get_batch_status
• list_batches
• abort_batch 🔥
• revert_batch 🔥

Sources (2)

• list_sources
• list_dataflows

Query Service (3)

• run_query 🔒
• get_query_status
• list_queries

Profiles, audiences & activation

Identities (2)

• list_identity_namespaces
• get_identity_graph

Profiles (4)

• get_profile
• get_profile_by_identity
• preview_profile
• delete_profile 🔥

Segments (5)

• list_segments
• get_segment
• create_segment 🔒
• estimate_segment_size
• delete_segment 🔥

Destinations (3)

• list_destinations
• create_destination_connection 🔒
• activate_segment 🔒

Governance — privacy, lifecycle & event routing

Privacy Service (6)

• create_privacy_job 🔒
• get_privacy_job
• list_privacy_jobs
• cancel_privacy_job 🔒
• get_privacy_job_results
• list_privacy_namespaces

Data Hygiene (9)

• create_record_delete 🔥
• get_work_order_status
• list_work_orders
• get_data_lifecycle_quota
• create_dataset_expiration 🔥
• get_dataset_expiration
• list_dataset_expirations
• update_dataset_expiration 🔥
• cancel_dataset_expiration 🔥

Workflows these unlock

Ingest end to end — create_schema → create_dataset → create_batch → upload_batch_file → complete_batch → get_batch_status

Build and activate an audience — create_segment → estimate_segment_size → list_destinations → create_destination_connection → activate_segment

Honour an erasure request — get_profile_by_identity → create_record_delete → get_work_order_status

Retire data on a schedule — create_dataset_expiration → list_dataset_expirations → update_dataset_expiration → cancel_dataset_expiration

What's actually been run against a live tenant is recorded per tool in docs/VALIDATION-MATRIX.md — including the surfaces that are documented-and-mocked but deliberately never executed, and why.

Adobe Journey Optimizer (2)

AJO is a separate Adobe product, licensed separately — hence the ajo_ prefix, so an entitlement failure reads as one.

Campaigns

• ajo_list_campaigns
• ajo_get_campaign

Campaigns is the only AJO surface reachable on our tenant. Journeys, messages, channel surfaces, content templates, fragments, offers and decisions all return an HTML 404 — the gateway has no such route — so they are deliberately not implemented.

Writes are absent on purpose. The routes exist, but shipping an unva