Skip to main content
Glama
Sign In

Playgama MCP - Publish & Manage HTML5 Games

by com.playgama.developer
OverviewDiscussionsAdmin

Read the sandbox traffic state

get_sandbox_traffic
Read-onlyIdempotent

Read campaign eligibility, bonus offers and existing traffic runs for this game. This read does not launch a campaign or spend a traffic bonus. verdict and offer describe the share bonus, referralOffer a referral bonus (get_referral_program) with its bonusId when available. verdict.reason when not allowed: DSP_DISABLED, NO_SITE (publish first), BLOCKED, NO_COVERS (upload covers, publish again), ANALYSIS_PENDING (ask again shortly), NO_BRIDGE (Bridge SDK not detected; get_bridge_sdk_docs has the integration docs), RUN_IN_PROGRESS, PAYMENT_REQUIRED (share bonus used; paid traffic is in the console), ORG_LIMIT (three share bonuses per organization, lifetime; legacy free runs do not count). offer: FREE or PAID, available (the free bonus only), remainingFreeRuns, durationDays (one free boost), budgetUsd (per post, internal accounting — present a free boost without a dollar amount). current: the run in progress (PENDING, then RUNNING); runs: newest first, with status, failureReason and postUrls. After a start, find the returned run.id in runs and poll until it leaves PENDING. In get_launch_steps the traffic step names its source: REFERRAL with a bonusId (get_referral_program) or SHARE; any completed traffic campaign closes that step, and further bonuses do not reopen it.

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": {
      "applicationId": "<applicationId>"
    },
    "name": "get_sandbox_traffic"
  }
}

Input Schema

NameRequiredDescriptionDefault
applicationIdYesGame id from list_applications

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / applicationId / description
      Previous value: -"Application (game) id, as returned by list_applications"New value: +"Game id from list_applications"
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly and non-destructive annotations, the description explains the verdict reason codes and their implied actions, the distinction between free and paid offers, and the internal accounting caveat for budgetUsd. It also discloses run status progression, failureReason and postUrls fields, and the polling behavior after a start. This is substantial behavioral context that annotations alone do not provide.

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?

The description is front-loaded with purpose and the non-mutation guarantee, and most sentences carry useful output or workflow detail. It is dense and code-heavy, which makes it harder to scan, but there is little outright waste given the absence of an output schema.

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?

There is no output schema, so the description must explain return values, and it does: verdict, offer, referralOffer, current, runs, statuses, failureReason, postUrls, and polling behavior. It also covers the reason codes and next steps, making it complete for an agent calling this read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage for the single applicationId parameter, including the note that it comes from list_applications. The description does not add any further meaning or constraints for applicationId, so the schema carries parameter semantics entirely.

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: it reads campaign eligibility, bonus offers, and existing traffic runs for a game. It immediately distinguishes this read from mutation by saying it does not launch a campaign or spend a traffic bonus, which separates it from start_sandbox_traffic.

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 gives clear usage context: check eligibility, inspect existing runs, and poll returned run IDs until they leave PENDING. It also points to get_referral_program and get_bridge_sdk_docs for related information. It does not explicitly name start_sandbox_traffic as the alternative for launching or spending, so the when-to-use routing is strong but not fully explicit.

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
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources