Skip to main content
Glama
Sign In

iDos Games

by com.idosgames
OverviewDiscussionsAdmin

Save Analytics settings

save_analytics
Destructive

PARTIAL SAVE: writes ONLY the 'Analytics' field of TitlePublicConfigurationModel; all other v1/v2 fields stay untouched. Custom events - Firebase Analytics parity. The game sends its own events (logEvent(name, params, value)); the engine stores them per player per UTC day and the dashboard reports counts, unique players, value sums and breakdowns by platform, app version, OS, device, language, country, new/returning and acquisition source; A/B experiment goals and custom funnel steps can use these events. Enabled is the master switch and defaults to OFF. EventNaming: "Open" (any valid name is accepted and joins the title's event catalog up to the PLAN limit) or "Declared" (only names listed in Events). Events maps an event name (^[A-Za-z][A-Za-z0-9_]{0,39}$; prefixes idos_/firebase_/google_/ga_ are reserved, except the automatic idos_* events) to a display name, description and a Blocked flag. Dimensions registers event parameters as reporting dimensions (like GA4 custom dimensions) - the count is capped by the plan; unregistered parameters are accepted but not stored. RetentionDays is how long per-player event data is kept (default 90, capped by the plan); daily title summaries are kept forever. AutomaticEvents (default on) accepts the SDK's automatic events: idos_first_open, idos_session_start, idos_app_update, idos_os_update, idos_screen_view.

Input Schema

NameRequiredDescriptionDefault
valueYesCustom events (Firebase Analytics parity). Everything here is chosen by the publisher within their plan's analytics limits. Absent section or Enabled != true = events are not stored and cost no database access.
title_idYesTitleID, для которого сохраняются данные.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / definitions / AnalyticsEventDefinition / properties / Highlight
      Added value: +{
+  "description": "Highlight weight 1-10 for auto-clips: when the game logs this event, the player's background recording marks the moment, and the heaviest marks become their Best moments clips. Unset = not a highlight. Works even with analytics off (marking happens in the browser).",
+  "format": "int32",
+  "type": [
+    "integer",
+    "null"
+  ]
+}
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations declare destructiveHint=true but say nothing about blast radius; the description supplies that, clarifying only the Analytics field is written and other fields are untouched, plus defaults-off semantics for Enabled, event drops without database access, plan clamping of RetentionDays and Dimensions, and forever-retained daily summaries. It does not warn that the Analytics section itself is overwritten wholesale or whether the change is reversible, so it stops short of 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?

Front-loading the PARTIAL SAVE constraint is effective, but the remainder is one dense semicolon-chained block mixing event storage, reporting, naming modes, dimensions, retention and automatic events. Every clause carries information, yet the lack of grouping makes it hard to scan for the specific knob an agent wants.

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 nested-object mutation with no output schema, the description covers defaults, plan caps, naming modes and the meaning of each sub-field well enough to call it correctly. It omits error behavior on invalid names/overflowing plan limits and any note that the Analytics block is replaced rather than merged.

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 baseline is 3, but the description adds constraints absent from the schema: the event-name pattern, the reserved idos_/firebase_/google_/ga_ prefixes, and the plan-limited catalog interaction between Open/Declared modes. That is genuine operational guidance beyond the field docs.

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 precise verb+resource+scope: "PARTIAL SAVE: writes ONLY the 'Analytics' field of TitlePublicConfigurationModel; all other v1/v2 fields stay untouched." That single clause separates it from save_title_data and the rest of the save_* family, which is exactly the ambiguity an agent faces here.

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" framing implicitly tells the agent it can persist analytics without resending the whole config, which is useful context. However, there is no explicit when-to-use/when-not statement, no pointer to get_analytics for reading current settings, and no stated prerequisites (e.g. that the title must exist or that plan caps apply before calling).

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

All iDos Games toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources