MCP in marketing: the work that needs a judgement each time
The useful question is not which marketing tasks an agent can do. It is which ones have an answer that stays the same, and which ones change with the circumstances.
The marketing work that needs a judgement each time is the work whose right answer changes with the circumstances: what to publish next, whether this month's search budget should go on that query, whether a claim in a draft is one you are willing to defend. Everything else — fetching a report, regenerating a sitemap, drafting from an outline you approved — has an answer that stays the same, so the judgement can be made once and written down as a rule. An agent working over MCP is safe on the second kind and needs a person on the first.
A marketing task is decidable once when repeating it produces the same outcome and the outcome does not depend on anything a person would want to weigh. Fetching last week's clicks is decidable once: it changes nothing, costs nothing you care about, and gives the same answer to whoever asks. Regenerating a sitemap is decidable once for the same reason — running it twice leaves the same file. These are tasks where the reasonable policy is a standing yes, and pausing to confirm each one is a cost with no matching benefit.
Market4 encodes that distinction in the shape of its MCP tools rather than in a list of task names. Every tool is annotated along two axes: whose system it touches — ours or somebody else's — and what it does to it, which is read, overwrite, add or remove. Eight combinations cover the whole surface, and the annotation on a tool is what an assistant reads before deciding whether to run it or ask.
| Shape of the work | Marketing example | Repeat it and you get | Who decides |
|---|---|---|---|
| Read our own data | Last week's search performance | The same answer | Standing yes |
| Read somebody else's | A crawlability check on a live URL | The same answer, from outside | Standing yes |
| Overwrite our own state | Update a keyword's target page | The same state | Standing yes, with an audit trail |
| Add to our own state | Create a draft post | Two drafts | Standing yes, but not idempotent |
| Remove from our own state | Archive a keyword or a post | The same state | Surfaced to a person |
| Change somebody else's system | Publish to a social network, submit a sitemap | A different result each time, sometimes | A judgement |
The server is the same in both. What differs is which layers the client implements: how it connects, how it discovers the authorisation server, which of the three capabilities it lists, and whether it reads the hints on each tool.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
A marketing decision cannot be settled in advance when the same action is right in one week and wrong in the next. Market4 names seven of these as approval action types, and they are worth reading as a list of the judgements a marketing system actually contains: publishing a post, sending a bulk email, spending money, changing analytics configuration, publishing to a social channel, changing a tag manager container, and buying a batch of search results. Each is a question whose answer depends on what else is happening.
Notice what unites them. Each one either reaches someone outside the company, spends a finite resource, or changes the instrument by which everything else is measured. None of those is a property of the task's difficulty; a bulk email is technically trivial and still needs a person, while a full crawlability audit is technically involved and needs nobody.
An agent knows which kind of work it is doing from the tool it is about to call, provided the tools carry that information. In practice this means two things about how a tool surface is written. The first is the annotation, which answers whether the call reads or writes, whose system it touches, and whether repeating it is harmless. The second is the tool's description, which has to name the judgement rather than hide it — a tool that spends money should say so in the sentence an assistant reads before choosing it, not in a footnote.
There is a subtlety in what "repeating it is harmless" means. Market4 answers it from the caller's point of view: if this same call is made twice, does the caller end up where they wanted? Creating a draft post fails that test, because two calls make two drafts, so it is marked as an addition rather than an overwrite. Setting a keyword's target page passes it, because the second call leaves the same value. That framing matters for a retry after a network error, which is exactly when an agent is most likely to repeat itself.
Sorting the work this way leaves a person with a small and specific job: deciding the things whose answer moves. That is choosing what to write about next, reading a draft before it goes out, saying yes or no to a spend, and setting the goal the rest of the work is judged against. It is not fetching reports, not formatting them, not remembering to resubmit a sitemap. The complaint that automation removes the interesting part of marketing usually describes a system that automated the judgements and left the person doing the fetching.
The ones whose answer does not change with the circumstances: reading analytics and search data, checking crawlability or structured data on a URL, regenerating and resubmitting a sitemap, drafting against an outline that was already approved, and updating your own records such as a keyword's target page. What they share is that repeating them is harmless, they reach nobody outside the company, and they spend nothing finite.
Because the two differ in reversibility, not in difficulty. A published post can be unpublished or rewritten, and readers who have not arrived yet will see the corrected version. An email is in the recipient's inbox the moment it is sent, and no later action in any product reaches it. Reversibility, not technical risk, is what decides which actions can carry a standing yes.
In the description the assistant reads before choosing it, in plain words, and again in the annotation that says the call is not a read. Burying the cost in a parameter comment means the choice is made before the cost is known. In Market4 the spend category is the one that always requires an approval regardless of any auto-publish setting, so the tool description saying so is what stops an agent planning around a gate it cannot pass.
The caller's, and the difference is practical. A server might consider a create idempotent because it wrote exactly one row per request, while the caller who retried after a timeout now has two drafts. Judging from the caller's point of view means asking whether a repeated call leaves them where they wanted to be, which is the question that matters when an agent retries a call it never saw the answer to.
Fewer decisions, and each remaining one heavier. Fetching a report, formatting it and remembering to resubmit a sitemap all stop being decisions. What is left is choosing the subject, reading the draft, approving the spend and setting the goal. That is a smaller list, but every item on it is a judgement that changes what happens next, which is the part a rule written in advance cannot cover.
Both can hand a model a block of JSON, so the choice looks cosmetic. It is not. A tool call is a decision the model makes with arguments it invents; a resource read is a fetch the client performs against an address it already holds.
A tool error that says "invalid input" ends the run. One that quotes the rejected value, lists the accepted set and names the next move lets the assistant repair the call itself. Four real messages from one codebase, read closely.