GenFlick

Save an authored campaign plan

native.genads_save_campaign

DestructiveIdempotent

Save an authored campaign plan. Meta catalog_sales uses catalogCampaign with a saved catalog operation, catalog and product-set IDs, measurementOperationId, pixelId and conversionEvent, explicit dynamic-content scope, and an empty releaseIds list. It requires report permission and a separate human live-content confirmation; fixed offers and carousels cannot be combined with it. For carousels, releaseIds is the exact ordered list of approved image releases; carousel.cards maps each release ID to its headline, description, destination and callToAction. Explicit carousel.optimizeOrder=false preserves 2–5 cards; true permits Meta to reorder 2–10. Carousel launch has independent account qualification. Optional storeOffer binds an exact connected store, completed individual-product operation, product and 1–10 variant IDs, with validUntil covering the campaign. Read current store evidence first; current store access is separate from advertiser access, including the selected MCP store and commerce:read scope. These facts are reviewed and checked again before a paid change. This never stages, approves, activates or changes platform ads.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "work_id": "<work_id>",
      "arguments": "<arguments>",
      "expected_catalog_version": "<expected_catalog_version>",
      "read_skills": "<read_skills>",
      "request_key": "<request_key>"
    },
    "name": "native.genads_save_campaign"
  }
}

Input Schema

Name	Required	Description
`work_id`	Yes
`arguments`	Yes
`read_skills`	Yes	Exact required native skills and their dependencies, copied from the accepted session bootstrap's skills array. Include only entries in that array. General mcp.* guides and native.{studio}.instructions are guidance, not native skill proofs.
`request_key`	Yes
`publication_proposal_id`	No	For native Social scheduling, the exact server-approved publication proposal. This identifier cannot confer approval by itself.
`expected_catalog_version`	Yes	For a new session, read a studios/{studio}/native/{pack} child toolset and copy invocation.catalog_version from a native tool descriptor. Do not use the top-level library version. For calls in an existing session, use that session proposal's catalog_version.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already flag the write/destructive/open-world/idempotent profile, and the description still adds real substance: authorization requirements (report permission), a human live-content confirmation gate, the statement that facts are 'reviewed and checked again before a paid change', and the explicit non-effects on platform ads. It stops short of describing version-conflict behavior despite expected_revision and request_key being present.

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?

The purpose is front-loaded, but the remainder is a dense run-on paragraph chaining conditional clauses about catalog campaigns, carousels, and store offers without bullets or sentence-level separation. Nearly every clause carries information, yet the packaging makes it hard to scan for the one rule that applies to a given call.

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

Completeness3/5

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

An output schema exists, so return values need no explanation, and the description covers the risky conditional branches of a deeply nested body. Gaps remain for a tool with this much nesting: nothing says whether the call creates or updates a plan, how expected_revision/expected_catalog_version conflicts surface, or what happens when the live-content confirmation is absent.

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 only 50%, so the description carries a real load and does: it explains that releaseIds is the exact ordered list of approved image releases, that carousel.cards maps release ID to headline/description/destination/callToAction, the 2–5 vs 2–10 card behavior of optimizeOrder, the fields of storeOffer, and the full catalogCampaign requirement set for catalog_sales. The outer wrapper parameters (work_id, arguments.operation_id, expected_revision, request_key) remain unexplained in both places.

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?

Stated as a specific verb+resource: 'Save an authored campaign plan', and the closing sentence bounds the scope ('never stages, approves, activates or changes platform ads'), which separates it from campaign_review/activation paths. It does not, however, differentiate itself from the many adjacent save_* siblings (genads_save_brief, save_concept, save_variant), so an agent must infer the boundary from the noun 'campaign plan'.

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

Usage Guidelines3/5

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

The description gives rich in-tool preconditions (report permission, separate human live-content confirmation, 'read current store evidence first', commerce:read scope) and mutual-exclusion rules (fixed offers and carousels cannot be combined). What it never does is route the agent between this tool and its alternatives – nothing says when to call genads_campaign_plans or genads_campaign_review instead, so the when-to-use choice is only implied.

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

All GenFlick tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?