Skip to main content
Glama

Save Collection settings

save_collection
Destructive

PARTIAL SAVE: writes ONLY the 'Collection' field of TitlePublicConfigurationModel; all other v1/v2 fields stay untouched. Collection / album / codex definitions — sets of items, cards, characters or achievements players collect. Defines what counts as the collection, completion rewards, and tier/rarity grouping. Use for compendium-style meta content.

Input Schema

NameRequiredDescriptionDefault
valueYesRoot collection-system config for the title. Add to TitlePublicConfigurationModel as: public CollectionDefinitions Collection { get; set; }
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

A3.6/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, but the description adds genuinely non-redundant behavior: the write is a PARTIAL save scoped to a single field, with other fields preserved. That is the key risk-relevant detail for a destructive mutation. It is silent on whether the submitted Collection object replaces the existing collection config wholesale and on auth/validation requirements.

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-loads the critical "PARTIAL SAVE" constraint, which is the right choice. Four sentences with little waste, though the middle domain definition (sets of items, cards, characters...) is flavor that partly duplicates schema descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations cover the safety profile and the schema is exhaustive, and the description closes the main gap (field-level partiality). But for a destructive mutation of a large nested config, it leaves open whether omitted sub-objects are cleared or preserved and how this differs from save_lootbox overlapping reward-pool concepts.

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 description coverage is 100% and every nested property of CollectionDefinitions is documented in the schema itself, so the baseline is 3. The description adds no additional meaning about title_id or about how the value object interacts with existing config (merge vs. replace).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource at field-level precision: it writes ONLY the 'Collection' field of TitlePublicConfigurationModel and leaves all other v1/v2 fields untouched. This sharply bounds what the tool does, though it never names the obvious siblings (get_collection, save_lootbox) to route an agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

"Use for compendium-style meta content" gives a loose usage context, but there is no explicit when-not or alternative. It does not say to use get_collection to read current state first, nor that CollectionDefinitions.RewardPools is separate from Lootbox's registry — an agent picking between save_collection and save_lootbox gets no help.

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.