StealAds

Create a Playbook

create_playbook

Builds a Playbook for one competitor: a written summary of its stored ads with ideas to try against them. When credits would be charged it takes two steps: without confirm it returns a cost preview (idempotency_key, max_credits) and changes nothing; the same call with confirm: true and those two values starts the analysis and returns a playbook_id. With nothing to charge, the first call starts the analysis, or returns the current Playbook instead of rebuilding it. The analysis runs in the background and get_playbook shows the result. Does not start tracking.

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": {
      "competitor_id": "<competitor_id>"
    },
    "name": "create_playbook"
  }
}

Input Schema

Name	Required	Description
`confirm`	No	true starts the paid work shown in the cost preview. Absent or false returns that preview and spends nothing when credits would be charged; an action that costs no credits runs on this call.
`max_credits`	No	max_credits from the cost preview, sent unchanged with confirm: true as the approved credit ceiling. A higher current price needs a new preview.
`competitor_id`	Yes	Competitor id from list_competitors.
`idempotency_key`	No	idempotency_key from the cost preview, needed with confirm: true and valid for 15 minutes. A repeat with the same key returns the first result without a second charge.

Output Schema

Name	Required	Description
`status`	No	Current progress or delivery state.
`billing_url`	No	billing url value in this response.
`max_credits`	No	Explicit credit ceiling to echo after the user approves this quote.
`playbook_id`	No	playbook id value in this response.
`cost_credits`	No	Credits quoted or charged by this operation.
`what_happens`	No	Plain explanation of the proposed work, confirmation steps and quote expiry.
`enough_credits`	No	enough credits value in this response.
`balance_credits`	No	balance credits value in this response.
`idempotency_key`	No	Key binding confirmation to this preview and preventing duplicate work.
`confirmation_required`	No	True for a cost preview awaiting explicit approval.
`tracking_enabled_by_this_call`	No	tracking enabled by this call value in this response.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 10, 2026

changedInput schema / properties / confirm / description

Previous value: -"Set to true to spend the credits shown in the preview. Leave it out to see the cost first."New value: +"true starts the paid work shown in the cost preview. Absent or false returns that preview and spends nothing when credits would be charged; an action that costs no credits runs on this call."

changedInput schema / properties / idempotency_key / description

Previous value: -"The idempotency_key from the preview. Required with confirm: true. Repeating a confirmed call with the same key returns the first result and does not spend again."New value: +"idempotency_key from the cost preview, needed with confirm: true and valid for 15 minutes. A repeat with the same key returns the first result without a second charge."

changedInput schema / properties / max_credits / description

Previous value: -"The explicit credit ceiling you approve. For paid confirmation, echo max_credits from the preview unchanged. A higher current price requires a new preview and approval."New value: +"max_credits from the cost preview, sent unchanged with confirm: true as the approved credit ceiling. A higher current price needs a new preview."

First observedNov 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint false, destructiveHint false, openWorldHint true), it discloses the cost-preview/confirm gate, that a preview call changes nothing, the 15-minute idempotency window and no-double-charge behavior, and that analysis runs in the background. That is exactly the behavioral context an agent needs for a metered, asynchronous mutation.

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?

It is front-loaded with purpose before the multi-branch mechanics, and every sentence carries information. Some sentences are long clause chains, but nothing is redundant enough to cut.

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

Completeness5/5

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

For a metered, multi-step, async tool with an output schema, it covers trigger conditions, the two-step sequence, what the preview returns, what the confirmed call returns (playbook_id), and which sibling shows the finished artifact. Nothing an agent needs to call it correctly is missing.

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 already 100%, so the schema carries the parameter documentation. The description still adds flow-level meaning the schema cannot: that idempotency_key and max_credits come from the preview and must be passed unchanged with confirm: true, which explains how the four parameters interlock.

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 first sentence names a specific verb and resource plus scope: 'Builds a Playbook for one competitor: a written summary of its stored ads with ideas to try against them.' It also implicitly distinguishes itself from get_playbook (read the result) and list_playbooks, and closes with the boundary 'Does not start tracking.'

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?

It spells out two distinct call paths: when credits would be charged, call once for a preview then again with confirm: true; when nothing is charged, the first call runs the work. It also states the alternative outcome (return the existing Playbook instead of rebuilding) and names get_playbook as the way to see results.

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

All StealAds 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.