Skip to main content
Glama

Honeyfield Marketing MCP

Meta Ads: Update adset

meta_update_adset
Destructive

Meta-Adset ändern: Name, Status, Tages- oder Laufzeitbudget (EUR), Bid-Strategie/-Betrag (EUR), DSA-Angaben (dsa_beneficiary/dsa_payor, EU-Pflicht), advantage_audience (KI-Zielgruppenerweiterung an/aus), Platzierungen, promoted_object/destination_type und/oder Targeting (Länder, Geo-Verfeinerung, Ausschlüsse, Audiences, Interessen, Sprachen). status: ACTIVE = starten, PAUSED = pausieren (zum Stoppen PAUSED nehmen — umkehrbar), ARCHIVED = gestoppt und nur noch lesbar (Berichte bleiben), DELETED = endgültig gelöscht, NICHT umkehrbar. promoted_page_id bzw. pixel_id + custom_event_type: promoted_object des Adsets (Page für Lead-Adsets; Pixel + Ereignis wie LEAD/PURCHASE für Conversion-Adsets). Es wird nur gesendet, was übergeben wurde; pixel_id und custom_event_type immer zusammen (error=pixel_event_required), unbekannte Ereignisse error=invalid_custom_event_type. Ob Meta das promoted_object eines bestehenden Adsets ändern lässt, hängt vom Optimierungsziel ab — lehnt Meta ab, kommt der Fehler durch. destination_type: laut Meta-Enum (WEBSITE, ON_AD, MESSENGER, WHATSAPP, INSTAGRAM_DIRECT, ...); error=invalid_destination_type sonst. Zurücklesen via meta_list_adsets. daily_budget / lifetime_budget: nie beides (error=budget_conflict). lifetime_budget braucht ein end_time — mitgegeben oder schon am Adset gesetzt, sonst error=end_time_required. Ein Wechsel Tages-↔Laufzeit- budget ist bei Meta eingeschränkt; lehnt Meta ab, kommt der Fehler durch. bid_strategy: LOWEST_COST_WITHOUT_CAP, LOWEST_COST_WITH_BID_CAP, COST_CAP, LOWEST_COST_WITH_MIN_ROAS (BID_CAP/COST_CAP brauchen bid_amount, MIN_ROAS braucht min_roas: error=min_roas_required — und kennt KEIN bid_amount: error=bid_amount_not_applicable). min_roas: Mindest-ROAS als Verhältnis (2.5 = 250 %, erlaubt 0.01–1000), geht als bid_constraints.roas_average_floor (×10000) raus. Umstellen auf Mindest-ROAS: zusammen mit bid_strategy=LOWEST_COST_WITH_MIN_ROAS. min_roas OHNE bid_strategy liest die bestehende Strategie (Adset; bei CBO die der Kampagne) und sendet nur den neuen Floor, wenn sie schon LOWEST_COST_WITH_MIN_ROAS ist (bei CBO ohne bid_strategy — die liegt an der Kampagne); jede andere Strategie: error=min_roas_not_applicable, nichts geändert (kein stilles Umschalten). Die Antwort nennt den gesendeten Wert in min_roas; Zurücklesen via meta_list_adsets. bid_amount OHNE bid_strategy liest die bestehende Strategie des Adsets und behält sie bei (COST_CAP bleibt COST_CAP); nur ein Adset mit LOWEST_COST_WITHOUT_CAP wechselt auf LOWEST_COST_WITH_BID_CAP, weil ein Betrag dort sonst nicht wirkt. Nutzt das Adset (oder bei CBO die Kampagne) LOWEST_COST_WITH_MIN_ROAS, gibt es kein bid_amount: error=bid_amount_not_applicable. Die Antwort nennt in bid_strategy, was gesendet wurde. Ist die bestehende Strategie nicht lesbar, bricht das Tool ab, ohne etwas zu ändern. Targeting wird gemerged — nur übergebene Teile werden ersetzt; Listen (countries, cities, regions, zips, custom_locations, interest_ids, behavior_ids, locales, excluded_custom_audience_ids) ersetzen ihren Bestand komplett, eine LEERE Liste entfernt ihn (cities=[] löscht alle Städte, interest_ids=[] alle Interessen; excluded_geo_locations={'zips': []} löscht den PLZ-Ausschluss; countries=[] entfernt countries UND country_groups aus geo_locations). geo_locations/excluded_geo_locations werden schlüsselweise gemergt. custom_audience_ids=[] und genders=[] sind dagegen keine Angabe (unverändert). Geo-Verfeinerung — Schlüssel via meta_targeting_search: cities=[{'key': '2420605', 'radius_km': 17}] (17–80 km, error=invalid_city_radius), regions=['1234'], zips=['AT:5020'] (Landespräfix Pflicht, error=invalid_zip_key), custom_locations=[{'latitude': 47.8, 'longitude': 13.04, 'radius_km': 10}] oder [{'address_string': '...', 'radius_km': 5}] (1–80 km, error=invalid_custom_location). Städte und Umkreise aus meta_list_adsets ({'key', 'radius', 'distance_unit': 'kilometer', ...}) dürfen 1:1 zurückgegeben werden; Meilen (distance_unit='mile') und unbekannte Felder werden abgelehnt (error=invalid_city_radius/invalid_cities), nie still umgedeutet. Konfliktregel von Meta (Subcode 1487756): Orte, die ineinander liegen, dürfen nicht gemeinsam EINGESCHLOSSEN werden (Land + Stadt darin, Region + Stadt darin, Stadt-Umkreis + PLZ darin) — Meta lehnt den Aufruf ab, der Fehler kommt mit hint. Deshalb: Verfeinerung OHNE countries ENTFERNT bestehende countries UND country_groups (z.B. 'europe' aus dem Ads Manager) aus dem Targeting und meldet das in warnings; soll ein Land zusätzlich gelten (nur sinnvoll für Orte in ANDEREN Ländern, z.B. DE + Salzburg/AT), countries mitgeben — dann bleibt es stehen, ohne Warnung. countries ersetzt eine bestehende country_groups (mit Warnung) — Ländergruppen lassen sich über dieses Tool nicht setzen. Ausschlüsse INNERHALB eines Gebiets sind erlaubt (excluded_geo_locations, z.B. countries=['AT'] minus Stadt Salzburg). Bleibt nach dem Merge kein Geo-Eintrag übrig (auch nach countries=[]): error=geo_required, nichts geändert. excluded_geo_locations: Dict wie {'zips': ['AT:5020']}, {'cities': [...]}, {'regions': [...]}, {'countries': ['CH']}, {'custom_locations': [...]} (error=invalid_excluded_geo_locations bei anderen Schlüsseln). excluded_custom_audience_ids: Custom Audiences ausschließen (IDs aus meta_list_audiences). interest_ids / behavior_ids: IDs aus meta_targeting_search (kind='interest'/'behavior'). locales: Meta-Locale-Schlüssel (Ganzzahlen, kind='locale'; error=invalid_locales). Zurücklesen: meta_list_adsets zeigt den gemergten Stand im targeting. publisher_platforms schränkt die Plattformen ein: ['facebook','instagram'] schaltet z.B. Audience Network ab. Positionen abgewählter Plattformen werden dabei mit entfernt. positions: je Plattform, z.B. {'instagram': ['stream','reels']}. device_platforms: ['mobile'] und/oder ['desktop']. start_time / end_time: Zeitplan; end_time ist das Traffic-Enddatum. Je als Datum '2026-09-30' (= Tagesende) oder ISO-Zeitstempel; ohne Offset wird die Zeitzone des Werbekontos angehängt (Meta würde sonst UTC annehmen). Zurücklesen via meta_list_adsets — Meta braucht nach dem Schreiben ein paar Sekunden, bis der neue Stand sichtbar ist. Bei EU-/EWR-Targeting ohne dsa_beneficiary warnt das nicht-blockierende warnings-Feld. Bei status=ACTIVE wird der DSA-Stand best-effort geprüft; dsa_check: "unavailable" markiert einen fehlgeschlagenen Advisory-Check. Erfasst werden alle Geo-Einträge mit Ländercode sowie country_groups (europe/eea/worldwide/eurozone/european_union); nicht auswertbare Geo-Listeneinträge erscheinen als UNKNOWN. validate_only: True lässt Meta den Aufruf prüfen, ohne etwas zu ändern. Ein Erfolg heißt: Meta würde die Änderung annehmen. IDs muessen zum Werbekonto des Workspace gehoeren — IDs eines anderen Kontos (auch wenn die Meta-Verbindung es sieht) → {'error': 'foreign_object'}. workspace: Slug des Kunden-Workspace (optional bei nur einem Workspace).

Input Schema

NameRequiredDescriptionDefault
nameNo
zipsNo
citiesNo
statusNo
age_maxNo
age_minNo
gendersNo
localesNo
regionsNo
adset_idYes
end_timeNo
min_roasNo
pixel_idNo
countriesNo
dsa_payorNo
positionsNo
workspaceNo
bid_amountNo
start_timeNo
behavior_idsNo
bid_strategyNo
daily_budgetNo
interest_idsNo
validate_onlyNo
dsa_beneficiaryNo
lifetime_budgetNo
custom_locationsNo
destination_typeNo
device_platformsNo
promoted_page_idNo
custom_event_typeNo
advantage_audienceNo
custom_audience_idsNo
publisher_platformsNo
excluded_geo_locationsNo
excluded_publisher_list_idsNo
excluded_custom_audience_idsNo
excluded_publisher_categoriesNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the destructiveHint=true annotation: DELETED is called out as final and non-reversible, targeting is described as a merge where an empty list deletes existing entries, geo refinements without countries silently strip country_groups (reported in `warnings`), and a long catalogue of error codes (budget_conflict, end_time_required, min_roas_not_applicable, geo_required, foreign_object) is disclosed. Side effects, validation via validate_only, and eventual-consistency lag on read-back are all stated.

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

Conciseness3/5

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

Front-loaded well — the field inventory and status semantics come first — but the body is a ~1,300-word wall of undifferentiated prose, and passages such as the min_roas / bid_amount interaction are convoluted enough that an agent must re-read them. Substantively almost every sentence carries information, yet the density and lack of scannable grouping (no headings or bullets) costs it.

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?

For a destructive, high-blast-radius mutation tool with 38 parameters, no schema documentation and a declared output schema, the description supplies everything an agent needs to act safely: merge behavior, irreversibility, error-driven preconditions, and which response fields (`warnings`, `dsa_check`, `min_roas`, `bid_strategy`) to inspect afterwards.

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?

With 0% schema description coverage across 38 parameters, the description carries the entire burden and largely succeeds: budget mutual exclusion, bid_strategy enum values with their required companions, min_roas scaling (×10000) and range 0.01–1000, geo key formats with radius bounds and required country prefixes, and list-replacement vs key-wise-merge semantics are all spelled out. Only age_min/age_max and excluded_publisher_list_ids/excluded_publisher_categories are left undocumented, a small gap against the rest.

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?

Opens with a specific verb+resource ('Meta-Adset ändern') and immediately enumerates the mutatable surface: name, status, budgets in EUR, bid strategy/amount, DSA fields, advantage_audience, placements, promoted_object/destination_type and targeting. An agent can distinguish this from meta_update_campaign, meta_create_adset and meta_update_ad_status from the first paragraph alone.

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?

Gives explicit decision rules for the ambiguous cases (status: ACTIVE=start, PAUSED=pause/reversible stop, ARCHIVED=read-only, DELETED=irreversible) and routes read-back to meta_list_adsets and targeting lookups to meta_targeting_search. What is missing is any explicit statement of when to prefer a sibling such as meta_update_campaign or when a change should instead be done at campaign level (CBO).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources