Skip to main content
Glama

Playgama MCP - Publish & Manage HTML5 Games

by com.playgama.developer
OverviewDiscussionsAdmin

Bring traffic to the sandbox

start_sandbox_traffic
Destructive

Start an ad campaign that sends players to the sandbox page. Send exactly one of bonusId or postUrls. A referral bonusId (from get_referral_program or get_sandbox_traffic) spends that traffic bonus without a social post and without using the separate share allowance. Reuse the same bonusId and applicationId after an uncertain answer. Poll the returned run id; a timeout is not permission to spend another bonus. The separate share traffic bonus: first help the developer post the game (get_sandbox_share has the post and links), then ask the developer to paste the links of their published posts and pass 1–3 of them (different public HTTPS links from any platform) — never invent one. Each accepted link adds one boost unit to the campaign, up to three. One campaign per game, three games per organization for its lifetime; earlier free runs without sharing do not count. No dollar amount. Ask the developer first. Needs covers in the published revision and the Bridge SDK. Answers the PENDING run; poll get_sandbox_traffic for the returned run.id until it leaves PENDING — FAILED carries failureReason. Only a confirmed safe failure makes a referral bonus retryable; an uncertain DSP outcome keeps its reservation. A refusal carries the reason get_sandbox_traffic shows, or SHARE_REQUIRED / INVALID_POST_URL for missing or invalid links; PAYMENT_REQUIRED: paid traffic is in the console. Repeatedly submitting already accepted links reuses the same grant without changing its budget or dates. Add the remaining links later (up to three total) to increase the same campaign budget and extend it to at least three days from submission, including after it has finished. New links wait while a launch/update is PENDING (RUN_IN_PROGRESS). A stale PENDING run is requeued with the same id and saved links.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bonusIdNoReferral bonus id returned by get_referral_program or get_sandbox_traffic. Send bonusId OR postUrls, never both. A referral bonus requires no social post. Reuse the same bonusId and applicationId after a timeout; never choose a new bonus to retry an unknown outcome.
postUrlsNo1–3 different public HTTPS post URLs from any platform. The developer must publish the posts first. Each accepted link adds one boost unit to the same campaign, up to three. Send new links now or later, up to three total per game. Already accepted links are not credited again. Each addition extends the same campaign to at least three days from submission.
applicationIdYesApplication (game) id, as returned by list_applications

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / bonusId
      Added value: +{
+  "description": "Referral bonus id returned by get_referral_program or get_sandbox_traffic. Send bonusId OR postUrls, never both. A referral bonus requires no social post. Reuse the same bonusId and applicationId after a timeout; never choose a new bonus to retry an unknown outcome.",
+  "maxLength": 128,
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "applicationId",
-  "postUrls"
-]New value: +[
+  "applicationId"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / postUrls / description
      Previous value: -"1–3 different public HTTPS post URLs from any platform. The developer must publish the posts first. Each accepted link adds one boost unit to the same campaign, up to three. Submit all available post links together; the once-per-game bonus cannot be increased by a repeat request."New value: +"1–3 different public HTTPS post URLs from any platform. The developer must publish the posts first. Each accepted link adds one boost unit to the same campaign, up to three. Send new links now or later, up to three total per game. Already accepted links are not credited again. Each addition extends the same campaign to at least three days from submission."
  3. Changed1 schema field changed
    • changedInput schema / properties / postUrls / description
      Previous value: -"1–3 different public HTTPS post URLs from any platform. The developer must publish the post first. One post is enough; extra posts do not increase the boost."New value: +"1–3 different public HTTPS post URLs from any platform. The developer must publish the posts first. Each accepted link adds one boost unit to the same campaign, up to three. Submit all available post links together; the once-per-game bonus cannot be increased by a repeat request."
  4. Changed1 schema field changed
    • changedInput schema / properties / postUrls / description
      Previous value: -"1–3 different public post URLs from X, LinkedIn, Threads or Facebook. The developer must publish the post first. One post is enough; extra posts do not increase the boost."New value: +"1–3 different public HTTPS post URLs from any platform. The developer must publish the post first. One post is enough; extra posts do not increase the boost."
  5. Changed2 schema fields changed
    • addedInput schema / properties / postUrls
      Added value: +{
+  "description": "1–3 different public post URLs from X, LinkedIn, Threads or Facebook. The developer must publish the post first. One post is enough; extra posts do not increase the boost.",
+  "items": {
+    "maxLength": 2048,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 3,
+  "minItems": 1,
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "applicationId"
-]New value: +[
+  "applicationId",
+  "postUrls"
+]
  6. Added

TDQS

A4.7/5.0
Behavior5/5

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

With annotations only telling the agent this is a non-readonly, non-idempotent, open-world, destructive write, the description discloses the behaviors that actually matter: budget/reservation semantics on uncertain outcomes, the rule that a timeout is not permission to spend another bonus, retryability limited to confirmed safe failures, PENDING-run polling and requeue, and the specific refusal codes (SHARE_REQUIRED, INVALID_POST_URL, PAYMENT_REQUIRED). This is rich context well beyond structured fields.

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 critical guidance (one of bonusId/postUrls, reuse after uncertainty) is front-loaded, but the body is a dense wall of run-on sentences with several rules repeated between description and schema (postUrls credits, retry semantics). It is information-dense yet oversized and hard to scan, so it is not appropriately concise even though most sentences carry real meaning.

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 destructive mutation tool with no output schema, the description covers everything an agent needs: inputs, prerequisites, failure modes, retry/idempotency-safe behavior, error codes, and the polling follow-up via get_sandbox_traffic. Nothing material is left to inference.

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 description coverage is 100%, so the schema already documents all three parameters and the 3-unit cap. The description adds operational meaning to those parameters: reusing the same bonusId/applicationId after an uncertain answer, the 1–3 link range with one boost unit each, and that later link additions extend the same campaign rather than create a new one.

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 opening sentence states a precise verb and resource (start an ad campaign that sends players to the sandbox page), which is immediately distinguishable from siblings like get_sandbox_traffic (polling) and get_sandbox_share (posting). An agent can tell what this tool does without opening 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes between the two input modes ('Send exactly one of bonusId or postUrls'), names the source tools for bonusId (get_referral_program, get_sandbox_traffic) and for share links (get_sandbox_share), and states the exclusion that a referral bonus needs no social post. Prerequisite ('ask the developer first', needs covers in published revision and Bridge SDK) is also given.

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

All Playgama MCP - Publish & Manage HTML5 Games toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources