Launch the SAME campaign set across MULTIPLE ad accounts in one call (up to 5 accounts; chain calls for more). Each account gets its own currency-aware guardrails, capacity check (throttled accounts are skipped, not hammered), and correct Page/Instagram/pixel. WRITES live.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| campaigns | Yes | ||
| account_ids | Yes | Up to 5 Meta ad account IDs. |
Changes observed during successful MCP inspections.
Input schema / properties / campaigns / items / properties / geoLocationsAdded value: +{
+ "additionalProperties": true,
+ "description": "OPTIONAL specific places instead of whole countries (replaces countries when set). Get keys from search_locations. cities: [{ key, radius (km, 17-80; omit for the city only), country_code }], regions: [{ key, country_code }] (states), zips: [{ key e.g. \"IN:380015\", country_code }] (PIN/ZIP codes). Meta rejects overlapping places (e.g. a PIN inside a city radius). With a Special Ad Category: no zips, and cities need a radius of at least 25 km.",
+ "properties": {
+ "cities": {
+ "items": {
+ "properties": {
+ "country_code": {
+ "type": "string"
+ },
+ "key": {
+ "type": "string"
+ },
+ "radius": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "key"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "regions": {
+ "items": {
+ "properties": {
+ "country_code": {
+ "type": "string"
+ },
+ "key": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "key"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "zips": {
+ "items": {
+ "properties": {
+ "country_code": {
+ "type": "string"
+ },
+ "key": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "key"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false; the description adds real substance beyond that — per-account currency-aware guardrails, a capacity check, throttled accounts being skipped rather than hammered, and the explicit "WRITES live" warning. It still omits the confirm parameter's behavior, permission requirements, and what happens on partial failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with the action and scope front-loaded, followed by the key behavioral guarantees. Every clause (multi-account, cap, chaining, currency, capacity, pixel, live write) earns its place; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a live-writing bulk mutation with no output schema and only 33% parameter coverage, the description covers much of the operational complexity (multi-account batching, currency, throttling) but is silent on return values, partial-success/failure semantics, and the confirm parameter. Adequate but with visible gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33%, so the description carries more burden. It clarifies that account_ids accepts only up to 5 and that the same campaign set is replicated to each account, but the required "confirm" parameter and the per-account vs shared budget implications are left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb ("Launch"), resource ("campaign set"), and a distinguishing scope ("across MULTIPLE ad accounts in one call"). The multi-account framing separates it from single-account siblings like create_campaign and bulk_create_campaigns without the agent needing to open any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operating context: use it to fan the SAME campaign set across accounts, capped at 5 with the instruction to "chain calls for more." It does not name an alternative (e.g., single-account create) or state when not to use it, so it stops short of explicit when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.