Fama

Switch on

switch_on

Destructive

Switches ON a paused campaign, ad set or ad, so it can spend. Use it only when the person asks for it or clearly agrees. The account's daily cap is a hard limit: a switch-on that would take live daily budgets over it is refused. Something switched on under a paused campaign or ad set will not spend until that is on too; the result says so. Inside the limits the person set, it happens at once and the result says what Meta now reports. Over a soft limit it waits for the person to confirm; past a hard limit (the account's daily cap, read-only mode) it is refused. Read result before saying what happened.

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": {
      "entity_id": "<entity_id>",
      "reason": "<reason>"
    },
    "name": "switch_on"
  }
}

Input Schema

Name	Required	Description	Default
`reason`	Yes	Why, with the numbers that justify it. Recorded in the activity log.
`entity_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The annotations already mark this as destructive, non-idempotent and open-world, but the description adds substantive behavior beyond them: the account daily cap is a hard ceiling that causes refusal, soft limits trigger a confirmation pause, and an entity enabled under a still-paused parent will not spend. It also directs the agent to read `result` before reporting outcomes, which is the key behavioral caveat for a mutation tool.

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?

The definition is front-loaded with purpose and consent, and the limit hierarchy is ordered logically. It is slightly repetitive around result reporting ('the result says so', 'the result says what Meta now reports', 'Read `result` before saying what happened'), which could be consolidated without losing meaning.

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 a destructive mutation with no output schema, the description covers the important unknowns: spend implications, cap enforcement, confirmation flow, parent-status dependency, and the presence of a `result` field. What remains thin is identifier semantics for `entity_id` and the shape of a refusal response.

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

Parameters3/5

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

Schema coverage is only 50%: `reason` is documented in the schema but `entity_id` has no description at all. The description hints that entity_id may be a campaign, ad set or ad, which adds some meaning, but it never says how the type is resolved or what identifier format is expected, so it only partially compensates for the gap.

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 the exact resource set ('Switches ON a paused campaign, ad set or ad, so it can spend'), which immediately distinguishes it from the sibling 'pause'. The purpose is unambiguous and the effect (enabling spend) is stated in the same sentence.

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?

Gives an explicit consent gate ('only when the person asks for it or clearly agrees'), plus the operational conditions that select different outcomes: within limits it acts at once, over a soft limit it waits for confirmation, past a hard limit it is refused. This is when-to-use and when-not-to-use guidance rather than inference.

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

All Fama 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?