amazon-ads-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AMAZON_ADS_ENV_FILE | No | Path to a .env file containing the credentials | |
| AMAZON_ADS_CLIENT_ID | No | Amazon Ads API client ID | |
| AMAZON_ADS_CONSENT_DATE | No | Optional consent date (YYYY-MM-DD) to warn before 365-day expiry | |
| AMAZON_ADS_CLIENT_SECRET | No | Amazon Ads API client secret | |
| AMAZON_ADS_MCP_READ_ONLY | No | Set to '1' to remove write tools | |
| AMAZON_ADS_REFRESH_TOKEN | No | Amazon Ads API refresh token |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| api_notesA | Amazon Ads API behavior the official docs do not state. Read once per session. |
| list_profilesA | Every advertising profile (account x marketplace) the credentials reach. |
| list_entitiesA | List Sponsored Products entities in one market. entity: campaigns, ad_groups, keywords, targets, negative_keywords, negative_targets, campaign_negative_keywords, campaign_negative_targets, product_ads or portfolios. States default to ENABLED and PAUSED; include_archived lists every state. text_contains filters keywords, names and ASINs case-insensitively after fetching. |
| get_suggested_bidsA | Amazon's suggested low/median/high bid next to the live bid, for existing enabled keywords or targets (kind: "keywords" or "targets"). |
| get_suggested_bids_for_newA | Suggested bids before an ad group exists: for the book(s) in |
| get_change_historyC | What changed, from what, to what and when (up to 90 days back). since: ISO date or datetime; otherwise the last |
| run_reportA | Run a report (dates YYYY-MM-DD, any length) and return rows or totals. preset: sp_campaigns, sp_placement, sp_ad_groups, sp_targeting, sp_search_terms, sp_advertised_products, sp_purchased_products. group_by (e.g. ["campaignName", "placementClassification"]) sums numeric columns per group instead of returning daily rows. save_to writes every row to a JSON file. |
| search_operationsB | Find any of the ~1,200 operations in Amazon's published specs by keyword. |
| call_operationA | Call a read-only operation from Amazon's specs by id (see search_operations). Operations that can change data are refused here; use a plan tool instead. |
| get_planB | A saved plan's table, fingerprint and status (applied or not). |
| list_plansB | Recent plans, newest first, with whether each was applied. |
| plan_updateB | Build (not apply) an update: each change is the entity id plus new values, e.g. {"keywordId": "123", "bid": 0.45} or {"targetId": "9", "state": "PAUSED"}. |
| plan_createB | Build (not apply) a create, e.g. keywords [{"campaignId", "adGroupId", "keywordText", "matchType": "EXACT", "bid": 0.5, "state": "ENABLED"}]. |
| plan_archiveB | Build (not apply) an archive. Archiving cannot be undone; prefer pausing. |
| plan_restore_from_historyA | Build (not apply) a plan restoring bids and states to what they were at
|
| apply_planA | Apply a saved plan. Only call after the user approved this exact plan. fingerprint must equal the one returned when the plan was built or fetched, which guarantees the plan being applied is the one that was shown. With check_drift (default) the plan is refused if any value changed since it was built. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| api_notes |
TDQS
Scored across 16 tools
Each tool serves a clear function: list/get for reads, plan_* for building changes, apply for execution, run_report for analytics, and history/bids/operations for specific lookups. The two suggested-bid tools are explicitly separated by 'existing' vs 'new', and the plan tools are distinct despite sharing a prefix.
Most tools follow a verb_noun pattern (list_profiles, get_change_history, run_report, apply_plan), but the plan-building tools invert it (plan_update, plan_create, plan_archive, plan_restore_from_history) and api_notes is a bare noun. The mixed conventions are still readable, but the inconsistency is noticeable across a subset of tools.
16 tools is slightly above the typical 3-15 range, but the Amazon Ads domain is broad enough to warrant the extra surface. The plan sub-system uses 7 tools, yet each covers a distinct phase of the plan lifecycle, and the remaining tools handle entities, bids, history, reports, and API introspection.
The set covers the core workflows: listing profiles/entities, checking bids, viewing change history, running reports, and mutating state through a well-designed plan system (create, update, archive, restore, apply). Minor gaps like a dedicated single-entity getter or direct write operations are handled reasonably through list filtering and the plan-based write path.