Skip to main content
Glama

Save Game Loop settings

save_game_loop
Destructive

PARTIAL SAVE: writes ONLY the 'GameLoop' field of TitlePublicConfigurationModel; all other v1/v2 fields stay untouched. Core gameplay loop configuration — match settings, level pacing, difficulty curves, energy/cooldown gates, retry/continue economy. Use for tuning the moment-to-moment gameplay; not for content (use Item, Character, Collection) and not for meta-progression (use Season).

Input Schema

NameRequiredDescriptionDefault
valueYesRoot config of the Core Loop system in TitlePublicConfigurationModel.GameLoop. Holds the nested board configuration.
title_idYesTitleID, для которого сохраняются данные.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / definitions / ResourceEntryType / enum
      Previous value: -[
      -  "Item",
      -  "VirtualCurrency",
      -  "CryptoCurrency",
      -  "Purchase",
      -  "RewardedVideoCredit",
      -  "PlatformCoin"
      -]New value: +[
      +  "Item",
      +  "VirtualCurrency",
      +  "CryptoCurrency",
      +  "Purchase",
      +  "RewardedVideoCredit",
      +  "PlatformCredits"
      +]
    • changedInput schema / definitions / ResourceEntryType / x-enum-descriptions
      Previous value: -[
      -  "Catalog item. Requires CatalogID, ItemID and Amount.",
      -  "In-game (off-chain) virtual currency. Requires CurrencyID and Amount. Looked up in cfg.Currency.VirtualCurrencies.",
      -  "On-chain cryptocurrency. Requires CurrencyID and Amount. Looked up in cfg.Currency.CryptoCurrencies.",
      -  "Real-money payment in a store. Requires only ProductID (a product from cfg.Purchase.Products); the amount and currency are decided by the store from the SKU price tier. NOT a storable resource and never passes through ResourceService — the money is paid outside before the server learns about it, so the entry is consumed by the receipt check (ExternalPaymentGate) and stripped before the resource operation. Allowed only in Consume and only for Consumable products.",
      -  "Rewarded-video credit. One credit equals one verified ad view that can be spent in systems requiring rewarded video (lootbox open, reward double, re-roll, booster). Granted +1 per server-verified view, or as N from milestones/quests/premium perks; spent -1 per gated action.",
      -  "Payment in Coin, the PLATFORM currency on the player's iDos Games account. Requires only Amount — the price in whole Coin. Like Purchase it is NOT a player resource and never enters ResourceService: it is settled by PlatformCoinPayment in the same transaction as the grant (buyer charged, author credited). Accepted only by the store (Store.Purchase) for now; allowed only in Consume."
      -]New value: +[
      +  "Catalog item. Requires CatalogID, ItemID and Amount.",
      +  "In-game (off-chain) virtual currency. Requires CurrencyID and Amount. Looked up in cfg.Currency.VirtualCurrencies.",
      +  "On-chain cryptocurrency. Requires CurrencyID and Amount. Looked up in cfg.Currency.CryptoCurrencies.",
      +  "Real-money payment in a store. Requires only ProductID (a product from cfg.Purchase.Products); the amount and currency are decided by the store from the SKU price tier. NOT a storable resource and never passes through ResourceService — the money is paid outside before the server learns about it, so the entry is consumed by the receipt check (ExternalPaymentGate) and stripped before the resource operation. Allowed only in Consume and only for Consumable products.",
      +  "Rewarded-video credit. One credit equals one verified ad view that can be spent in systems requiring rewarded video (lootbox open, reward double, re-roll, booster). Granted +1 per server-verified view, or as N from milestones/quests/premium perks; spent -1 per gated action.",
      +  "Payment in Credits, the PLATFORM currency on the player's iDos Games account (players see it as \"Aspis\" — write Aspis in player-facing text). Requires only Amount — the price in whole Credits. Like Purchase it is NOT a player resource and never enters ResourceService: it is settled by PlatformCreditsPayment in the same transaction as the grant (buyer charged, author credited). Accepted only by the store (Store.Purchase) for now; allowed only in Consume."
      +]
    • changedInput schema / definitions / ResourceEntryType / x-enumNames
      Previous value: -[
      -  "Item",
      -  "VirtualCurrency",
      -  "CryptoCurrency",
      -  "Purchase",
      -  "RewardedVideoCredit",
      -  "PlatformCoin"
      -]New value: +[
      +  "Item",
      +  "VirtualCurrency",
      +  "CryptoCurrency",
      +  "Purchase",
      +  "RewardedVideoCredit",
      +  "PlatformCredits"
      +]
  2. Changed3 schema fields changed
    • changedInput schema / definitions / ResourceEntryType / enum
      Previous value: -[
      -  "Item",
      -  "VirtualCurrency",
      -  "CryptoCurrency",
      -  "Purchase",
      -  "RewardedVideoCredit"
      -]New value: +[
      +  "Item",
      +  "VirtualCurrency",
      +  "CryptoCurrency",
      +  "Purchase",
      +  "RewardedVideoCredit",
      +  "PlatformCoin"
      +]
    • changedInput schema / definitions / ResourceEntryType / x-enum-descriptions
      Previous value: -[
      -  "Catalog item. Requires CatalogID, ItemID and Amount.",
      -  "In-game (off-chain) virtual currency. Requires CurrencyID and Amount. Looked up in cfg.Currency.VirtualCurrencies.",
      -  "On-chain cryptocurrency. Requires CurrencyID and Amount. Looked up in cfg.Currency.CryptoCurrencies.",
      -  "Real-money payment in a store. Requires only ProductID (a product from cfg.Purchase.Products); the amount and currency are decided by the store from the SKU price tier. NOT a storable resource and never passes through ResourceService — the money is paid outside before the server learns about it, so the entry is consumed by the receipt check (ExternalPaymentGate) and stripped before the resource operation. Allowed only in Consume and only for Consumable products.",
      -  "Rewarded-video credit. One credit equals one verified ad view that can be spent in systems requiring rewarded video (lootbox open, reward double, re-roll, booster). Granted +1 per server-verified view, or as N from milestones/quests/premium perks; spent -1 per gated action."
      -]New value: +[
      +  "Catalog item. Requires CatalogID, ItemID and Amount.",
      +  "In-game (off-chain) virtual currency. Requires CurrencyID and Amount. Looked up in cfg.Currency.VirtualCurrencies.",
      +  "On-chain cryptocurrency. Requires CurrencyID and Amount. Looked up in cfg.Currency.CryptoCurrencies.",
      +  "Real-money payment in a store. Requires only ProductID (a product from cfg.Purchase.Products); the amount and currency are decided by the store from the SKU price tier. NOT a storable resource and never passes through ResourceService — the money is paid outside before the server learns about it, so the entry is consumed by the receipt check (ExternalPaymentGate) and stripped before the resource operation. Allowed only in Consume and only for Consumable products.",
      +  "Rewarded-video credit. One credit equals one verified ad view that can be spent in systems requiring rewarded video (lootbox open, reward double, re-roll, booster). Granted +1 per server-verified view, or as N from milestones/quests/premium perks; spent -1 per gated action.",
      +  "Payment in Coin, the PLATFORM currency on the player's iDos Games account. Requires only Amount — the price in whole Coin. Like Purchase it is NOT a player resource and never enters ResourceService: it is settled by PlatformCoinPayment in the same transaction as the grant (buyer charged, author credited). Accepted only by the store (Store.Purchase) for now; allowed only in Consume."
      +]
    • changedInput schema / definitions / ResourceEntryType / x-enumNames
      Previous value: -[
      -  "Item",
      -  "VirtualCurrency",
      -  "CryptoCurrency",
      -  "Purchase",
      -  "RewardedVideoCredit"
      -]New value: +[
      +  "Item",
      +  "VirtualCurrency",
      +  "CryptoCurrency",
      +  "Purchase",
      +  "RewardedVideoCredit",
      +  "PlatformCoin"
      +]
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

The 'PARTIAL SAVE … all other v1/v2 fields stay untouched' line is genuine context beyond the annotations, narrowing what destructiveHint=true actually destroys. It still doesn't say whether the supplied value replaces the whole GameLoop object (dropping unspecified sub-fields) or merges, nor whether a publish/version step is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, zero filler, and the highest-value constraint (partial save) is front-loaded before the routing guidance.

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?

For a 2-parameter but deeply nested mutation tool with annotations and a fully described schema, the description covers scope, content, and alternatives well. The remaining gap is replacement-vs-merge semantics for the GameLoop object itself, which matters given destructiveHint=true.

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?

Schema coverage is 100% and both properties are documented, so baseline 3 applies. The description's field inventory (match settings, level pacing, difficulty curves, energy/cooldown gates) only loosely maps to the schema's Board/CommunityChest shape, adding framing but no parameter-level detail.

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+scope ('PARTIAL SAVE: writes ONLY the GameLoop field of TitlePublicConfigurationModel') and then states what the field covers. An agent immediately knows this mutates one named slice of title config and not the whole record.

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 usage: 'Use for tuning the moment-to-moment gameplay; not for content (use Item, Character, Collection) and not for meta-progression (use Season).' Both positive selection and named alternatives for the negative cases are given.

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.