What Ten Amazon Ads MCP Servers Do With Your Write Access

Finding. Twenty GitHub repositories match a search for “amazon ads mcp”. Three contain no code at all. Of those that do, a single 74,000-line codebase accounts for most of the ecosystem, and two other projects are copies of it that GitHub does not identify as forks. Across all ten repositories examined, none records what it changed after a write.

These servers expose campaign create, update and delete against live advertising spend. What follows is a static audit of what the code does, conducted 2026-09-04.

The ecosystem is smaller than it looks

The two 74,080-line entries are the same software. Comparing file trees by content hash, 547 of 550 shared files are byte-identical, a 99.5% match. The three that differ are README.md, CHANGELOG.md and server.json; the later repository adds deployment configuration. It was created ten months after the original.

The third Python project shares 90 of its 94 Python file paths with the first, and 43% of those files are byte-identical. It is a derivative of the same lineage at an earlier point.

All three carry MIT licences, so the copying is entirely permitted and there is nothing improper here. The observation is narrower and still worth making: GitHub reports none of the three as a fork, so a buyer comparing “which Amazon Ads MCP server should I trust” sees three independent-looking projects with independent star counts, and is in fact looking at one codebase three times. A defect in the original is a defect in all three, and there is no notification path between them.

Worth noting in the other direction: the second-most-starred repository is 170 lines across two files, and another with 38 registered tools contains a single HTTP call. Much of what looks like an ecosystem of API clients is thin proxying to hosted services.

Idempotency is implemented and then not used where it matters

The largest codebase does something most do not: it thinks about idempotency explicitly. Its HTTP resilience layer contains a helper that classifies requests correctly. GET, HEAD, PUT and DELETE count as idempotent, and POST qualifies only when an idempotency key header is present.

That helper is consulted in exactly one place — the branch handling 4xx responses.

The retry decision has three paths. Retryable status codes are 429, 408, 502, 503 and 504, and that check is made without reference to the HTTP method. Client errors in the 4xx range consult the idempotency helper, which is correct. Network errors and timeouts set the retry flag unconditionally, with no method check at all.

So a POST creating a campaign that returns 502, or that times out at the gateway, is retried. The timeout case is the one that matters, because a timeout is precisely the ambiguous outcome: the request may have been received and applied, and the client has no way to know. Retrying it is the textbook way to create two of something.

This is a correctness defect rather than a vulnerability, and it is a small fix — the idempotency check already exists a few lines above and simply needs to gate the other two paths as well. The same code appears in the derivative project.

Nobody writes down what they changed

Not one repository searched contains an audit log, a mutation record, or any structured account of which campaign was altered, from what value, to what value, by which run. Ordinary application logging exists. A record you could hand to somebody asking why the budget changed on Tuesday does not.

That absence is the finding I would weight highest. An agent with campaign write access will eventually do something nobody intended, and the question afterwards is always the same: what did it change. The servers reviewed here make that question unanswerable from their own output.

Method

Population. GitHub repository search for “amazon ads mcp”, 2026-09-04, top 40 results by relevance, yielding 20 repositories. Excluded from cloning: privacy-policy pages, a workshop repository and a learning app, none of which are servers. The remaining ten were cloned at depth 1 and examined as source.

Procedure. File trees compared by MD5 per file. Signal counts by regular expression across source and documentation, then every finding reported above verified by reading the relevant source directly. Licence, fork status, star count and creation date from the GitHub API rather than from repository pages.

What this does not establish. This is static reading, not execution. No server was run, no request was issued against Amazon’s API, and no claim here is a behavioural test. A project could correct any of this at a layer not visible in source, though for the retry path specifically the logic is self-contained and reads unambiguously.

Absence of a pattern is weaker evidence than presence. “No audit logging in 10 of 10” means no such code matched the searches used and none appeared on inspection of the write paths. A sufficiently unusual implementation could be missed. Presence findings — the byte-identical trees, the retry branches — are strong, because they were read directly.

These are volunteer projects. Several are early and honest about it. The point of the exercise is the shape of the ecosystem rather than the quality of any individual’s work, and the most-developed project is also the one that got furthest toward handling this correctly.

What would change this

Running the servers would. A behavioural test against a sandbox account — issue a write, kill the connection mid-flight, count the resulting campaigns — would convert the retry finding from a reading of the code into a demonstration. That is the obvious round two.

A larger population would sharpen the duplication finding. Search relevance ordering is not a census, and servers that do not use these words in their names are invisible to it.

And a single upstream fix would change two rows of the table at once, which is the practical consequence of three repositories sharing one codebase.

Collected 2026-09-04. First published 2026-09-04. Last revised 2026-09-04.