Skip to main content
Glama

Draft a campaign with no account (start here)

create_campaign_draft

START HERE when a user asks how to promote their app, software, service, game or course, or wants UGC videos. Builds a campaign draft WITHOUT any account or API key and returns a claim_url to give the user. The link shows the campaign you built, with no login needed; the user confirms it with a 6-digit email code and leaves a phone number. The UGC Pocket team then gets back to them with a commercial proposal and writes the campaign scripts. Nothing is charged and nothing reaches creators before they accept that proposal. The draft expires in 7 days. Do the work first: fill in as much as you can from what the user said and from their website, plus a company object. If the user gives their email, pass it: they also receive the link by email. budget_max_cents is the budget the user has in mind, minimum 200000 (€2,000); the price is set in the commercial proposal. Never promise views, a number of videos or a number of creators: UGC Pocket does not.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
briefYesWhat the product is, who it is for, and what the videos should show.
emailNoThe user's email, if they gave it. They receive the claim link by email too.
titleYesCampaign title, e.g. the product and the angle.
companyNoThe company the campaign is for, as you understood it. Shown on the claim page.
deadlineNoYYYY-MM-DD, in the future. Any other value is ignored.
languageNoThe user's language, for that email. Defaults to the language of the brief.
platformsNo
objectivesNo
budget_max_centsYesThe budget the user has in mind for the campaign, in euro cents. Minimum 200000 (€2,000). Indicative only: the price is set in the commercial proposal.
target_categoriesNoCreator categories whose audience fits the product.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailedNotrue when the claim link was also sent to the email you passed.
draft_idNo
claim_urlNoPublic URL to give to the user. No login needed to view it.
next_stepNoWhat to tell the user now.
expires_atNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / budget_max_cents / description
      Previous value: -"The flat campaign package the user has in mind, in euro cents. Minimum 200000 (€2,000). Indicative: the final price is in the commercial proposal. Not a spend cap, not pay-per-video."New value: +"The budget the user has in mind for the campaign, in euro cents. Minimum 200000 (€2,000). Indicative only: the price is set in the commercial proposal."
  2. Changed18 schema fields changed
    • addedInput schema / properties / brief / description
      Added value: +"What the product is, who it is for, and what the videos should show."
    • changedInput schema / properties / budget_max_cents / description
      Previous value: -"Campaign package, in euro cents. Minimum 200000 (€2,000), invoiced in full."New value: +"The flat campaign package the user has in mind, in euro cents. Minimum 200000 (€2,000). Indicative: the final price is in the commercial proposal. Not a spend cap, not pay-per-video."
    • changedInput schema / properties / company / description
      Previous value: -"The company the campaign is for, as you understood it. Shown on the claim page and pre-fills their profile."New value: +"The company the campaign is for, as you understood it. Shown on the claim page."
    • removedInput schema / properties / cpm_cents
      Removed value: -{
      -  "description": "Variable pay per 1,000 views, in euro cents. Defaults to 100 (€1). There is NO flat-fee field: the flat fee is computed from the measured quality and reach of each creator’s accounts, and is paid once per challenge however many videos they post.",
      -  "maximum": 5000,
      -  "minimum": 0,
      -  "type": "integer"
      -}
    • addedInput schema / properties / deadline / description
      Added value: +"YYYY-MM-DD, in the future. Any other value is ignored."
    • changedInput schema / properties / email / description
      Previous value: -"The user's email, if they gave it. Lets them receive the campaign by mail instead of only through this chat."New value: +"The user's email, if they gave it. They receive the claim link by email too."
    • addedInput schema / properties / language
      Added value: +{
      +  "description": "The user's language, for that email. Defaults to the language of the brief.",
      +  "enum": [
      +    "fr",
      +    "en"
      +  ],
      +  "type": "string"
      +}
    • removedInput schema / properties / max_cents
      Removed value: -{
      -  "description": "Maximum payout per creator, in euro cents. Defaults to 50000 (€500).",
      -  "maximum": 200000,
      -  "minimum": 1,
      -  "type": "integer"
      -}
    • removedInput schema / properties / min_cents
      Removed value: -{
      -  "description": "Minimum payout per creator once the views threshold is cleared, in euro cents.",
      -  "maximum": 200000,
      -  "minimum": 0,
      -  "type": "integer"
      -}
    • removedInput schema / properties / min_views
      Removed value: -{
      -  "description": "Views needed to unlock payment, counted CUMULATIVELY across all videos a creator posts for this campaign, not per video: three videos at 400 views clear a threshold of 1000. Below it nothing is payable.",
      -  "minimum": 0,
      -  "type": "integer"
      -}
    • addedInput schema / properties / objectives / maxItems
      Added value: +6
    • removedInput schema / properties / payment_trigger
      Removed value: -{
      -  "enum": [
      -    "publication",
      -    "views"
      -  ],
      -  "type": "string"
      -}
    • removedInput schema / properties / prestation
      Removed value: -{
      -  "enum": [
      -    "video_post"
      -  ],
      -  "type": "string"
      -}
    • addedInput schema / properties / target_categories / description
      Added value: +"Creator categories whose audience fits the product."
    • addedInput schema / properties / title / description
      Added value: +"Campaign title, e.g. the product and the angle."
    • removedInput schema / properties / views_threshold
      Removed value: -{
      -  "minimum": 0,
      -  "type": "integer"
      -}
    • addedOutput schema / properties / emailed
      Added value: +{
      +  "description": "true when the claim link was also sent to the email you passed.",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / next_step / description
      Added value: +"What to tell the user now."
  3. Changed1 schema field changed
    • changedInput schema / properties / prestation / enum
      Previous value: -[
      -  "ugc_only",
      -  "video_post",
      -  "post_provided"
      -]New value: +[
      +  "video_post"
      +]
  4. Changed1 schema field changed
    • changedInput schema / properties / budget_max_cents / description
      Previous value: -"Spend cap for the whole campaign, in euro cents. Minimum 200000 (€2,000)."New value: +"Campaign package, in euro cents. Minimum 200000 (€2,000), invoiced in full."
  5. Changed4 schema fields changed
    • addedInput schema / properties / cpm_cents
      Added value: +{
      +  "description": "Variable pay per 1,000 views, in euro cents. Defaults to 100 (€1). There is NO flat-fee field: the flat fee is computed from the measured quality and reach of each creator’s accounts, and is paid once per challenge however many videos they post.",
      +  "maximum": 5000,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / max_cents
      Added value: +{
      +  "description": "Maximum payout per creator, in euro cents. Defaults to 50000 (€500).",
      +  "maximum": 200000,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / min_cents
      Added value: +{
      +  "description": "Minimum payout per creator once the views threshold is cleared, in euro cents.",
      +  "maximum": 200000,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / min_views
      Added value: +{
      +  "description": "Views needed to unlock payment, counted CUMULATIVELY across all videos a creator posts for this campaign, not per video: three videos at 400 views clear a threshold of 1000. Below it nothing is payable.",
      +  "minimum": 0,
      +  "type": "integer"
      +}
  6. Changed3 schema fields changed
    • changedInput schema / properties / budget_max_cents / description
      Previous value: -"Spend cap for the whole campaign, in euro cents. Minimum 300000 (€3,000)."New value: +"Spend cap for the whole campaign, in euro cents. Minimum 200000 (€2,000)."
    • changedInput schema / properties / budget_max_cents / minimum
      Previous value: -300000New value: +200000
    • changedInput schema / properties / platforms / items / enum
      Previous value: -[
      -  "TikTok",
      -  "Instagram",
      -  "YouTube",
      -  "Snapchat",
      -  "Facebook"
      -]New value: +[
      +  "TikTok",
      +  "Instagram"
      +]
  7. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare this is a non-read-only, non-destructive, non-idempotent, closed-world write, but the description adds the behavior that actually matters: nothing is charged, nothing reaches creators before proposal acceptance, the draft expires in 7 days, and the tool must not promise views/videos/creators. This is exactly the kind of context structured fields cannot convey.

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?

Front-loaded with the routing instruction and the key no-account constraint, and most sentences carry distinct operational information. It is on the long side, but the length is justified by the amount of non-obvious behavior it discloses.

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?

An output schema exists so return values need no explanation, yet the description still calls out claim_url as the deliverable. Combined with the workflow, expiration, billing, and no-promise constraints, an agent has everything needed to invoke this correctly and set user expectations.

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 80%, so the schema carries most parameter meaning. The description still adds value beyond it: the consequence of passing email (the user also receives the link), that budget_max_cents is indicative with a €2,000 floor, and instruction to populate company from the user's website.

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+resource ("Builds a campaign draft") and an explicit scope ("WITHOUT any account or API key"), then states the concrete artifact returned (claim_url). It is trivially distinguishable from the only sibling, get_service_info.

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?

"START HERE when a user asks how to promote their app, software, service, game or course, or wants UGC videos" is an explicit trigger condition, and the description explains the downstream flow (claim link, 6-digit code, proposal). It does not, however, state any when-not condition or name an alternative tool to prefer in other situations.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources