Taseli

Propose a new campaign

propose_campaign

Creates a proposal in Taseli for a new campaign on a topic, planned with AI from the business brief and memory. Google Ads: Search, Performance Max, Demand Gen or an App campaign for installs (type; left out, Taseli picks by the business and its stage; a Search campaign for a business paid by phone calls starts with its phone number as a call asset). Meta can also run call ads (route call) or store-visit ads (route store). The owner's explicit choices (type, daily budget, route, match, bidding) are honored even against Taseli's advice: the advice comes back once in the answer; only what the platform itself can't run is refused. Meta: a whole Facebook + Instagram campaign from scratch (WhatsApp, an instant form or the website; 2-3 ads from the business's best pictures; a broad audience in its area), also for an empty account. TikTok: a whole TikTok campaign from scratch (purchases or leads counted by the pixel, an instant form, or visits; 1-3 vertical videos, or the owner's own post as a Spark ad with spark_code), also for an empty account. The owner approves it in Taseli; it is built switched off and spends nothing until turned on. Nothing changes in the ad account here. Not on read-only accounts. Creatives for Meta and TikTok campaigns come from the library, by id. The same request_id (or the same topic while the first proposal is still open) returns the same proposal.

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": {
      "topic": "<topic>"
    },
    "name": "propose_campaign"
  }
}

Input Schema

Name	Required	Description
`type`	No	Google Ads only: the campaign type, when the owner chose one. app: an App campaign for installs of the business's app (needs app_url or a saved store link, and installs counted through Firebase or the app's measurement partner; the answer says what is missing).
`match`	No	Google Search only: the keyword match type, when the owner chose one.
`route`	No	Meta and TikTok: where people go, when the owner chose (TikTok: form, site_leads, site_sales or traffic). Meta call: a call button that dials the business (needs its phone number); Meta store: people to the nearest branch (needs the business's locations in Meta). Both need the goal model on.
`topic`	Yes	What the campaign is about, e.g. 'bathroom remodels'.
`ad_set`	No	Meta only: a running ad set (exact name or id) to add 1-3 new ads into instead of building a new campaign.
`account`	No	The Google Ads, Meta or TikTok account's name (or id); needed when the business has more than one.
`app_url`	No	Google App campaign only: the app's store page (Google Play or App Store link).
`bidding`	No	Google Search only: the bidding, when the owner chose one.
`page_id`	No	Meta only: the Facebook Page the ads speak as (id or exact name), when the answer listed several and the owner chose.
`language`	No	Answer language. The business's language by default.
`request_id`	No	Optional idempotency key, up to 64 characters: a retry with the same key never makes a second proposal.
`spark_code`	No	TikTok only: a Spark Ads code the owner made for one of their own TikTok posts.
`privacy_url`	No	Meta only: the owner's privacy policy link, for an instant form.
`creative_ids`	No	Meta and TikTok: library creatives to use (creative ids; videos for TikTok). A Google build picks the library's pictures and videos itself (videos need no YouTube channel).
`daily_budget`	No	The owner's own daily budget, in the account's currency (Google, Meta and TikTok).

Output Schema

Name	Required	Description	Default
`error`	No
`advice`	No
`detail`	No
`account`	No
`accounts`	No
`proposalId`	No
`approvalUrl`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Adds substantial context beyond the annotations: the campaign is built switched off and spends nothing until turned on, only what the platform cannot run is refused, owner advice is returned once, and creatives are pulled from the library by id. The idempotency claim ('the same request_id returns the same proposal') is explicitly conditioned on the key, so it does not truly contradict idempotentHint=false, though the tension is worth noting.

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 in the first sentence, but the body is a dense, semicolon-heavy run of platform details that reads as stream-of-consciousness rather than a structured per-platform breakdown. Every sentence carries information, yet the Google/Meta/TikTok details are interleaved and could be reorganized for faster scanning.

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?

With 15 parameters, a 100%-covered schema, an output schema and annotations, the description covers the important behavioral gaps: no side effects on the ad account, safe-by-default off state, idempotency via request_id, and per-platform prerequisites. Remaining gaps are minor, such as how multiple accounts or ambiguous page_id values are resolved.

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 baseline is 3; the description still adds real meaning, such as Taseli choosing the campaign type when 'type' is omitted, a phone-call business starting with its phone number as a call asset, and Spark Ads via spark_code. It stops short of explaining several parameters (page_id, account, language) beyond what the schema already states.

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?

Opens with a specific verb+resource: 'Creates a proposal in Taseli for a new campaign on a topic, planned with AI from the business brief and memory.' It also names the platforms (Google Ads, Meta, TikTok) and makes clear this is a proposal, not a live build, which separates it from sibling tools like propose_change and create_ad.

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?

Gives clear conditions for use: a new campaign per platform, empty accounts supported, plus the exclusions 'Not on read-only accounts' and 'Nothing changes in the ad account here,' with approval happening in Taseli. It never names a sibling alternative (e.g. propose_change for existing campaigns), so routing between siblings is left partly to inference.

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

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