Skip to main content
Glama

Datamanager.Audience.Remove Members

datamanager.audience.remove_members

Remove Customer Match audience members by hashed identifier with a guarded operation to avoid unintended changes.

Instructions

Remove Customer Match audience members by hashed identifier (guarded).

Input Schema

NameRequiredDescriptionDefault
confirmNo
membersYes
audience_idYes
destination_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden and largely fails. It is a destructive mutation, yet it never says whether removals are reversible, what 'guarded' requires (presumably the confirm param), whether the call is asynchronous given the sibling request_status tool, or what happens if confirmation is omitted.

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?

A single tight sentence with the resource and operation front-loaded and zero filler. Brevity here is efficient rather than padded, though it doubles as under-specification.

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

Completeness2/5

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

For a destructive, 4-parameter mutation with no annotations, the description leaves critical gaps: confirmation semantics, identifier format expectations, and side effects. The presence of an output schema excuses it from explaining return values, but little else is covered.

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

Parameters2/5

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

Schema coverage is 0% across four parameters. 'Hashed identifier' adds some meaning to the members array, but destination_id, audience_id, and especially the optional confirm parameter are entirely unexplained in both schema and description.

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

Purpose4/5

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

States a specific verb and resource: removes Customer Match audience members identified by hashed identifier. This is clearly distinguishable from sibling datamanager.audience.upload_members, though the sibling is never named explicitly.

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

Usage Guidelines2/5

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

No guidance on when to use this versus upload_members or why one would remove members. The lone parenthetical '(guarded)' gestures at a precondition but never states it, and there is no mention of the confirm parameter or any prerequisite.

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

Deploy Server

Other Tools