Skip to main content
Glama

Metadata MCP Connector

Update Target Group

update_target_group
Destructive

Update existing target group with new name and/or targeting criteria. Supports BOTH include AND exclude rules — including adding/removing exclude audiences.

CRITICAL - PUT REQUEST: You MUST provide ALL fields, not just changed ones.

  • 'name' is ALWAYS REQUIRED even if not changing

  • If updating targeting, provide complete targeting object (full include + exclude)

  • Always retrieve current config first via retrieve_target_group_by_id and merge changes onto it

PREREQUISITE WORKFLOW:

  1. list_target_groups(name="X") → get ID

  2. retrieve_target_group_by_id(target_group_id=ID) → get current config, check isModifiable fields, copy existing exclude audiences

  3. search_target_group_criteria → get new criteria IDs

  4. estimate_target_group → MANDATORY: verify isMatchCountTooSmall=false

  5. update_target_group with ID and ALL required fields (full targeting object)

MODIFIABILITY: Name always modifiable. LOCATION usually isModifiable=false. Check retrieve_target_group_by_id response for other fields.

TARGETING STRUCTURE: Same as create_target_group — full include array + single exclude object containing both criteria and audiences. See create_target_group description for the full example payload (with NATIVE_LOCATION, AGE, COMPANY_NAME exclude criteria, and FIRMOGRAPHIC_EXCLUDE audience). Only update criteria with isModifiable=true.

WARNING: AUDIENCES ≠ TARGET GROUPS. Both include[].audiences and exclude.audiences accept Custom Audience records ONLY (the entities returned by get_matched_audiences). Target Groups (the entities returned by list_target_groups / retrieve_target_group_by_id) are a separate entity in a separate ID space and CANNOT be attached here; the platform silently drops or rejects them. If the user names "X" and only list_target_groups matches it (not get_matched_audiences), do NOT pass the Target Group's id as mdAudienceId. Stop, tell the user "X is a Target Group, not a Custom Audience", and offer to rebuild X as a Custom Audience (e.g. via create_audiences with the same criteria) before retrying.

ADDING/REMOVING EXCLUDE AUDIENCES: Provide the COMPLETE desired exclude.audiences array. Each entry needs: mdAudienceId (integer, REQUIRED — the numeric Custom Audience id like 49067 from get_matched_audiences, its customAudienceId / mdAudienceId field, NEVER that row's id, NEVER the audience name string, NEVER a placeholder like 1/2/3/4 (rejected pre-flight), and NEVER a Target Group id from list_target_groups; see the AUDIENCES ≠ TARGET GROUPS note above), name, type (EXCLUDE variant like FIRMOGRAPHIC_EXCLUDE/RETARGETING_EXCLUDE/CONTACT_LIST_EXCLUDE), matchCount, matchCountType, inactive, and the audience's own criteria array. To remove an exclusion, omit it from the array. To add one, append it.

RESPONSE: {id, name, channel, audienceSize, status, modifiedDate, targeting}

VALIDATION: Must estimate first and verify isMatchCountTooSmall=false before updating.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesREQUIRED: Target group name. CRITICAL - This is a PUT request so you MUST provide the name even if not changing it. Use retrieve_target_group_by_id to get the current name if you don't have it.
targetingNoUpdated targeting configuration (optional). Structure must match create_target_group format. Only update criteria that have isModifiable=true in the current configuration. All criteria IDs/references must come from search_target_group_criteria tool. REQUIRED: Must estimate this targeting first and verify isMatchCountTooSmall is false. NOTE: This is a PUT request - if the target group has targeting, you should provide the complete targeting object.
target_group_idYesThe unique ID of the target group to update. Must be a positive integer. Use list_target_groups to find the ID by name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations only indicate readOnlyHint=false and destructiveHint=true, but the description adds critical behavioral context: PUT request semantics requiring all fields, modifiability checks via isModifiable, the need to merge with current config, and the requirement to estimate and verify isMatchCountTooSmall. It also explains the response format. No contradiction with annotations.

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 long but highly structured with clear sections (CRITICAL, PREREQUISITE WORKFLOW, MODIFIABILITY, TARGETING STRUCTURE, WARNING, ADDING/REMOVING EXCLUDE AUDIENCES, RESPONSE, VALIDATION). Critical information is front-loaded, and each paragraph serves a distinct purpose. No redundancy or filler.

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—PUT semantics, nested targeting, audience type distinctions—the description covers all necessary context: prerequisites, workflow, modifiability, full example reference, response format, and validation steps. With no output schema, the response description fills that gap. Nothing an agent needs to call it correctly is missing.

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?

While the schema covers all three parameters with descriptions, the tool description significantly enriches them: explains that 'name' is always required even if unchanged, details the targeting structure (include array + exclude object), specifies the exact fields needed for exclude audiences (mdAudienceId, name, type, matchCount, etc.), and warns about invalid values. This goes well beyond the schema's generic descriptions.

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 states a specific verb and resource: 'Update existing target group with new name and/or targeting criteria.' It also clarifies scope by supporting include and exclude rules, and distinguishes itself from create_target_group and retrieve_target_group_by_id by name. The purpose is unmistakable and differentiates from siblings.

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?

Provides an explicit prerequisite workflow with numbered steps, including listing, retrieving, searching criteria, and mandatory estimation before updating. It also warns when not to pass target group IDs as audiences and instructs to stop and inform the user if the entity is a Target Group, not a Custom Audience. Clear when-to-use and when-not-to-use guidance.

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