Adobe Target and MCP: Two Ways to Put It to Work

There is real buzz around the Model Context Protocol right now. The question is not whether to use it with Adobe Target, but how. Here is an honest look at the two good answers.

There is a lot of energy in the community right now around the Model Context Protocol, and for good reason. MCP gives a large language model a clean, governed way to actually do things in Adobe Target instead of just talking about them. You can ask an agent to spin up an experience targeting activity, QA it against your rules, pull the reporting, and summarize what it found, all in natural language. For anyone who runs an optimization program, that is a real shift in how the day to day work gets done.

The question I keep getting is not whether to use MCP. It is how. And there are really two good answers. You can build the connection yourself, or you can bring in a platform that already has it wired up. Both are legitimate. Which one fits depends on your team, your appetite for owning infrastructure, and how quickly you want to be live. Let me lay out both honestly.

What MCP gives you in the first place

Before the two paths, it helps to be precise about what MCP is. It is a protocol. Adobe exposes MCP endpoints for Target and Analytics, an LLM connects to them through an MCP client, and the model can then call a defined set of tools to read and write within your Adobe environment. The protocol handles the plumbing between the model and Adobe. What it deliberately does not do is decide how you govern, log, or productize that access. Those are choices you make on top of it.

That is not a shortcoming. It is the right separation of concerns for a primitive, and it is a credit to how Adobe has approached this. It just means the interesting decisions live in the layer above the protocol, which is exactly where the two paths diverge.

Path one: build it yourself

The direct path is to connect your own MCP client and your own model straight to Adobe over OAuth. If your team has engineering capacity and wants to own the stack, this is a genuinely strong option, and I would not talk anyone out of it.

You get the widest provider choice available today. Because you bring your own MCP host and model, you can run whichever model your organization has already approved, whether that is a hosted commercial model or something in your own cloud. You get the shortest data path, since traffic goes from your host to Adobe and to your model with nothing in between. You keep the smallest dependency footprint, which procurement and risk teams tend to love. And there is no platform license to buy.

The tradeoff is that everything beyond the raw Adobe connection is yours to build and run. Authentication and token hardening are on you. Observability is on you, and this is the one to think hardest about, because a bare MCP connection does not give you a record of what was prompted, what the model answered, or which Adobe calls it made. If you want that audit trail, and most enterprises do, you instrument it yourself. Shared prompt libraries, versioning, approval, and any guardrails that keep a less technical user inside the lines are also things you design and maintain. None of that is exotic. It is just real work, and it is ongoing.

Build it yourself if you have the engineering bandwidth, you want maximum control and provider flexibility, and you are comfortable owning the governance layer that sits above the protocol.

Path two: bring in a platform like MiaProva

The other path is to use a platform that already has the MCP tooling built, governed, and running, and this is where I get excited. That is what we have done with MiaProva, and it turns MCP from a promising primitive into something your team can put to work in earnest this week.

Start with time to market, because it is the headline. There is no build cycle. The Adobe MCP connection, the model orchestration, the logging, and the governance are already there, so the distance between “this looks interesting” and “my team is running this on real activities” is measured in days, not a project plan. You bring your own key and your own agent setup, point it at your Adobe environment, and you are working.

Then there is governance, built in rather than bolted on. Every prompt, response, and Adobe API call is captured and tied to a user, an agent, and a timestamp, so you have a full audit trail from the very first session. Prompts live in shared, versioned libraries with central approval, so your best patterns get reused instead of rediscovered and nothing goes rogue. You decide which features and agents each team can use, with guardrails around them. If you have ever had to answer a security or compliance question about who can do what with AI in your stack, having that in place on day one is a genuine relief.

My favorite part is the curated prompt and agent library. Nobody does their best work staring at an empty prompt box. MiaProva ships with a well-curated set of packaged prompts and purpose-built agents aimed at the work optimization teams actually do: standing up and QAing activities against your rules, reading and explaining reporting, analyzing audiences, reconciling metrics across CJA and Analytics, and catching the things that quietly wreck a test. One of my favorites is an agent that watches for sample ratio mismatch, exactly the kind of issue you want surfaced before it costs you a decision. These are expert built and ready to run, so your team starts from a strong, proven baseline and tunes from there instead of inventing prompt craft from scratch.

And all of it lives in context. MCP for Target is powerful, but Target is one part of an optimization program. MiaProva brings the MCP tooling into the same place you already manage that program, alongside Customer Journey Analytics, Adobe Analytics, the Experience Platform, and Real Time CDP. So an agent is not editing an activity in isolation. It is working where you plan tests, watch audiences, reconcile metrics across CJA and Analytics, and monitor your Platform data. That context is the difference between a clever MCP demo and something that moves your whole optimization practice forward.

I will still be straight about the tradeoffs, because the community deserves that. You are adding a party to the trust and data path, there is a platform license, and today the model side runs on Google Cloud with Gemini, with support for more providers expanding. If your priority is the leanest possible footprint or a specific model you must run today, weigh that against everything you get on day one without building it yourself.

Bring in a platform if you want to be live today, you want audit and governance in place from the start, and you want MCP working inside your broader optimization program with a curated head start rather than a blank page.

The point is to start

Here is what I would leave you with. MCP is the foundation, and Adobe has done the important work of exposing it cleanly and openly. The value is not in the protocol by itself. It is in how you fit it into the way your team actually optimizes. If you have the engineering appetite, build to suit and own the stack. If you want everything you need in one place and want to put AI to work across your program today, that is where a platform like MiaProva earns its keep.

Either way, the worst move is to wait. Pick the path that matches your team, and start putting MCP to work.