Amazon Ads MCP Server: What Connecting Costs

Amazon's official Ads MCP Server hands your agent 92,678 tokens of tool definitions the moment it connects, before it reads a single campaign. Kuudo's Amazon Ads MCP hands it 388, and indexes 773 Amazon Ads operations behind them. I measured both on 2026-09-12 with the same tokenizer, and everything in this guide rests on those two counts.

Here is why I went looking. A PPC lead on our side connected Amazon's new server to Claude Desktop, asked one question about a campaign, and hit a context warning before the answer came back. Nothing was broken. The catalog the server advertises is simply large, and an advertised catalog is charged whether or not you call anything in it. So the question became: how large, does it matter, and does it keep mattering as the catalog grows?

ChatGPT, Claude, Perplexity, Microsoft Copilot, and whatever comes next know nothing about your business out of the box. Your competitors use those tools too. Kuudo gives those same tools your edge: your data, your rules, and the way your business operates. That means your account as it is right now, your judgment running every time, and your call before anything changes. The Amazon Ads MCP and the Selling Partner MCP supply the live account and the authorized tools, Skills carry your judgment, Amazon Agent Atlas grounds Amazon's rules, and approval controls keep the last word with you. The cost this guide measures is the price of that first piece, paid on every connection, and it decides how much of the window is left for the rest.

The advertised catalog is a fixed cost, paid before any work starts

When an MCP client connects, the server answers with the definition of every tool it advertises: name, description, and a JSON schema for the inputs. That answer sits at the front of the context window from the first request. Token governance attention goes to the variable costs, the history, the retrieval payloads, the output length. The advertised catalog precedes all of them, and it is the one line item that can be engineered away rather than trimmed.

Amazon's single largest tool, the one that creates a target, is 12,051 tokens on its own, 31 times the size of Kuudo's entire advertised surface. Composition explains the shape: 94.4% of Amazon's footprint is JSON schema and 4.5% is description, so advertising the catalog costs about nine times what invoking every tool in it once would cost. The distribution is skewed too. The median tool is 315 tokens against a mean of 842, ten tools carry more than half the catalog, and sixteen exceed 1,000 each. Kuudo advertises three small tools and fetches the rest of its catalog only when a tool is actually needed, which is why the MCP connection itself weighs almost nothing.

Discovery costs something too, and the honest number is 72 percent, not 99

Fetching tools on demand trades a fixed cost for a variable one, and the variable side has to be counted. I exercised 100 tools on the Amazon Ads MCP through six search queries and added up everything the exchange put into the window.

Against Amazon's 92,678 connect cost, the complete 100-tool discovery exercise is 72.4% lower, a factor of 3.6. That is the defensible figure whenever the comparison involves work being done, and it is materially less dramatic than the 239 times at connect. Use it.

Two constraints travel with it. The schema responses in the probe are compact summaries. A full-detail schema can be far larger: the campaign-creation operation measures 9,759 tokens at full detail against 90 for its compact form, a 108-times spread, so no projection across the full 773-operation catalog appears here. And discovery artifacts persist. Search results and fetched schemas enter the message history and are re-sent on later turns like any other content unless the client clears tool results, so 25,605 is the cost of the exercise, not a per-turn figure.

On clients that resend the catalog, the cost recurs every turn and multiplies across agents

For clients that eagerly inject the complete tool list, the advertised definitions are re-sent on every inference call. The connect cost is not a startup charge that frees up; it is present in every request for the life of the session. This qualification matters. Anthropic supports deferred tool loading, where definitions are fetched on demand rather than injected wholesale, and a client using it does not pay 92,678 on every turn. The recurrence argument applies to eager-injection clients, which remain common but are not universal, and it should be stated that way.

Where recurrence applies, two consequences follow that a larger window does not fix. Sub-agent fan-out multiplies it: each sub-agent context carries the catalog independently, so ten parallel sub-agents on Amazon's server carry 926,780 tokens of tool definitions across the fleet, against 3,880 on Kuudo. And the constraint changes with the deployment tier without disappearing. On 128k and 200k class models, including open-weight and self-hosted deployments, 92,678 tokens is 72.4% and 46.3% of the window before any work, and capacity is the binding constraint. On frontier models with 1M windows the catalog fits at 9.27%, and price starts binding instead. Carrying it uncached across a 20-turn session:

Prices are Anthropic's published base input rates on 2026-09-12, applied to the cl100k_base counts from the audit. Anthropic bills on its own tokenizer, which its pricing page says produces about 30 percent more tokens for the same text, so both columns would run roughly a third higher on a real bill while the ratio between them stays put. Prompt caching reduces the Amazon column substantially where the cache stays warm, but it reduces both columns by the same multiplier and does not change the ratio, because caching lowers the price of re-sending tokens and not the number of tokens occupying the window. Cheap tokens, no room. Plenty of room, expensive tokens. A fixed catalog loses on whichever axis the deployment cares about. There is a quality question underneath the budget one as well: published research on long contexts finds that model performance declines as input length grows and that distractor content amplifies the effect. This guide does not quantify that effect, and the two studies in the sources are the place to start if you want to.

Adding an operation to Kuudo's catalog costs nothing at connect

This is the durable argument, and it needs no claim about capability. Under a static catalog, advertised breadth and default context cost are the same variable: every tool added to the catalog is charged to every client in every session, including clients that will never call it, at roughly 842 tokens on Amazon's current per-tool average. Whether a new backend operation becomes a new advertised tool or folds into an existing one is Amazon's design choice, and this audit did not measure a per-operation delta on their side. Kuudo separates the two. The build I measured indexes 773 Amazon Ads API operations at a connect cost of 388 tokens, and that figure does not move when the 774th is added. The public repository's generated catalog carries 711 operations today; the connect cost is the same number either way, which is the point.

One boundary, stated plainly. Both audits are token counts of what a server advertises. Neither describes what any tool does, and Amazon's 110 tools may each aggregate several backend operations, so 773 against 110 is not a like-for-like count and no coverage ratio is claimed from it. The comparison here is about what connecting costs and how that cost behaves as a catalog grows. Nothing more.

What happens next

Check which loading mode your client uses before you size a workflow, because that decides whether the connect cost is paid once or on every turn. Then measure. Both audits are reproducible from the tool list a server returns at connect, and the open items are listed rather than papered over: the Amazon figure is a single North America snapshot and should be re-run on the EU and FE endpoints; both audits use cl100k_base, and Anthropic notes that its current tokenizer produces about 30 percent more tokens for the same text, so the direction and the order of magnitude hold while the specific multipliers should be re-derived rather than carried over; and fetch success is not the same as retrieval accuracy, which is the point a skeptic will press hardest and the next thing to measure.

For the work itself, the Amazon Agent Data layer is what keeps a large result out of the window entirely: a query returns a bounded preview and a durable handle, so the context holds the evidence and not the whole table. That is the same discipline as the small catalog, applied one step later.

The pattern is simple. Measure what a connection costs before the first call, count discovery honestly once work starts, and prefer the catalog whose cost does not move when it grows.

Next: why the same AI in every competitor's hands makes your account context the edge.