Skip to main content
Glama
kadam-official

@kadam-net/mcp-server

Official
by kadam-official
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Remote

kadam_adv_create_audience

Create a Kadam ad audience for pixel, stat, or S2S types by defining name, expiry, campaign IDs, and tracking rules. Use dryRun to validate the payload before creating.

Instructions

Create an audience. Required fields by type: • audience_code (pixel) — name, expireDays; optional createFingerprint. • audience (stat) — name, expireDays, campaignIds, plus >=1 of hasClicks/hasConversions/hasHolds/hasRejects. • s2s — name, expireDays, linkedAudienceIds (pixel/fingerprint IDs). • fingerprint — not created directly; set createFingerprint=true on a pixel/stat audience. Set dryRun=true to check the payload without creating anything — useful while assembling a campaign and its audience together.

Input Schema

NameRequiredDescriptionDefault
nameYes
typeYes
dryRunNoCheck the payload and create nothing
hasHoldsNoTrack holds (type=audience)
hasClicksNoTrack clicks (type=audience)
expireDaysYes
hasRejectsNoTrack rejects (type=audience)
campaignIdsNoComma-separated campaign IDs (required for type=audience)
hasConversionsNoTrack conversions (type=audience)
createFingerprintNoAlso create a linked fingerprint audience (type=audience_code or audience)
linkedAudienceIdsNoComma-separated pixel/fingerprint audience IDs (required for type=s2s)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.1
    • addedInput schema / properties / dryRun
      Added value: +{
+  "default": false,
+  "description": "Check the payload and create nothing",
+  "type": "boolean"
+}
  2. First observedv0.3.9

TDQS

A4.2/5.0
Behavior3/5

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

Annotations only declare readOnlyHint=false, so the description must carry behavioral weight. It usefully discloses that type=fingerprint is never created directly and must be produced as a side effect via createFingerprint=true, and re-explains dryRun's no-op semantics. However it says nothing about permissions, error behavior on partial payloads, or whether a created fingerprint is atomically linked.

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?

Front-loads the core action, then uses a tight type-by-type bullet list rather than prose, with no redundant sentences. The closing dryRun sentence earns its place by giving the practical trigger for using it.

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

Completeness4/5

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

For an 11-parameter mutation tool with no output schema, the description covers payload composition thoroughly. The remaining gap is the result side: it never indicates what is returned on success (e.g., the new audience ID) or how to verify creation, which an agent orchestrating a campaign create would want.

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

Parameters4/5

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

Schema description coverage is 73%, so the schema already documents most individual flags, but the description adds genuine cross-field semantics absent from the schema: the '>=1 of hasClicks/hasConversions/hasHolds/hasRejects' constraint for type=audience, the required sets per type, and that linkedAudienceIds takes pixel/fingerprint IDs. This meaningfully exceeds the baseline.

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?

States a specific verb and resource ('Create an audience') and then enumerates the exact required field sets for each of the three creatable types, which no other sibling does. An agent can distinguish this from kadam_adv_update_audience, kadam_adv_delete_audience, and kadam_adv_list_audiences from the description 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 clear per-type selection logic (which fields apply when) and recommends dryRun=true while assembling a campaign and its audience together. It stops short of naming the sibling tools to use for modification or deletion, so it lacks explicit alternatives/exclusions, but the conditional guidance is strong.

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