Skip to main content
Glama
Sign In

Vibeking

by com.vibekingdevelopment
OverviewDiscussionsAdmin

Propose an ad change

propose_ad_change
Idempotent

Propose pausing, resuming or changing the daily budget of a campaign. An owner or admin approves or rejects it in Vibeking, never through the MCP. When the owner switched on the autopilot and the proposal is within its limits (allowed actions and platforms, budget change per campaign per day, total daily spend increase per currency, not on do not touch), it is approved by the autopilot and carried out at once (via autopilot); otherwise it stays a normal proposal (field autopilot names the limit). The current state is stored as before; the proposal expires after 72 hours. After approval Vibeking carries it out within a minute: when status or budget changed in the meantime the change becomes stale (propose again), and the result is checked by reading the state again. Daily budget only for Meta campaign budgets and Google Ads campaigns with their own budget (shared budgets are refused). Never deletes or creates anything; at most 10 executions per organization per hour. Regie and Enterprise plans only (error code plan); the account needs the right to change ads (error code rights: use Extend rights) and, for Google Ads, a connected account.

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": {
      "site_id": "<site_id>",
      "platform": "<platform>",
      "account": "<account>",
      "campaign_id": "<campaign_id>",
      "action": "<action>",
      "reason": "<reason>"
    },
    "name": "propose_ad_change"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYespause, resume or set_daily_budget.
reasonYesWhy the agent proposes this change.
accountYesAd account id (Google Ads: customer id), as returned by get_ads.
site_idYesThe site id, as returned by list_sites.
platformYesAd platform.
campaign_idYesCampaign id, as returned by get_ads.
daily_budgetNoNew daily budget in the account currency; required for set_daily_budget.
expected_impactNoExpected effect, shown to the approver.
idempotency_keyNoOptional key; the same key returns the same proposal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

The description goes well beyond the supplied annotations, disclosing the 72-hour expiry, the 10-executions-per-hour rate limit, the stale-change behavior after approval, the re-read verification, the shared-budget refusal, and the error codes plan and rights. That is unusually rich behavioral context for a non-readOnly, non-destructive, idempotent tool. Minor gap: it doesn't say what identifier or shape the proposal response carries, so the agent can't fully predict the return.

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, which is good, but the bulk arrives as one long parenthesis-heavy sentence covering autopilot limits, plus a run-on about post-approval behavior. Every fact is relevant, yet the lack of breaks or bullets makes the limits section harder to scan than it needs to be.

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 nine-parameter mutation tool with no output schema, the description covers the decision path, failure modes, plan and rights requirements, and rate limiting thoroughly. The remaining gap is the return contract: with no output schema present, the agent would benefit from knowing what a proposal object contains (id, status, autopilot field) rather than only that autopilot "names the limit."

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 coverage is 100%, so the schema already documents every parameter and the baseline is 3. The description adds real meaning on top, notably that daily_budget applies only to Meta campaign budgets and Google Ads campaigns with their own budget (shared budgets refused), and that action transitions through the owner/autopilot path. It doesn't elaborate on idempotency_key or expected_impact beyond the schema's own wording.

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?

The description opens with a specific verb and resource: "Propose pausing, resuming or changing the daily budget of a campaign." It also scopes the action set (pause/resume/set_daily_budget) and the platforms, so an agent can distinguish this from sibling proposal tools like propose_post or propose_undo without reading the schema.

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?

It clearly describes the approval workflow (owner/admin approves in Vibeking, or autopilot auto-approves within configured limits) and the conditions for use: Regie/Enterprise plans, ad-change rights, connected Google Ads account. What it lacks is an explicit pointer to when to choose this over sibling tools such as propose_undo or add_keywords, leaving the agent to infer that from the resource named.

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

All Vibeking toolsInspect
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