Skip to main content
Glama
KuudoAI

Amazon Ads API MCP

by KuudoAI

Amazon Ads API MCP SDK

Build AI-powered advertising applications with the Model Context Protocol (MCP) SDK for Amazon Advertising API

Made with ❤️ + ☕ by Openbridge

Python 3.10+ License: MIT CI

MCP registry id (for clients and catalogs that display a stable package name): io.github.KuudoAI/amazon_ads_mcp

Table of contents

Related MCP server: TikTok Ads MCP Server

What Are MCP Tools?

Think of MCP (Model Context Protocol) as a translator between an AI model and outside systems (like Amazon Ads). Each MCP tool is like a remote control button that tells the AI how to interact with Amazon Ads. Without MCP tools, the AI would have no idea how to “talk” to Amazon Ads.

With MCP tools:

  • The AI knows the exact endpoints to call.

  • The AI can request campaign reports, budgets, or targeting data safely.

  • Everything is structured, so the AI doesn’t break things by making random guesses.

👉 In short: MCP tools = a safe, well-labeled toolkit that lets AI work with the Amazon Ads API.

🚀 What is Amazon Ads API MCP SDK?

The Amazon Ads API MCP SDK is an open-source implementation that provides a robust foundation for creating AI-powered advertising tools, chatbots, and automated services.

✨ Key Features

  • 🔌 MCP Integration: Full Model Context Protocol compliance for AI application integration

  • 🌍 Multi-Region Support: NA, EU, and FE region endpoints with automatic routing

  • 📊 Comprehensive API Coverage: Campaigns, profiles, reporting, DSP, AMC workflows, and more

  • 📝 Type Safety: Full Pydantic model support with comprehensive type hints

  • 🧪 Production Ready: Includes testing, validation, and error handling

🎯 Use Cases

Claude Desktop Integration

  • Campaign Management: Ask Claude to create, update, or analyze campaigns

  • Performance Insights: Get AI-powered analysis of your advertising performance

  • Budget Optimization: Let Claude suggest budget adjustments based on performance

  • Creative Testing: Get recommendations for ad creative improvements

  • Reporting: Generate custom reports and insights on demand

AI Applications

  • Marketing Chatbots: Build conversational AI that can manage Amazon Ads campaigns

  • Automated Reporting: AI-powered insights and performance analysis

  • Smart Budget Management: Intelligent budget optimization using AI

  • Creative Optimization: AI-driven ad creative testing and optimization

Enterprise Services

  • Marketing Automation Platforms: Integrate Amazon Ads into existing marketing tools

  • Agency Management Systems: Multi-client, multi-account advertising management

  • E-commerce Integrations: Connect Amazon Ads with e-commerce platforms

  • Analytics Dashboards: Real-time advertising performance monitoring

Developer Tools

  • API Wrappers: Create custom SDKs for specific use cases

  • Testing Frameworks: Automated testing for Amazon Ads integrations

  • Development Tools: Local development and debugging utilities

Why this Ads MCP is different

Other Amazon Ads MCPs do happy path. They fall apart the moment an agent makes a reasonable mistake and Amazon's Ads API has more reasonable mistakes than almost any other large API surface. The v1 reporting catalog uses a different vocabulary than v3. The docs are scattered across migration generations. The same field can have three plausible names depending on which tutorial an agent or human was trained on.

You've felt this before

You know the symptoms even if you've never thought of them as a single problem:

  • "Compacting conversation…" right when you were getting somewhere

  • "Usage limit reached" mid-task, with nothing to show for the tokens

  • "Context window exceeded" start over, re-explain everything

  • The agent quietly forgetting the fix it figured out three turns ago

  • Five tool calls, four of them retries, none of them progress

  • Re-pasting the same error into the chat for the third time

That's not the model being dumb. That's the API surface burning context vague errors trigger thrashing, thrashing fills the window, the window fills and everything useful gets evicted. Anywhere from 4 to 12 round-trips for an agent: wrong field names, wrong body shape, wrong filter operator, wrong date placement, wrong advertiser-account format.

Here, the wrong moves return the right move

This server is built around a different premise: the error surface is the documentation surface. Every failure is a teaching opportunity, and the server is engineered to make the next attempt smarter than the last one, for the same agent or the next one, without retraining, prompt updates, or memory tricks.

  • The server tells you what went wrong, and why you got it wrong

  • Every failure converts to a corrective action — the model just reads the hint and moves on

  • A five-tool-call debugging arc collapses into a two-call corrected one

  • The same mistake a week later doesn't re-burn context, because the validator, alias table, and deprecated-shape table are still right there

  • No out-of-context tribal knowledge to forget

Every failure is cheaper than the last. Every agent learns from the same authoritative source. Every retry has direction. That compounding is what a smart agent solution looks like in practice.

Everything is an edge case, you can help

We won't catch every edge case. Amazon's API surface is enormous, the migration history is messy, and real-world failures get more creative than anything anyone can anticipate. What we're committing to is the strategy that errors should teach, that documentation should live in the surfaces agents actually touch, that every wrong move should make the next move easier.

If you hit a failure where the envelope didn't help; vague hint, wrong suggestion, no hint at all, that's exactly the feedback we want. Open an issue, paste the envelope, tell us what you expected. The strategy is only as good as the cases it covers.

Quick start

Prerequisites: Docker (recommended), Python 3.10+ if you run from source, and Amazon Ads API access (your own developer app or a partner such as Openbridge).

  1. git clone https://github.com/KuudoAI/amazon-ads-mcp.git && cd amazon-ads-mcp

  2. cp .env.example .env and add credentials (see Configuration).

  3. docker compose up -d

  4. Connect your MCP client to http://localhost:<PORT>/mcp/.env.example sets PORT=9080 (override in .env if needed).

OAuth steps, client JSON samples, and a full variable reference: Configuration below, INSTALL.md, and AGENTS.md.

📚 What Is Included In the Amazon Ads MCP?

The MCP server mirrors broad coverage of the Amazon Ads API surface. Each enabled package maps to a set of API operations. That includes Campaign Management (Amazon Ads API v1), Exports, Amazon Marketing Cloud, and many more.

Here is a representative list of the various Amazon API services in the MCP:

  • Accounts

  • Audiences

  • Reporting

  • Brand metrics

  • Sponsored Products

  • Sponsored Brands

  • Sponsored Display

  • Amazon DSP

  • Amazon Attribution

  • Recommendations & insights

  • Creatives

  • Change history

  • Data provider

  • Products

  • Unified pre-moderation

  • Moderation

  • Amazon Marketing Stream

  • Locations

  • Exports

  • Media Planning

  • Amazon Ads API v1

🧪 Amazon Ads API v1

The Amazon Ads API v1 represents a reimagined approach to the Amazon Ads API, built from the ground up to provide a seamless experience across all Amazon advertising products through a common model. One major benefit of this common model is improved compatibility with code generation tools such as client library generators.

⚠️ Beta Notice: These APIs are currently in beta at Amazon. Features and endpoints may change. Use in production with caution.

Package Name

Description

Prefix

ads-api-v1-all

Ads API v1 merged ALL surface

allv1_

ads-api-v1-sp

Sponsored Products v1

spv1_

ads-api-v1-sb

Sponsored Brands v1

sbv1_

ads-api-v1-dsp

Amazon DSP v1

dspv1_

ads-api-v1-sd

Sponsored Display v1

sdv1_

ads-api-v1-st

Sponsored Television v1

stv1_

ads-api-v1-beta

Ads API v1 merged BETA surface

beta_

To activate Ads API v1 packages, add them to your AMAZON_AD_API_PACKAGES environment variable:

# Example: Enable the merged Ads API v1 ALL surface
AMAZON_AD_API_PACKAGES="profiles,ads-api-v1-all"

For more information, see Amazon's Campaign Management Overview.

Installation

We recommend running Amazon Ads API MCP with 🐳 Docker. Build the image from this repository (there is no supported docker pull for a third-party registry image here—use the Dockerfile and docker-compose.yaml in the repo).

For bespoke installs such as pip, source checkouts, custom virtualenvs, non-Docker deployments, or Code Mode extra handling, use the Installation Guide. The README keeps the Docker quick path short; INSTALL.md has the full install matrix and verification steps.

git clone https://github.com/KuudoAI/amazon-ads-mcp.git
cd amazon-ads-mcp

Copy the environment template:

cp .env.example .env

Edit .env with your settings (including PORT if you change the default).

Start the server with Docker Compose (builds and tags amazon-ads-mcp:latest per docker-compose.yaml):

docker compose up -d

The server listens on the host port mapped from PORT in .env (.env.example uses 9080).

Check logs:

docker compose logs -f

Stop the server:

docker compose down

For verification, upgrading, developer setup, and non-Docker installation paths, see the Installation Guide.

Configuration

Operators / self-hosters: follow the steps below and your .env file. Chat users mostly interact via prompts once the server is connected; skim Advertiser Profiles & Regions for profile and region behavior.

Amazon Ads requires that all calls to the API are authorized. If you are not sure what this means, you should read the Amazon docs:

There are three paths for connecting to the API;

  1. Bring Your Own App (BYOA)

  2. Use OpenBridge-managed authorizations

  3. Use Kuudo-managed authorizations

Bring Your Own Amazon Ads API App

If you have your own Amazon Ads API app, or want to create one, the process is detailed below.

1. Register Your Application with Amazon

  1. Go to the Amazon Developer Console

  2. Create or select your Login with Amazon application

  3. Note your Client ID and Client Secret

  4. Set your callback URL to "Allowed Return URLs". This must match the host and port of this MCP server’s HTTP listener (see PORT in .env; .env.example uses 9080):

    • For production: https://your-server.com/auth/callback

    • For local development: http://localhost:<PORT>/auth/callback (e.g. http://localhost:9080/auth/callback)

Once you have your app secured and approved by Amazon, you will need the client ID and secret:

# Amazon Ads API Credentials (required)
AMAZON_AD_API_CLIENT_ID="your-client-id"
AMAZON_AD_API_CLIENT_SECRET="your-client-secret"

Make sure these are in your .env file. Also, make sure you set your authorization method to direct in the same .env:

AUTH_METHOD=direct

Complete OAuth Flow

To authorize your connection to Amazon, you need to complete an OAuth workflow as an end user. First, you need to set your region. Authorization occurs at the region level and not setting your region may cause a failure. The server will default to the na region. You can manually set the region with tool set_active_region.

  • Tool: set_active_region

  • Parameters: na | eu | fe

Example prompt: "Set my current region to eu"

Step 1: Start OAuth

To connect to Amazon Ads API, you use an MCP tool to start your OAuth flow

  • Tool: start_oauth_flow

  • Example prompt: "Start my OAuth flow"

Step 2: Redirect to Amazon Ads

In this example, you are prompted to click the link that will open a browser window and request approval at Amazon.

Step 3: Approve Request

In the browser window, Amazon will prompt that you approve the request to connect.

Step 4: Success

If all goes well, you will see a success response. You can close the browser window and go back to your client. If you see something else, attempt the process again and confirm all your configuration elements are correct

Step 5: Confirmation

To confirm that your MCP server is connected to the Amazon Ads API, check your OAuth status

  • Tool: check_oauth_status

  • Example prompt: "Check my OAuth status"

You are ready to start interacting with the Amazon Ads API system!

Partner Applications: Token Authentication

You can configure your client, like Claude, to use authentication by supplying a valid access token. This is most appropriate for service accounts, long-lived API keys, CI/CD, applications where authentication is managed separately, or other non-interactive authentication methods.

Openbridge Partner App

As an Ads API Partner application provider, Openbridge offers a ready-to-go gateway to the Amazon Ads API. You log into your Openbridge account, provision a token, then set your token in your client config (see below).

First, set Openbridge as the auth method:

AUTH_METHOD=openbridge

That is it for the server config. To access the server, you need configure the client, like Claude Desktop, to pass the token directly. (see Example MCP Client: Connect Claude Desktop)

Authorized Amazon Accounts

Your Amazon authorizations reside in Openbridge. Your first step in your client is to request your current identities: "List my remote identities". Next, you would tell the MCP server to use one of these identities: "Set my remote identity to <>". You can then ask the MCP to List all of my Amazon Ad profiles linked to that account. If you do not see an advertiser listed, set a different identity.

Kuudo Partner App

Kuudo can vend short-lived Amazon Ads credentials from organization-managed Amazon connections. Configure the server with a Kuudo M2M API key:

AUTH_METHOD=kuudo
KUUDO_API_BASE_URL=https://amazon-spapi-dev.kuudo.ai/
KUUDO_API_KEY=sk_xxxxxx
KUUDO_PROVIDER=amazon_ads

The API key requires the amazon-connections:read and amazon-tokens:vend scopes. Set KUUDO_REMOTE_IDENTITY_ID to select a default connection at startup, or use the identity tools to list and select a connection before calling Amazon Ads operations.

Public HTTP deployments must also configure MCP_INBOUND_TOKEN or trusted proxy HMAC authorization for MCP callers.

Set Your Amazon Ads MCP Packages

To activate specific packages, set a comma-separated package list. For a streamlined default with unified Ads API v1 coverage:

  • AMAZON_AD_API_PACKAGES="profiles,accounts-ads-accounts,reporting-version-3,amc-workflow,ads-api-v1-all"

Here is the list of tool packages available in the server:

  • profiles

  • test-account

  • forecasts

  • brand-stores-management

  • campaign-manage

  • accounts-manager-accounts

  • accounts-ads-accounts

  • accounts-portfolios

  • accounts-billing

  • accounts-account-budgets

  • audiences-discovery

  • reporting-version-3

  • brand-benchmarks

  • brand-metrics

  • stores-analytics

  • sponsored-products

  • sp-suggested-keywords

  • sponsored-brands-v4

  • sponsored-brands-v3

  • sponsored-display

  • dsp-measurement

  • dsp-advertisers

  • dsp-audiences

  • dsp-conversions

  • dsp-target-kpi-recommendations

  • amazon-attribution

  • audience-insights

  • partner-opportunities

  • tactical-recommendations

  • persona-builder

  • creative-assets

  • change-history

  • data-provider-data

  • products-metadata

  • products-eligibility

  • unified-pre-moderation-results

  • moderation-results

  • amazon-marketing-stream

  • locations

  • exports-snapshots

  • marketing-mix-modeling

  • reach-forecasting

  • amc-administration

  • amc-workflow

  • amc-rule-audience

  • amc-ad-audience

  • ads-api-v1-sp (Beta)

  • ads-api-v1-sb (Beta)

  • ads-api-v1-dsp (Beta)

  • ads-api-v1-sd (Beta)

  • ads-api-v1-st (Beta)

  • ads-api-v1-all

  • ads-api-v1-beta (Beta)

You will note that some are broken up into smaller groupings. For example, Amazon Marketing Cloud has bundles; amc-ad-audience, amc-administration, amc-rule-audience, and amc-workflow. This is done to create efficiencies and optimizations that reduce context limits in many AI clients.

Understanding Amazon Ads MCP Tools

Amazon Ads MCP tools have prefixes (like cm_ for Campaign Management or amc_ for Amazon Marketing Cloud) to help organize the specific Ads API operation.

Example prefixes:

  • cm_ → campaign/advertising APIs

  • amc_ → AMC-related APIs

  • dsp_ → DSP APIs

  • sd_ → Sponsored Display

  • ams_ → Amazon Marketing Stream

  • spv1_ → Sponsored Products v1 (Beta)

  • sbv1_ → Sponsored Brands v1 (Beta)

  • dspv1_ → Amazon DSP v1 (Beta)

  • sdv1_ → Sponsored Display v1 (Beta)

  • stv1_ → Sponsored Television v1 (Beta)

This will translate into collections of tools that align with the API operations that are available:

Campaign Management (cm_)

  • cm_QueryCampaign — Query campaigns

  • cm_CreateCampaign — Create campaign

  • cm_UpdateCampaign — Update campaign

  • cm_DeleteCampaign — Delete campaign

  • cm_QueryAdGroup — Query ad groups

Sponsored Products (sp_)

  • sp_listProductAds — List product ads

  • sp_createKeywords — Create keywords

  • sp_updateBids — Update keyword bids

  • sp_getNegativeKeywords — Get negative keywords

AMC Workflows (amc_)

  • amc_listWorkflows — List AMC workflows

  • amc_executeWorkflow — Run workflow

  • amc_getWorkflowStatus — Check workflow status

Users would see tools like:

  • "List my Amazon Ads campaigns"
    → Claude uses: cm_QueryCampaign

  • "Create an AMC workflow"
    → Claude uses tools such as amc_executeWorkflow (after discovery; exact names depend on your enabled packages)

  • "Export my sponsored products ads data" → Claude uses: export_createAdExport

📥 Downloading Reports & Exports

When tools fetch a report or export from Amazon, they download the file onto the machine running the MCP server (local disk on the server host—Docker volume, VM, or bare metal—not your laptop unless the server runs there). The default base directory is ./data (override with AMAZON_ADS_DOWNLOAD_DIR). Files are organized under data/profiles/{profile_id}/….

MCP tools list those server-side files and build URLs; clients then pull the bytes over HTTP (GET /downloads, GET /downloads/{relative-path}). Nothing streams straight from Amazon into the MCP client without hitting server storage first in these flows.

Use HTTP transport for downloads: run with --transport http (or Docker on port 9080). stdio mode does not register /downloads, and the get_download_url tool returns an error without HTTP.

Reports vs exports

  • V3 async reports: Use the OpenAPI tools createAsyncReport (POST) to create, getAsyncReport (GET) to poll status, then download_export to save the completed file on the server into profile storage.

  • Exports (e.g. ad exports): Create the job with the OpenAPI tools (e.g. export_CampaignExport), poll with export_GetExport, then call download_export with the completion URL so the file is fetched from Amazon and written on the server (same storage layout as reports).

Workflow

  1. Set active profile (set_active_profile) so storage and HTTP access are scoped.

  2. Create the job: Use the appropriate OpenAPI tool to create a report or export.

  3. Poll for completion: Use the corresponding GET tool to check status until COMPLETED.

  4. Download: Call download_export with the download URL from the completed response.

  5. Discover or link: MCP tools list_downloads and get_download_url.

  6. Fetch bytes: HTTP GET on the URL from step 5 (browser, curl, etc.).

Subpaths under the profile folder depend on report/export type (for example reports/…, exports/…). URLs look like http://localhost:9080/downloads/{relative-path} where {relative-path} matches list_downloads (illustrative example: reports/async/some-report.json.gz).

Direct HTTP (curl): /downloads uses the active profile in the running server (the one set via MCP in that process). If you see No active profile, call set_active_profile through MCP against the same server first. When no auth manager is configured, a numeric ?profile_id= query parameter may be accepted instead—see your deployment settings.

Example Prompts

Task

Example Prompt

Download a report

"Generate a Sponsored Products report for January 2026"

List available files

"Show me my downloaded files"

Get download link

"Get the download URL for the report we just created"

Filter by type

"List my downloaded campaign exports"

HTTP Download API

# List available downloads (paths and URLs are profile-scoped)
curl http://localhost:9080/downloads

# Optional filter
curl 'http://localhost:9080/downloads?type=reports'

# Download one file (example path — use paths from list_downloads)
curl -O 'http://localhost:9080/downloads/reports/async/example-report.json.gz'

# If AMAZON_ADS_DOWNLOAD_AUTH_TOKEN is set
curl -H "Authorization: Bearer your-token" -O 'http://localhost:9080/downloads/exports/campaigns/example-export.json'

Profile Isolation

  • Files live under data/profiles/{profile_id}/.

  • Download tools and /downloads only see the active profile’s files.

  • Set the profile first: "Set my active profile to 123456789".

  • Legacy files outside profiles/ are not listed when using profile-scoped mode; move them under data/profiles/{profile_id}/ for access.

Advertiser Profiles & Regions

Setting Your Advertiser Profile

Per Amazon: Profiles play a crucial role in the Amazon Ads API by determining the management scope for a given call. A profile ID is a required credential to access an advertiser's data and services in a specific marketplace.

You may not know what profile(s) authorization grants you access to. You can list all advertising profiles accessible by your authorization:

  • Tool: ac_listProfiles

  • Example prompt: "List my advertiser profile ids"

Warning: Large accounts can return very large profile lists that may exceed client context limits. Prefer these bounded tools for discovery:

  • Tool: summarize_profiles"Summarize my advertiser profiles"

  • Tool: search_profiles"Find profiles with Acme in the name in US"

  • Tool: page_profiles"Show the first 20 UK profiles"

  • Tool: refresh_profiles_cache"Refresh my profile list cache"

Response includes profile details:

  • profileId, countryCode, currencyCode

  • dailyBudget, timezone

  • accountInfo (type: seller/vendor/agency)

Let's assume your list included profile ID 1043817530956285. You can check for more details by getting profile details to confirm this is the one you want to use.

  • Tool: ac_getProfile

  • Example prompt: "Get the details for my profile_id: 1043817530956285"

Assuming this is the profile you want to use, you need to set the profile Amazon requires for API calls:

  • Tool: set_active_profile

  • Example prompt: "Set my active profile id to 1043817530956285"

When you set the profile, it determines:

  • Which account's data you access

  • Currency and timezone for reports

  • Available campaigns/ads/keywords

The profile ID will be set in the background for the duration of your session. Repeat the process if you want to switch to a new profile.

Most calls to the Amazon Ads API require a Region. Each advertiser profile ID is associated with an advertising account in a specific region/marketplace.

The region is part of an advertiser profile. When you set an advertiser profile with set_active_profile, it will set the region that is associated with the profile automatically.

  • Tool: set_active_profile

Example prompt: "Set my active advertiser profile to 111111111111"

Since profile ID 111111111111 is based in na, the region will be set based on the profile region.

Set Active Region

The Amazon Ads MCP server includes tools for managing API regions as defaults and dynamically, allowing you to switch between North America (na), Europe (eu), and Far East (fe) regions without restarting the server.

When you set a region, the system automatically:

  1. Updates API endpoints - Routes API calls to the correct regional endpoint

  2. Updates OAuth endpoints - Uses the correct token refresh endpoint for the region

  3. Clears cached tokens - Ensures fresh authentication for the new region

  4. Preserves other settings - Keeps profile ID and identity settings intact

IMPORTANT: Avoid Region Mismatch: If you attempt to set a region that is not associated with your advertiser profile, the Ads API will reject your requests. For example, if a profile ID is attached to na and you manually set the region to eu, you have created a mismatch which will cause API request failures.

Get Active Region

If you are not sure what region is set, you can check for the region

  • Tool: get_active_region

  • Returns: Current region, endpoints, and configuration source

Example prompt: "What is my current active region?"

Example MCP Client: Connect Claude Desktop

Navigate to Connector Settings

Open Claude in your browser and navigate to the settings page. You can access this by clicking on your profile icon and selecting “Settings” from the dropdown menu. Once in settings, locate and click on the “Connectors” section in the sidebar. This will display your currently configured connectors and provide options to add new ones.

Edit your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

In this example, we show how to use the bearer token using the Openbridge API key. Add this configuration to your mcpServers section:

{
  "mcpServers": {
    "amazon_ads_mcp": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote@latest",
        "http://${HOSTNAME}:${PORT}/mcp/",
        "--allow-http",
        "--header",
        "Authorization:Bearer ${OPENBRIDGE_API_KEY}",
        "--header",
        "Accept:application/json,text/event-stream",
        "--debug"
      ],
      "env": {
        "HOSTNAME": "your_hostname",
        "PORT": "your_server_port",
        "MCP_TIMEOUT": "120000",
        "MCP_REQUEST_TIMEOUT": "60000",
        "MCP_CONNECTION_TIMEOUT": "10000",
        "MCP_SERVER_REQUEST_TIMEOUT": "60000",
        "MCP_TOOL_TIMEOUT": "120000",
        "MCP_REQUEST_WARNING_THRESHOLD": "10000",
        "OPENBRIDGE_API_KEY": "your_openbridge_token_here"
      }
    }
  }
}

Note: Replace hostname, port and your_openbridge_token_here with your actual OpenBridge token.

IMPORTANT: Cursor and Claude Desktop (Windows) have a bug where spaces inside args aren't escaped when it invokes npx, which ends up mangling these values. You can work around it using: mcp-remote custom headers documentation.

The config would look something like this:

{
  "mcpServers": {
    "amazon_ads_mcp": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "http://${HOSTNAME}:${PORT}/mcp/",
        "--allow-http",
        "--header",
        "Authorization:${AUTH_HEADER}",
        "--header",
        "Accept: application/json, text/event-stream"
      ],
      "env": {
        "HOSTNAME": "your_hostname",
        "PORT": "your_server_port",
        "MCP_TIMEOUT": "120000",
        "MCP_REQUEST_TIMEOUT": "60000",
        "MCP_CONNECTION_TIMEOUT": "10000",
        "MCP_SERVER_REQUEST_TIMEOUT": "60000",
        "MCP_TOOL_TIMEOUT": "120000",
        "MCP_REQUEST_WARNING_THRESHOLD": "10000",
        "AUTH_HEADER": "Bearer <your_openbridge_token_here>"
      }
    }
  }
}

Here is another example, which can be used if you are using OAuth since the OPENBRIDGE_API_KEY is not needed:

{
  "mcpServers": {
    "amazon_ads_mcp": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote@latest",
        "http://localhost:9080/mcp/",
        "--allow-http"
      ],
      "env": {
        "MCP_TIMEOUT": "120000",
        "MCP_REQUEST_TIMEOUT": "60000",
        "MCP_CONNECTION_TIMEOUT": "10000",
        "MCP_SERVER_REQUEST_TIMEOUT": "60000",
        "MCP_TOOL_TIMEOUT": "120000",
        "MCP_REQUEST_WARNING_THRESHOLD": "10000"
      }
    }
  }
}

Note: For various Claude configurations similar to what was shown above, see the MCP Remote docs for the latest settings/options.

Restart Claude Desktop

After saving the configuration file, restart Claude Desktop to load the new MCP server.

⚠️ Context Limits and Active MCP Server Tools

MCP tool registration and use can impact your AI systems usage limits. Usage limits control how much you can interact with an AI system, like Claude, over a specific time period. As Anthropic states, think of the amount of information/data used as drawing down on a "conversation budget". That budget determines how many messages you can send to your AI client, or how long you can work, before needing to wait for your limit to reset.

MCP Server tools contribute metadata like titles, descriptions, hints, and schemas to the model's context. This metadata is loaded into the LLM’s context window, which acts as its short-term working memory.

Each client, like Claude, has a fixed-size context window. This defines the maximum amount of information it can process in a single interaction—including user prompts, system instructions, tool metadata, and any prior messages.

The more tools you activate, the more of that limited space gets consumed up front. When you activate many tools, their combined schema and config payloads can significantly use up this context and you may quickly hit the context ceiling. This is when you’ll start seeing errors or warnings about exceeding the chat length limit.

The Amazon Ads MCP provides coverage across the entire API. As a result, there can be 100s of tools!

  • More tools = less room for user interaction: Activating unnecessary tools reduces available space for your actual prompt or data.

  • Start small: Activate only what you need for the current task. You can always add more later.

If you're encountering unexpected length issues, review which tools are active. Trimming unused ones can help minimize context use.

Code Mode

Code Mode is a feature that dramatically reduces tool token consumption. Instead of loading every tool schema into the LLM's context upfront, Code Mode replaces the full catalog with four lightweight meta-tools. The LLM discovers tools on demand and executes them via sandboxed Python.

Token Impact

Mode

Tools in Context

Tokens Used

Context Window

Standard

55

~32,000

16.1%

Code Mode

4

~470

0.2%

Reduction

98.6%

Illustrative comparison for a representative default-sized catalog; actual tool counts and token use depend on AMAZON_AD_API_PACKAGES, server version, and tokenizer.

How It Works

Code Mode uses a 4-stage discovery pattern:

Stage 1: tags          → Browse categories: "campaign-management (20), accounts (14), ..."
Stage 2: search        → Find tools: search("campaigns") → cm_listCampaigns, cm_createCampaign, ...
Stage 3: get_schema    → Get parameters: get_schema("cm_listCampaigns") → full input schema
Stage 4: execute       → Run code: sandboxed Python with await call_tool("cm_listCampaigns", {...})

All 200+ tools remain fully accessible. The LLM simply discovers and calls them on demand rather than loading every schema upfront.

Activating Code Mode

Code Mode defaults to CODE_MODE=true. To use the full tool catalog in context instead, set:

CODE_MODE=false

Docker Compose — add to your environment section:

environment:
  - CODE_MODE=false

Docker Run (map the host port to the container PORT, e.g. 9080):

docker run -d --env-file .env -e CODE_MODE=false -e PORT=9080 -p 9080:9080 amazon-ads-mcp:latest

Local Development (entry point is python -m amazon_ads_mcp.server, which runs the MCP server module):

CODE_MODE=false uv run python -m amazon_ads_mcp.server --transport http --port 9080

Configuration Options

Variable

Default

Description

CODE_MODE

true

Enable code mode

CODE_MODE_INCLUDE_TAGS

true

Include tag browsing in discovery (set false for small catalogs)

CODE_MODE_MAX_DURATION_SECS

30

Maximum execution time per sandbox run

CODE_MODE_MAX_MEMORY

50000000

Memory limit per sandbox run (50 MB)

Using Code Mode

Once enabled, your MCP client (Claude Desktop, Claude Code, etc.) will see only four tools instead of the full catalog.

Browse available categories:

"What tool categories are available?"

The LLM calls tags and sees categories like campaign-management, sponsored-products, programmatic-dsp, accounts, reporting, etc.

Find specific tools:

"Find tools for managing campaigns"

The LLM calls search("campaigns") and gets matching tool names with brief descriptions.

Get tool details:

"Show me the parameters for creating a campaign"

The LLM calls get_schema("cm_CreateCampaign") and gets the full input schema.

Execute operations:

"List my enabled campaigns"

The LLM calls execute with Python code:

result = await call_tool("cm_QueryCampaign", {
    "body": {"stateFilter": {"include": ["ENABLED"]}}
})

Tool Categories

When the LLM calls tags, it sees human-readable categories mapped from the API prefixes:

Category

Prefix

Description

campaign-management

cm

Create, update, query, delete campaigns, ad groups, ads, targets

sponsored-products

sp

Sponsored Products targeting, keywords, bids

sponsored-brands

sb

Sponsored Brands campaigns (v3 + v4)

sponsored-display

sd

Sponsored Display campaign and targeting tools

programmatic-dsp

dsp

DSP advertisers, audiences, conversions, measurement

amazon-marketing-cloud

amc

AMC workflows, audiences, administration

accounts

ac

Profiles, billing, budgets, portfolios, manager accounts

reporting

rp

V3 reporting tools

brand-insights

br

Brand benchmarks and metrics

stores

st

Stores analytics

server-management

Profile, region, OAuth, download tools

When to Use Code Mode

Use Code Mode when:

  • You have many tool packages activated and are hitting context limits

  • You want maximum context space for conversation and data analysis

  • Your MCP client supports tool discovery patterns (Claude Desktop, Claude Code)

Use Standard Mode when:

  • You have a small number of packages activated (1-3)

  • You need the fastest possible tool invocation (no discovery step)

  • Your workflow uses the same few tools repeatedly

Verifying Code Mode

After starting the server with CODE_MODE=true, verify it is active:

# Check server logs for confirmation
docker logs <container> 2>&1 | grep "Code mode"
# Expected: "Code mode active: 4 meta-tools exposed (tags, search, get_schema, execute)"

In your MCP client, you should see only four tools: tags, search, get_schema, and execute. If you see the full tool catalog, code mode is not active — check your environment variable.

Tool Audit

Use tool_audit to measure token footprint for tool catalogs and code mode behavior.

Baseline Audit

.venv/bin/python -m amazon_ads_mcp.tool_audit \
  --url http://127.0.0.1:9080/mcp \
  --limit 20

JSON output:

.venv/bin/python -m amazon_ads_mcp.tool_audit \
  --url http://127.0.0.1:9080/mcp \
  --format json \
  --limit 0 \
  > /tmp/tool_audit.json

Code Mode Probe Audit

When code mode is active, use probe mode to estimate on-demand schema fetch cost:

.venv/bin/python -m amazon_ads_mcp.tool_audit \
  --url http://127.0.0.1:9080/mcp \
  --format json \
  --limit 0 \
  --code-mode-probe \
  --probe-limit 50 \
  --probe-queries "campaign,ad,report,profile,dsp,amc,brand,targeting" \
  > /tmp/tool_audit_code_mode.json

Quick Comparison

jq '{tool_count,total_tool_tokens,context_window_percent}' /tmp/tool_audit.json
jq '{tool_count,total_tool_tokens,context_window_percent,code_mode_probe}' /tmp/tool_audit_code_mode.json

Key fields:

  • total_tool_tokens: Upfront token load from tools/list

  • context_window_percent: Share of configured context window

  • code_mode_probe.total_schema_tokens: Total sampled schema-fetch token cost in code mode

  • code_mode_probe.avg_schema_tokens: Average token cost per fetched schema

Background Tasks

Many Amazon Ads API operations are long-running — report generation, export creation, AMC workflow execution, audience processing, and DSP measurement studies can take seconds to minutes. Background tasks allow these operations to run without blocking the conversation.

How It Works

Background tasks are enabled by default. When a client requests background execution for any tool:

  1. Start: The tool returns immediately with a task ID

  2. Track: The client polls for progress updates at server-suggested intervals

  3. Retrieve: The client fetches the result when the task completes

All async tools in the server support background execution automatically. The client decides per-call whether to run a tool in the foreground (wait for result) or background (get task ID, poll later).

Built-in workflow tools

These tools orchestrate multi-step workflows (download and HTTP access to server-side files):

Tool

Purpose

download_export

Downloads a completed export or report file from Amazon S3 to local storage

list_downloads

Lists all downloaded files for the active profile

get_download_url

Returns an HTTP URL to fetch a downloaded file

These tools include progress reporting so clients can track each stage of the workflow.

Configuration

Variable

Default

Description

ENABLE_TASKS

true

Enable background task execution for all async tools

To disable background tasks:

ENABLE_TASKS=false

Docker Compose — add to your environment section:

environment:
  - ENABLE_TASKS=false

Backend

The server uses an in-memory task backend by default. Tasks are tracked for the lifetime of the server process. If the server restarts, in-progress tasks are lost.

For persistent task tracking across restarts, configure a Redis backend:

FASTMCP_DOCKET_URL=redis://localhost:6379

Example Prompts

Task

Example Prompt

Generate a report

"Generate a Sponsored Products campaign report for March 2026"

Export campaigns

"Export all my enabled campaigns"

Run AMC workflow

"Execute my audience overlap workflow for the last 30 days"

Troubleshooting

Server not connecting?

  • Ensure the Docker container is running: docker compose ps

  • Check server logs: docker compose logs -f

  • Verify the host port matches PORT in .env (.env.example uses 9080; your mapping must match)

Authentication errors?

  • Check your OpenBridge token is valid

  • Ensure the token is properly set in the environment

  • Verify your Amazon Ads API access

Claude not recognizing the server?

  • Restart Claude Desktop after configuration changes

  • "Reload Page" in Claude Desktop if the MCP is not active

  • Check the JSON syntax is valid

  • Ensure the server name matches exactly

Documentation map

Doc

Purpose

INSTALL.md

Full install, verification, upgrades, developer setup

AGENTS.md

Environment variables, Docker, MCP tuning, contribution workflow

This README

Overview, auth walkthrough, downloads, clients, code mode

📄 License

This project is licensed under the MIT License — see the LICENSE file for details.

Security: report vulnerabilities through GitHub private security advisories for this repository.

Available Tools

4 tools
executeA

Run async Python in a sandboxed interpreter. The whole script runs as one turn; use return to produce the tool result.

Available in scope:

  • await call_tool(name: str, params: dict) -> Any — calls any backend tool. Failures raise RuntimeError(<envelope_json>) where the message body is the full v1 cross-server error envelope JSON. Inside the sandbox: try: await call_tool(name, params) except RuntimeError as e: env = json.loads(str(e)) # env['error_kind'], env['hints'], env['error_code'], # env['retryable'], env.get('_meta', {}) all available. Non-envelope failures fall back to RuntimeError("<OriginalType>: <message>"). Both forms are catchable with try/except RuntimeError:. The format matches Amazon SP MCP for cross-server symmetry.

Sandbox guardrails (Monty interpreter):

  • No network: urllib, requests, httpx, socket not importable. Use call_tool.

  • No filesystem writes: open() is missing from builtins; os and pathlib import successfully but most side-effecting methods are gated. Tool results larger than ~1 MB may be auto-stashed by the host client.

  • Stdlib (verified against pydantic_monty==0.0.11; allowlist is hardcoded in Monty's compiled extension and not configurable from Python — may differ on other CodeMode hosts running a different pydantic_monty):

    • Available: json, re, math, datetime, sys, typing, asyncio, os, pathlib.

    • Blocked: collections, itertools, functools, statistics, decimal, dataclasses, random, string, time, base64, hashlib, urllib.parse. Use built-ins and comprehensions for aggregation; for hashing/encoding/URL work, request a server-side tool via await call_tool(...).

  • Builtins (verified missing / behavior differences):

    • hasattr(o, k) is unavailable. Use a unique sentinel with getattr: _MISSING = [] (or {}), then getattr(o, k, _MISSING) is not _MISSING. object() is unavailable in this sandbox.

    • callable(x) is unavailable and getattr(x, '__call__', None) is not None is not reliable for built-in instances or functions in this sandbox. Prefer known-callable inputs, or guarded invocation with try: x(...); except TypeError: when safe.

    • No reliable capability-probing on objects. The _MISSING sentinel pattern above works for module attributes (e.g. getattr(math, 'pi', _MISSING)) but not for methods on built-in instances or attributes on user-defined functions. In this sandbox, built-in methods are invokable via d.keys() syntax but are not reachable as attributes via d.keys (which itself raises AttributeError). Same for function attributes — fn.__name__ raises AttributeError. getattr(o, k, default) returns default for these cases not because getattr is misbehaving but because the attribute isn't there. Write code that knows the shape of its inputs rather than probing for capabilities.

    • setattr, dir, vars, globals, locals, open are all absent.

  • Blocked-import error semantics: inside the sandbox, from collections import Counter raises a stock Python ImportError (NOT a RuntimeError-wrapped envelope). Catch with except ImportError: (or except Exception:). The v1 sandbox_runtime / SANDBOX_MODULE_BLOCKED envelope only fires when the import error is uncaught and propagates out of execute — at which point the calling tool layer sees the typed envelope.

  • Unsupported-syntax error semantics: class definitions, match statements, and other parser-not-yet-supported constructs raise a NotImplementedError that DOES surface as a v1 envelope with error_kind=sandbox_runtime / error_code=SANDBOX_RUNTIME_ERROR. Asymmetric with imports — known limitation.

  • print() output may be discarded depending on the client path; return data via the script's final expression instead.

  • asyncio.sleep is unavailable by design in this sandbox path. Don't sleep — chain await call_tool calls (e.g. poll a report-status tool) instead. For long-running reports (typically 1-20 minutes), do NOT rapid-poll inside a single execute block; return after one status check and let the user decide when to re-check.

  • try/except/finally work normally. To probe many candidates in one block, wrap each await call_tool(...) in its own try/except RuntimeError.

  • with works for pure-Python context managers (e.g. decimal.localcontext()). It does NOT work for open(...) because file I/O is blocked.

  • json.dumps(default=...) may trip on Pydantic models; call model_dump() first.

Auth, region, and active profile are managed by the server. Do not pass Amazon-Ads-AccountId, Amazon-Advertising-API-Scope, or bearer tokens in params — set them once via set_active_identity / set_region / set_active_profile and they ride every subsequent call_tool.

Session-scope contract:

  • Call get_session_state first; if state_scope == 'request', re-run set_active_identity / set_region / set_active_profile in each execute block. If state_scope == 'session', set them once via the corresponding tools and they ride subsequent call_tool calls in that session.

  • To detect the transport's scope, call get_session_state at the start of a block. It is a read-only probe with no side effects.

  • Rule: Re-establish context before the next tool call iff state_scope == 'request' or state_reason is not null.

  • Within a block the scope cannot change; one probe per block is sufficient.

  • state_reason enumerates: "no_mcp_session" (request-scoped transport), "token_swapped" (a different bearer/refresh token arrived mid-session and the previous tenant's state was cleared — state_scope stays 'session' but you must re-establish context for the new tenant), and "bridge_unavailable" (reserved; treat as 'request').

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesPython async code to execute tool calls via call_tool(name, arguments)

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and delivers detailed behavioral information: sandbox guardrails (no network, no filesystem, blocked imports), missing builtins, error behavior, and session-scope nuances. It is exceptionally transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very long but well-structured with clear sections (sandbox guardrails, builtins, auth, session-scope contract). While length is justified by complexity, it could be more concise without losing essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and lack of output schema, the description covers all necessary aspects: purpose, usage, environment, error handling, auth, and session management. It leaves no critical gaps for the AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 100%, the description adds immense value beyond the schema's brief parameter description. It explains the execution environment, available functions (call_tool), and how to structure code, vastly enriching parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear statement: 'Run async Python in a sandboxed interpreter.' It explicitly describes the tool's function and distinguishes it from siblings (tags, search, get_schema) which are unrelated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides extensive guidance including session-scope contract, auth handling, error semantics, and explicit do's and don'ts (e.g., 'Call get_session_state first', 'Do NOT rapid-poll inside a single execute block'). It effectively tells the agent when and how to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_schemaA

Get parameter schemas for specific tools.

Use after searching to get the detail needed to call a tool.

ParametersJSON Schema
NameRequiredDescriptionDefault
toolsYesList of tool names to get schemas for
detailNo'brief' for names and descriptions, 'detailed' for parameter schemas as markdown, 'full' for complete JSON schemasdetailed

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description does not disclose any behavioral traits such as side effects, authorization needs, or rate limits. For a read-only tool, the description could mention that it is non-destructive, but it remains silent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. Essential information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool is simple, output schema exists, so description doesn't need to explain return values. The description covers the essential usage flow, but slight improvement could mention that it returns JSON schemas.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds context about using after searching, which helps understand the purpose of the 'tools' parameter, but doesn't add extra meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool gets parameter schemas for specific tools. Verb 'get' and resource 'parameter schemas for specific tools' are specific and distinct from sibling tools like execute, search, and tags.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use after searching to get the detail needed to call a tool.' This gives clear context for when to use it, though it doesn't mention when not to use or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tagsA

List available tool tags.

Use to browse available tools by tag before searching.

ParametersJSON Schema
NameRequiredDescriptionDefault
detailNoLevel of detail: 'brief' for tag names and counts, 'full' for tools listed under each tagbrief

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite lacking annotations, the description accurately conveys a read-only listing behavior. No side effects or additional traits needed; the simplicity of the tool makes the description sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two short sentences, front-loading the main purpose immediately. Every word is purposeful without any waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, one optional parameter, and an existing output schema, the description is nearly complete. It could mention that results include tag names and counts or tools, but the output schema fills this gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides full coverage (100%) with a clear description of the 'detail' parameter including enum values. The description adds no extra parameter details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists available tool tags, with a specific verb and resource. It distinguishes from siblings like 'search' and 'execute' by focusing on browsing tags before searching.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description suggests using 'tags' to browse available tools by tag before searching, providing a clear when-to-use hint. However, it does not explicitly mention when not to use or compare to alternatives like 'search'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv0.3.29
    • Addedexecute
    • Addedsearch
    • Addedtags
  2. 3 tool updatesv0.3.27
    • Removedexecute
    • Removedsearch
    • Removedtags
  3. 24 tool updatesv0.3.13
    • Removedac_CreateTermsToken
    • Removedac_GetAccount
    • Removedac_getProfileById
    • Removedac_GetTermsToken
    • Removedac_ListAdsAccounts
    • Removedac_listProfiles
    • Removedac_RegisterAdsAccount
    • Removedac_updateProfiles
    • Removedclear_active_profile
    • Removeddownload_export
    • Addedexecute
    • Removedget_active_identity
    • Removedget_active_profile
    • Removedget_region
    • Removedget_routing_state
    • Addedget_schema
    • Removedlist_downloads
    • Removedlist_identities
    • Removedlist_regions
    • Addedsearch
    • Removedset_active_identity
    • Removedset_active_profile
    • Removedset_region
    • Addedtags
  4. 20 tool updatesv1.0.0
    • First observedac_CreateTermsToken
    • First observedac_GetAccount
    • First observedac_getProfileById
    • First observedac_GetTermsToken
    • First observedac_ListAdsAccounts
    • First observedac_listProfiles
    • First observedac_RegisterAdsAccount
    • First observedac_updateProfiles
    • First observedclear_active_profile
    • First observeddownload_export
    • First observedget_active_identity
    • First observedget_active_profile
    • First observedget_region
    • First observedget_routing_state
    • First observedlist_downloads
    • First observedlist_identities
    • First observedlist_regions
    • First observedset_active_identity
    • First observedset_active_profile
    • First observedset_region

TDQS

A3.6/5.0
Disambiguation5/5

Each tool has a distinct purpose: 'tags' lists tags, 'search' searches tools, 'get_schema' retrieves schemas, and 'execute' runs sandboxed Python. No overlap or ambiguity.

Naming Consistency3/5

Tool names are mixed: 'tags' is a noun, 'search' and 'execute' are verbs, 'get_schema' is verb_noun. They are readable but lack a consistent pattern.

Tool Count4/5

With 4 tools, the set is compact and appropriate for a meta-server focused on discovery and execution. Not too many or too few.

Completeness2/5

The server claims to be for the Amazon Ads API but provides only meta-tools. Core API operations (e.g., listing campaigns, creating ads) are missing, leaving a significant gap for the stated purpose.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

  • Build, edit and sync Google, Microsoft, Reddit and Meta ad campaigns from your assistant.

  • Manage Google, Meta, Amazon, TikTok, LinkedIn & ChatGPT ads. 430 tools for campaigns & analytics.

  • Amazon Seller Central and Amazon Ads for AI assistants: catalog, orders, FBA, pricing, PPC.

  • Connects Amazon Seller Central and Amazon Advertising to any MCP client. Settlement-accurate P&L - every fee, refund and reimbursement as Amazon posted it - plus contribution margin and breakeven per product, per marketplace, per day. Full Sponsored Products, Brands and Display management: search terms, placements, keyword and competitor research, dayparting, automation rules. 107 tools: 72 read-only, 29 that stage a reviewable diff for your approval, and 6 confirmation/support actions. Write tools stage a reviewable diff; applying it takes a separate confirmation.

Related MCP Servers

  • F
    license
    Not graded
    quality
    F
    maintenance
    Enables users to analyze, manage, and optimize digital advertising campaigns through natural language conversations in Claude, offering performance insights, interactive visualizations, and campaign management for platforms like Amazon Ads.
    4
    -
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI assistants to manage TikTok advertising campaigns through the TikTok Ads API. Supports campaign creation, performance analytics, audience management, creative operations, and custom reporting through natural language interactions.
    48
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Enables natural language querying of Amazon Advertising data including Sponsored Products, Brands, Display, DSP reports, and AMC SQL workflows, with live data from the Amazon Ads API.
    23
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables LLMs to interact with the Google Ads API through the Model Context Protocol, allowing natural language queries for campaign management and metrics.
    Apache 2.0

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/KuudoAI/amazon_ads_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server