Intentwise

Run an Amazon Marketing Cloud (AMC) analytics query from a natural-language question and return structured report results. WHEN TO USE THIS TOOL — use ONLY when BOTH conditions are true: 1. The account's `type` field from `get_intentwise_accounts` is `AMAZON_MARKETING_CLOUD`. Regular Amazon Seller/Vendor/Ads/DSP accounts do NOT have AMC data — use `get_insights` for those. 2. The user's question is about an AMC report. AMC is Amazon's privacy-safe clean room — it provides anonymized, event-level signals across Sponsored Ads and DSP to produce cross-channel insights (path-to-conversion, exposure group analysis, frequency distribution, geographic reach, NTB analysis across all ad product types) that standard per-format ad reporting cannot. Supported reports: - Sponsored Ads vs DSP overlap (reach, unique reach, NTB metrics, ROAS by exposure group) - New-to-brand gateway ASINs (which promoted ASINs attract the most NTB customers) - ASIN purchase overlap / upsell (which ASINs are bought together, product affinity, cross-sell) - DSP campaign performance by geography (reach, purchases, ROAS broken out by country, state, or DMA — geographic DSP breakdown does NOT exist in standard DSP reporting; always use this tool for geo questions) - DSP reach and impression frequency (unique users reached and frequency distribution by bucket: how many users saw 1×, 2–3×, 4–6×, 7+× impressions — standard DSP has total impressions only, NOT per-bucket distribution; always use this tool for frequency distribution questions) - Path-to-conversion / customer journey analysis (which ad touchpoint sequences led to purchase, most efficient paths, NTB journeys) - Path-to-conversion with Brand Store / BSI touchpoints (paid dataset; brand-store-influenced journeys) - Customer audience / shopper funnel (impressions → clicks → conversions by NEW TO BRAND vs REPEAT; CAC) - Organic vs ad-exposed purchases by ASIN (non-ad-exposed vs ad-exposed shoppers, sales, NTB, Subscribe & Save) - New-to-brand customer impact (NTB rate, NTB sales by ad product type or campaign) - Ad-attributed branded searches (which DSP campaigns drive branded keyword searches on Amazon) - Time-to-conversion (how long after seeing an ad customers make a purchase — time bucket distribution) - Tentpole phase overlap (ad strategy performance across Lead Up, Event Day, and Lead Out phases for peak events like Prime Day and Black Friday) - Shopper insight abandonment events (ASIN-level cart abandonment, detail page view drop-off, purchase funnel analysis, and NTB buyers per product) - Custom first-touch attribution (28-day window; 100% credit to first touchpoint — which channels/campaigns attract customers) - Custom last-touch attribution (28-day window; 100% credit to last touchpoint — which channels/campaigns convert customers) - Custom linear-touch attribution (28-day window; equal credit across all touchpoints — full-path contribution; may include fractional conversions) - Brand lifetime revenue from Amazon Retail Purchases / ARP (NTB cohort 3/6/12-month LTR by brand and purchase month; revenue-only, no ad cost) - Purchase frequency from ARP (how many users bought 1x vs 2x vs 3x+ for a brand) - Days between purchases from ARP (repurchase cadence / day-gap distribution by brand) - ASIN-level (entry product) lifetime revenue from ARP (product vs customer LTR for NTB entry ASINs) - Brand Store page performance (sessions, visits, dwell time, and purchase conversions attributed to the last Brand Store page viewed before purchase — use for which pages drive the most engagement or NTB purchases) Do NOT use this tool for standard campaign/keyword/bid performance, Seller Central, or Vendor Central questions — use `get_insights` for those. PREREQUISITE SEQUENCE: 1. Call `get_organization` to obtain your organization_id. 2. Call `get_intentwise_accounts(organization_id=..., account_type_filter='AMAZON_MARKETING_CLOUD')` to find AMC accounts. Only accounts with type=AMAZON_MARKETING_CLOUD can be queried with this tool. If no accounts are returned, the organization has no AMC integration set up. 3. Call this tool with the AMC account_id from step 2. COMPOUND QUERIES — When the user asks about multiple AMC reports in one question (e.g. 'show overlap AND NTB gateway ASINs'), make SEPARATE calls — one per report slug. If the user asks for both AMC data AND standard advertising data (e.g. 'compare DSP overlap with campaign spend'), make SEPARATE calls: use this tool for the AMC part and `get_insights` for the standard part. Within a single AMC report, a single call handles all filters, groupings, and date ranges — do NOT split one report question into multiple calls. CLARIFICATION HANDLING — when `needs_clarification: true` the response carries a `status` and an `options` list. The `status` determines the option shape: STATUS `needs_clarification` (multiple complete query configurations exist): Each option has a `summary` sub-object. Present each option to the user with: - `summary.report_title` — the query configuration title. Always show this. May contain multiple titles joined with ' / ' (e.g. 'Monthly PTC / Quarterly PTC') when the execution set combines data from different query configurations — present it as-is. - `summary.coverage` — the date period covered by this option. Always show this. - `summary.input_parameters` — 'parameterized' means the query was run with specific advertiser/filter inputs; 'all advertisers' means no input filter was applied. Always mention this. - `summary.labels` — custom tags assigned to the query. Show only if non-empty. - `summary.exact_period_match` — true if coverage exactly matches the requested period. Ask the user to choose one, then re-call with the chosen option's `report_event_ids`. STATUS `partial_coverage` (data exists but does not fully cover the requested period): Each option has `id`, `label`, `report_event_ids`, and `covered_ranges` (no `summary`). Present the user with two choices: - Option id=1: proceed with available data — show `label` and the date range from `covered_ranges`. - Option id=2: skip — the user will ask for a different period. If the user picks id=1, re-call with those `report_event_ids`. If the user picks id=2 (empty `report_event_ids`), do NOT call this tool again. STATUS `not_trendable` (trend requested but report windows overlap — cannot be time-series): Each option has `id`, `label`, `report_event_ids` (no `summary`). Tell the user the report cannot be trended (consecutive executions cover overlapping windows and are not independent data points). Present two choices: - Option id=1: show a point-in-time overview using the most recent execution — use `label` for the window. - Option id=2: skip. If the user picks id=1, re-call with those `report_event_ids`. If the user picks id=2, do NOT call this tool again. COMPARISON CLARIFICATION — for comparison queries, `options` is a list of two objects, one for `period: current` and one for `period: previous`, each with its own `options` list and `start_date`/`end_date`. Each inner option has the same `summary` structure as `needs_clarification` above. Present both periods to the user and ask them to select a configuration for each. When re-calling, pass the chosen current-period option's `report_event_ids` as `report_event_ids` AND the chosen previous-period option's `report_event_ids` as `previous_report_event_ids`. Do NOT merge them into a single flat list. In all cases: each option's `report_event_ids` is a list of pre-resolved execution event IDs — you do NOT need to extract or derive them yourself. NO MATCHING OUTPUT — if status is `no_matching_output`, the AMC report exists but has no execution data for the requested date range. Do NOT retry. The user needs to run the AMC query in the 'My Queries' section of the Intentwise Explore AMC app to generate execution data. HANDLING FAILED QUERIES — If this tool returns an `error` status or an unexpected response: (1) Check whether the report slug and date range are valid. (2) Make at most ONE retry with a corrected question or a narrower date range. (3) If it fails again, do NOT keep retrying. Inform the user the query could not be completed and suggest they verify the AMC report is set up in Intentwise Explore AMC. Never make more than 2 attempts for the same question. RESPONSE — on success, returns rows with AMC metrics grouped by the dimensions in parameters.group_by. The actual query filters applied (other_filters, having_clause, etc.) are in parameters. GRAND-TOTAL ROW — when parameters.include_totals is '1=1' (the default), the FIRST row in the list is a grand-total aggregate where all grouping columns are null. It is NOT missing or unattributed data — it is the SUM across all groups. Always label it 'Grand Total' when presenting to the user; never call it 'Unattributed' or '(null)'. When include_totals is '1=0' (suppressed for filtered/top-N queries), no such row is present. TREND QUERIES — for trend questions ('show weekly overlap for last 3 months'), the pipeline resolves all execution events across the trend window and returns the full time series in rows. When present, metadata.available_cadence indicates the cadence at which AMC execution data exists for this report ('weekly', 'monthly', or 'quarterly'). If the user requested a different grain (e.g. 'daily'), inform them that data is only available at the detected cadence. If status is `not_trendable`, the report's execution windows overlap (e.g. the report is scheduled weekly but each run covers LAST_30_DAYS) — trending is NOT possible. In this case `needs_clarification: true` is set and options are provided: one to show a point-in-time snapshot of the most recent execution, one to skip. Tell the user clearly: 'This report cannot be trended because consecutive execution windows overlap and are not independent data points.' The `question` field in the response includes the exact window size derived from actual execution dates — include that detail when informing the user. Offer the snapshot option if the user still wants to see any data. DATASET PROFILE — metadata.dataset_profile (when present) is a pre-query scan of available data. It is scoped ONLY by the filter_context nested within it (account_id + report_event_ids). It does NOT apply other_filters, having_clause, or any user-specified dimension filters from the generated query. Use it to diagnose 0-row results: if dataset_profile shows non-zero sum_ totals, data exists for that account/event-set but the user's specific filters returned nothing. IMPORTANT: dataset_profile totals will NOT match the sum of returned rows when the query applied extra filters or a row limit — this is expected, not a data inconsistency. Fields follow two naming conventions: (1) Fields prefixed with 'sum_' are unfiltered metric totals — use them to confirm data exists and to quantify how much was excluded by user filters. (2) Array fields (lists of strings) are distinct values for low-cardinality enumerable dimensions such as exposure group, ad product type, frequency bucket, or time bucket — use them to suggest valid alternatives when a dimension filter returns 0 rows. High-cardinality dimensions (e.g. campaign names, ASINs, conversion paths) are intentionally excluded from dataset_profile to avoid misleading partial lists — their absence does NOT mean no data exists; only the sum_ totals confirm that. Example: if sum_total_purchases > 0 but the main query returned 0 rows, the user's filter was too narrow. Check array fields to suggest which dimension values actually exist, or advise the user to broaden their filter. COVERAGE WINDOW — metadata.dataset_profile.filter_context contains requested_start_date / requested_end_date (what the user asked for). When available, filter_context also contains covered_start_date / covered_end_date (the actual window the AMC execution data covers). When covered dates differ from requested dates, mention this to the user so they understand the data scope. Present the data and insights; report slugs, SQL, and event IDs are diagnostics.

get_amc_insights

Adds one or more products to conversion tracking for a DSP campaign. Products are appended to the campaign's existing tracking list. CHANNEL: Only 'AMAZON_DSP' is supported; set channel to 'AMAZON_DSP'. PREREQUISITE — organization_id, account_id, campaign_id, and channel are required: 1. Call get_organization to discover your organization_id. 2. Call get_intentwise_accounts to discover available accounts and their account_id. 3. The campaign_id must reference an existing DSP campaign (from create_campaign). PRODUCT ASSOCIATION — For each product, set productAssociation appropriately: - FEATURED: ASIN promoted in campaign creatives. - FEATURED_WITH_VARIATION: featured ASIN with variation tracking. - NOT_FEATURED: additional ASINs to track beyond featured/parent ASINs. Tracking non-featured ASINs prevents conversion data loss after the campaign starts. IMPORTANT: Before calling this tool, present a consolidated plan listing all ASINs, domains, and association types. Receive explicit user approval before proceeding. RESPONSE HANDLING — The tool returns JSON from the agent API: - On full success: a `message` field summarizing what was added. Present `message` to the user. - On per-product failure or partial success: `errors` (array), `success` (array), and `requestId`. Each item in `errors` has `index` (position in product_tracking_list) and `subErrors` (each with `errorCode`, `errorMessage`, and optional `errorId`). Present each `subErrors[].errorMessage` to the user, map `index` to the ASIN that failed, and include `requestId` when reporting issues. If `success` is non-empty, report which products were added and which failed. - On validation gaps: `needs_clarification` with `question` and `missing` fields. - On gateway/auth failures: `error`, `status`, and `message` (generic; no agent detail).

dsp_create_conversion_tracking_products

Generate and execute a BigQuery SQL query from a natural-language request for a SINGLE account per call. Channels (REQUIRED — pick one): 'amazon' (data sources: ads, seller_central, vendor_central, dsp, share_of_voice, content), 'walmart' (data_source 'ads', or 'seller'/'vendor' marketplace), 'criteo' (retail-media 'ads' across retailers — Target/Roundel, Dick's Sporting Goods, Golf Galaxy, Lowe's, Best Buy, Costco — filter by retailer_name), 'instacart' ('ads', mcp_instacart_data), 'tiktok' ('ads' for Ads or 'tiktok_shop' for TikTok Shop, mcp_tiktok_data), 'meta' ('ads', mcp_meta_data), and 'google' (Google Ads 'ads', mcp_google_data). DISAMBIGUATION: 'channel' is the PLATFORM; data_source (ads, dsp, seller_central, vendor_central, share_of_voice, content, tiktok_shop, Walmart seller/vendor) is a SEPARATE choice WITHIN a channel — never present a data_source like 'Amazon DSP' or 'Amazon Seller Central' as a platform option. If the account has more than one ads channel (e.g. both Amazon and Criteo, or Amazon and Walmart) and the user's request does not make the platform clear, ask which platform before calling this tool — do NOT guess, and do NOT list data_sources as the choices. Only SELECT queries on intentwise_ecommerce_graph tables are supported. INSERT, UPDATE, DELETE, MERGE and other write operations are not supported. PREREQUISITE — organization_id, account_id, channel, and data_source are all required. When the account has more than one ads channel and the right one is unclear, ask the user rather than guessing. Follow this sequence: 1. Call `get_organization` to discover your organization_id. 2. Call `get_intentwise_accounts(organization_id=...)` to discover available accounts. Each account includes available_data_sources — a list of { data_source_type, channel } pairs representing the active integrations for that account. IMPORTANT: before calling this tool, verify that the channel and data_source you intend to pass exist as a matching pair in the account's available_data_sources. If the combination is not present, do NOT call this tool — the data source is not enabled for that account. Accounts with an empty available_data_sources list have no active integrations and cannot be queried. 3. Call `search_schema` at least once per session with the user's query text to discover the available tables and their descriptions. For DSP queries (orders, line items, order goal, awareness/consideration/conversion), pass channel=amazon and data_source=dsp so results are from the DSP schema; otherwise you may get Sponsored Ads (ecommerce) tables. The schema contains similarly-named tables that serve different purposes (e.g., product_summary = holistic product data with organic metrics; advertised_product_summary = ad-level product data by campaign/adgroup — no organic metrics; product_summary = pre-joined flat table at ASIN x day grain with ads, SC/VC sales, SC traffic (sessions, page views, buy box), and VC glance views — use for any product-level cross-metric analysis instead of joining multiple product reports). The search results include table descriptions that explain when to use each table. After reviewing search results, fetch the relevant table resource via resources/read using the resource_id from search results (e.g. schema://intentwise-ecommerce-graph/v1/table/<table_name> for ads, schema://intentwise-dsp/v1/table/<table_name> for DSP, schema://intentwise-seller-central/v1/table/<table_name> for Seller Central, schema://intentwise-vendor-central/v1/table/<table_name> for Vendor Central) to see columns, semantic_layer, allowed group-by sets, and enum values. Each table resource includes channel, data_source, and in most cases an entity field — read the entity value from the resource and pass it directly to get_insights. Examples: searchterm_summary → entity=search_term; sellercentral_ordersbydate_report → entity=order; dsp_order_report → entity=order; dsp_lineitem_report → entity=lineitem; dsp_creative_report → entity=creative; dsp_audience_report → entity=audience; search_query_performance → entity=search_query; sellercentral_awd_inbound_shipment (AWD inbound) → entity=awd_inbound_shipment; sellercentral_awd_inventory (AWD inventory) → entity=awd_inventory; store_asin_engagement (Brand Store ASIN engagement) → entity=store_asin_engagement; store_page_insights (Brand Store page insights) → entity=store_page_insights; repeat_customers (Brand Analytics) → entity=repeat_customers; product_listing → entity=product_listing; share_of_voice → entity=share_of_voice; Once you have cached this schema knowledge for the session, you do not need to call search_schema again for similar queries. 4. Call `get_insights(organization_id=..., account_id=..., channel=..., data_source=..., text=..., entity=...)` with all required parameters. Pass entity whenever it can be resolved — either from the entity field in the table resource (step 3). If you are not sure about the entity, omit the entity parameter. Date ranges and context are resolved server-side by the insights service. Supports analytics including: (1) period-over-period comparisons (last 30 days vs previous 30 days, WoW, MoM, QoQ, YoY), (2) trend/time-series queries (daily/weekly/monthly), and (3) grouped breakdowns (group by campaign, keyword, product, country, etc.). Examples: 'Show spend for last 30 days'; 'Top 10 campaigns with biggest spend drop comparing last 30 days vs previous 30 days'; 'Show weekly spend trend for last 12 weeks'. For multi-account analysis, call `get_insights` once per account_id and aggregate results client-side. For period-over-period comparisons (WoW, MoM, QoQ, YoY, or any two date ranges) on the SAME account, make a SINGLE call with both the current and previous date range expressed in the text — do NOT make two separate calls per period. The insights service handles both windows in one query. Present the data and insights; SQL and schema details are diagnostics. COMPOUND QUERIES — When the user asks for multiple distinct analyses in one question (e.g., '(1) monthly DSP totals AND (2) top 10 DSP orders by spend', 'account summary and also top 5 campaigns'), decompose into separate get_insights calls, one per analysis — each likely needs a different entity (e.g., account for monthly totals, order for top 10 orders) — and present both result sets. Signs: numbered sub-requests '(1)… (2)…', 'and also', 'additionally', 'plus show me', or two analyses with different grouping dimensions. Do NOT combine analyses into one text parameter — the service generates one SQL query per call and cannot produce two differently-shaped result sets. CROSS-ENTITY QUERIES — Each get_insights call queries ONE entity (one table or a pre-built template that internally joins a fact+dimension pair for that entity). Before calling get_insights, call search_schema with the key metrics/dimensions from the user's question and check: - If ONE table has all the columns the user needs → single call. - If columns are in a fact+dimension pair of the SAME entity (e.g., dsp_order_report metrics + dsp_order names — both entity='order') → single call; the template handles it. - If metrics are spread across DIFFERENT tables but the user's key filter/grouping column (e.g., ASIN, campaign_name) exists in ALL those tables → make SEPARATE get_insights calls per table, combine the results by that shared dimension. Example: 'inventory and ad spend for ASIN X' — inventory table has ASIN, product_daily_summary has ASIN and ad spend → two calls (inventory entity + product entity), combine by ASIN. Do NOT join inventory with product_daily_summary inside a single query. - If the user's question requires RELATING two different entities and the key filter/grouping column does NOT exist in one of the tables → this is NOT SUPPORTED. Tell the user this query is not currently supported. Do NOT retry with different entities or guess workarounds. Example: 'keywords for ASIN X' on daily keyword_summary has no ASIN column — do NOT use entity='keyword' or entity='target'; instead use entity='marketing_stream' (ad_marketingstream_traffic has keyword_text and product/ASIN on the same row). HANDLING FAILED QUERIES — If a call fails or returns no data, do NOT retry with different entities; call search_schema to confirm the needed columns, then apply the CROSS-ENTITY rules above (multi-step if the shared column exists, else tell the user it is not supported). Never make more than 2 retry attempts for the same question. IMPORTANT: This tool always returns row-based tabular data. If the user asks for pivot tables, side-by-side column comparisons, or cross-tab views (e.g., 'show SP spend vs SB spend as separate columns'), query the data with the relevant dimension in group_by (e.g., campaign_type) and reshape/pivot the results client-side before presenting to the user. Do NOT pass pivot/reshape instructions in the text parameter. NOT A DATA EXPORT TOOL — get_insights is for analytical queries, NOT bulk extraction. Filtered or reasonably-scoped queries are fine (even daily grain over longer periods). NOT supported: blanket requests with no meaningful filter ('all products', 'every SKU/ASIN', 'all campaigns'), daily grain over >90 days, or requests designed to dump thousands of raw rows. For such asks, tell the user this tool provides analytical insights and suggest a filter (specific ASINs/campaigns or top-N), a narrower date range, a coarser grain (weekly/monthly), or the Intentwise platform's export. Do NOT batch multiple calls to work around row limits. UNSUPPORTED DATA — DO NOT call get_insights for these topics. Instead, tell the user this data is not currently available in Intentwise: - Competing offers: number of competing sellers, Buy Box competitors count, competitor pricing. - Keywords by ASIN on daily keyword_summary: that table has no ASIN column — do NOT use entity='keyword' or entity='target' for 'top keywords for ASIN X' / product × keyword performance. Use entity='marketing_stream' instead (keyword_text and product/ASIN on the same row). Suggest advertised_product only for product × campaign metrics without a keyword cut. Customer search-terms by ASIN remain unsupported (searchterm_summary has no ASIN; Marketing Stream has no customer search-term text). - Dayparting / hourly data: hourly ad PERFORMANCE — spend, revenue, impressions, clicks, orders, conversions and derived CTR/CPC/conv_rate/ACOS/ROAS by hour — IS available via Amazon Marketing Stream (entity='marketing_stream', data_source=ads); route ANY hourly / by-hour-of-day / dayparting / intraday ad question there, INCLUDING hourly ACOS/ROAS/orders/revenue. Vendor Central Rapid Retail Sales (entity='rapid_retail_sales', data_source=vendor_central) is hourly for ordered units/revenue. So flag hourly as unavailable ONLY for ad ACOS/ROAS/conversions/revenue. - Product reviews text: individual review text and sentiment not available. - PPC bid recommendations: bid suggestions not available via analytics. MIXED QUERIES — If the user asks for both supported AND unsupported metrics (e.g., 'buy box % and competing offers'), call get_insights with ONLY the supported portion in the text parameter. Present the results for the supported part, then separately inform the user which specific metrics are not currently available. Do NOT omit the supported part just because one piece is unavailable. Do NOT include unsupported metrics in the text parameter hoping the system will ignore them. RESPONSE HANDLING — On success, check metadata.enrichment_hint. If present, some requested metrics were omitted from this query. Follow the hint: (1) derive the metric client-side from returned columns if possible, (2) otherwise call search_schema to find which entity has it, make a follow-up get_insights call, and merge results by the shared key (e.g., ASIN). On success, returns template_id, generated SQL, parameters, metadata, and result rows.

get_insights

Creates one or more Amazon ad associations in a single batch call. An ad association links an ad (creative) to an ad group (line item). This tool supports BULK creation — pass multiple associations in the dsp_ad_associations array to create them all in one request instead of calling the tool repeatedly. CHANNEL: Only 'AMAZON_DSP' is supported; set channel to 'AMAZON_DSP' and populate 'dsp_ad_associations'. PREREQUISITE — organization_id, account_id, adGroupId, adId, and channel are required: 1. Call get_organization to discover your organization_id. 2. Call get_intentwise_accounts to discover available accounts and their account_id. 3. Deduce the channel from the user's request. 4. The adGroupId must reference an existing ad group (line item). Use create_ad_group first if needed. 5. The adId must reference an existing ad (creative). Obtain by calling query_structure_data_by_entity_type. IMPORTANT: Before calling this tool, present a single CONSOLIDATED plan summary covering ALL ad associations (ad group, ad/creative, etc. for each) in one view. Receive explicit user approval on the full plan before proceeding. Never call this tool without prior user confirmation. RESPONSE HANDLING — On success, the tool returns JSON with a `message` field. Relay `message` to the user.

create_ad_association

Creates one or more Amazon ad groups (called 'line items' in DSP) in a single batch call. This tool supports BULK creation — pass multiple ad groups in the dsp_ad_groups array to create them all in one request instead of calling the tool repeatedly. NOT SUPPORTED: Tactic ad groups (targetingSettings.automatedTargetingTactic). This tool only creates standard DSP line items. Do NOT set automatedTargetingTactic — all tactic types are out of scope (e.g. CUSTOMER_ACQUISITION, REMARKETING, RETENTION, MAXIMIZE_PERFORMANCE, PROSPECTING, AWARENESS, SEARCH). CHANNEL: Only 'AMAZON_DSP' is supported; set channel to 'AMAZON_DSP' and populate 'dsp_ad_groups'. PREREQUISITE — organization_id, account_id, campaign_id, and channel are required: 1. Call get_organization to discover your organization_id. 2. Call get_intentwise_accounts to discover available accounts and their account_id. 3. Deduce the channel from the user's request. 4. The campaignId must reference an existing campaign (order). Use create_campaign first if needed. 5. Call discover_advertised_product_category to get advertisedProductCategoryIds. 6. Every standard ad group requires a LIFETIME budget — ask the user for the amount before calling this tool. 7. Every standard ad group requires bid.baseBid — ask the user for the bid amount before calling this tool. IMPORTANT: Before calling this tool, present a single CONSOLIDATED plan summary covering ALL ad groups in one view. Receive explicit user approval on the full plan before proceeding. Never call this tool without prior user confirmation. RESPONSE HANDLING — On success, the tool returns JSON with a `message` field. Relay `message` to the user. Related tools that operate on the result: create_target (add targeting criteria) and create_ad_association (link ads/creatives).

create_ad_group

Creates one or more Amazon DSP campaigns (called 'orders' in DSP) in a single batch call. This tool supports BULK creation — pass multiple campaigns in the dsp_campaigns array to create them all in one request instead of calling the tool repeatedly. CHANNEL: Only 'AMAZON_DSP' is supported; set channel to 'AMAZON_DSP' and populate 'dsp_campaigns'. PREREQUISITE — organization_id, account_id, and channel are required: 1. Call get_organization to discover your organization_id. 2. Call get_intentwise_accounts to discover available accounts and their account_id. 3. Use channel 'AMAZON_DSP'. LIMITATION: After creating a campaign, only STANDARD ad groups are supported via create_ad_group. Tactic ad groups (targetingSettings.automatedTargetingTactic) are NOT supported — all tactic types are out of scope. Do not attempt ad groups with automatedTargetingTactic set. IMPORTANT: Before calling this tool, present a single CONSOLIDATED plan summary covering ALL campaigns in one view. Receive explicit user approval on the full plan before proceeding. Never call this tool without prior user confirmation. RESPONSE HANDLING — On success, the tool returns JSON with a `message` field. Relay `message` to the user. Related tools that operate on the result: create_ad_group (add standard ad groups).

create_campaign

Creates one or more Amazon targeting criteria in a single batch call. This tool supports BULK creation — pass multiple targets in the dsp_targets array to create them all in one request instead of calling the tool repeatedly. CHANNEL: Only 'AMAZON_DSP' is supported; set channel to 'AMAZON_DSP' and populate 'dsp_targets'. PREREQUISITE — organization_id, account_id, and channel are required: 1. Call get_organization to discover your organization_id. 2. Call get_intentwise_accounts to discover available accounts and their account_id. 3. Deduce the channel from the user's request. 4. Call the appropriate discovery tool for the target type (discover_static_targets, target_discovery_by_type_and_query, or target_discovery_by_audience) and use the returned values in targetDetails. 5. Each target must specify targetType and the corresponding targetDetails object. 6. Set adGroupId for ad-group level targets or campaignId for campaign-level targets. NEGATIVE TARGETING: - Include-only (no exclusions): for targetType KEYWORD, DEVICE, CONTENT_CATEGORY (contentCategoryTarget / IAB-style categories), or DOMAIN — the API only supports inclusion. Do not ask the user about negative/exclude; always set negative to false. - For all other target types: explicitly ask whether each target should be negative (excluded) or positive (included) before setting negative. AUDIENCE TARGETING (targetType AUDIENCE): - Up to 500 audience targets can be associated per ad group. - groupId is required on every audience target. Use '1'–'10' for inclusion groups; '11' for the exclusion group. - Include vs exclude is controlled by the negative field: negative=false (include), negative=true (exclude). - Audiences to include together (OR) → same groupId from '1'–'10' + negative=false. - Audiences to exclude together (AND) → groupId '11' + negative=true. - Every audience in a groupId must have the same negative value. - Use a new groupId from '1'–'10' for a separate inclusion OR-set. - Do NOT set inGroupOperator, acrossGroupOperator, intraOperator, or interOperator — boolean logic is applied automatically by Amazon: • Within an inclusion group (negative=false): audiences joined by OR/ANY. • Within the exclusion group (negative=true): audiences joined by AND/ALL. • Across groups: groups are joined by AND logic. IMPORTANT: Before calling this tool, present a single CONSOLIDATED plan summary covering ALL targets in one view. Receive explicit user approval on the full plan before proceeding. Never call this tool without prior user confirmation. RESPONSE HANDLING — On success, the tool returns JSON with a `message` field. Relay `message` to the user. Related tools that operate on the result: create_ad_association (link ads/creatives).

create_target

Returns the list of Amazon DSP advertised product categories available for an account. These are the product categories an advertiser can target based on their catalog.

discover_advertised_product_category

Returns Amazon DSP static target lists that don't require search queries. INVENTORY_SOURCE returns available deals and inventory sources; CONTENT_CATEGORY returns standard IAB content categories.

discover_static_targets

Returns the list of AMS accounts for a given organization. organization_id is required — obtain it from get_organization first. Non-SUPER_ADMIN users must pass their own organization_id. SUPER_ADMIN users may pass any valid organization_id. Supports optional heuristic filtering for account name and account type. Each account includes an available_data_sources list of { data_source_type, channel, description } entries representing the active data source integrations for that account. An empty available_data_sources list means the account has no active data source integrations.

get_intentwise_accounts