Skip to main content
Glama

Save Match settings

save_match
Destructive

PARTIAL SAVE: writes ONLY the 'Match' field of TitlePublicConfigurationModel; all other v1/v2 fields stay untouched. PvP / match system configuration, grouped by battle mode under InstantBattle. Holds the instant-battle rule catalogue (keyed by RuleID) plus title-wide defaults. Each rule defines wager economy (prize-pool burn) and battle settings: a combat-role → StatID mapping (which Character stat drives HP/Damage/Armor/AttackSpeed/CritChance/CritDamage/Dodge/AllMight), combat params (max rounds, block effect, crit/dodge clamps) and optional per-stat custom formulas. Stat/formula fields reference Character.Stats StatIDs; equipment bonuses (Item) key off the same StatIDs.

Input Schema

NameRequiredDescriptionDefault
valueYesConfiguration of the title's PvP (Match) system. Grouped by battle mode: InstantBattle is the instant-battle container (rule catalog + title-wide defaults). Future match modes (tournament, async turn-based) are added here as sibling containers. Fully optional — absent config falls back to engine defaults (InstantBattle1v1 rule + DefaultData stat mapping), preserving legacy behavior.
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 already declare destructiveHint=true and readOnlyHint=false, so the description's added value is the scope of destruction: only the 'Match' field is replaced, all v1/v2 fields stay untouched. It also discloses the inheritance chain (rule → InstantBattleDefinitions.Defaults → engine defaults) that determines what happens to unset blocks. It stops short of saying whether the write validates against Character.Stats StatIDs or how conflicts are handled, which keeps it from a 5.

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 most important fact — the partial-save scope — is correctly front-loaded in the first clause. But the following paragraph is a dense wall of domain explanation (wager economy, combat-role mapping, formula vocabulary) that largely restates the schema's own definitions, adding length without adding decision-relevant information for tool selection.

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 tool with a very rich nested schema and a destructive annotation, the description covers what an agent must know before calling: exactly what is written, what is preserved, and how omitted config resolves to defaults. The absence of any mention of the response (no output schema exists) is the main remaining gap.

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 the nested definitions already document InstantBattle, Rules, Defaults, StatMapping and combat params exhaustively. The description adds a modest cross-module note that Stat/formula fields reference Character.Stats StatIDs and that Item equipment bonuses key off the same IDs, but most of its prose duplicates what the schema already says. Baseline 3 applies.

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?

The opening sentence names a specific verb and target: 'writes ONLY the Match field of TitlePublicConfigurationModel', immediately telling the agent this is a module-scoped save rather than a whole-title save. The remainder identifies the resource domain (PvP / instant-battle rules, StatID mappings, wager economy). It does not name any sibling (e.g. save_title_data vs save_character), but the partial-save framing is enough to distinguish it in practice.

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?

The 'PARTIAL SAVE' prefix implies the tool should be chosen over a full-title save when only Match config changes, and that other fields are not carried over. However, there is no explicit when-to-use/when-not statement, no mention of the read counterpart (get_match) or prerequisites such as requiring an existing title. Usage is inferable rather than stated.

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.