Skip to main content
Glama

Get Data Collections settings

get_data_collections
Read-only

GET ONLY the 'DataCollections' field of TitlePublicConfigurationModel. Data collections - the creator's own data structures, a Firebase/Supabase-like store inside the platform for games, apps and sites. USE A READY PLATFORM MODULE FIRST (currencies, items, store, lootboxes, quests, leaderboards, chat, social, workshop, match, season, tutorial, localization, push, analytics); declare a collection only for what no module provides (guilds, auctions, orders, catalogs, articles, saved levels, feeds, mail) or for extra data attached to module entities. NEVER store currencies or items inside a record: reference them with a Ref field (Kind Item/Currency/User/…) and move value with Economy (Cost/Grant in engine resource format, charged in the same transaction as the write). Collections maps a collection id (letters, digits, '_', '-', ':' up to 64; a front-end module prefixes its namespace, e.g. 'guild-system:guilds') to: Kind (UserOwned: each record belongs to one user; Shared: records used by many users; Temporary: short-lived, mandatory TTL up to 30 days; Log: append-only, read by time); Mode (Strict = only declared fields); Fields (String, Text = searchable by words, Int, Number, Bool, Date, Json, Array with ItemType, Ref with Ref.Kind, File) with Required/Default (JSON literal)/Min/Max/MaxLength/MaxItems/Enum/Unique/Indexed/Visibility (Everyone/Owner/Server)/ClientWritable=false for server-only fields/Immutable; SortKeys (id + 1..4 components, each a scalar field or createdAt/updatedAt, optionally Descending) - every ordered query uses one, and equality filters on its leading components narrow the range; Access with Read/Create/Update/Delete lists of rules OR-ed together (Anyone - Read only, Authenticated, Owner, Members with MembersField = an Array of Ref(User), Role with a role id from Roles, Server); Limits (MaxItemBytes, MaxItemsPerOwner, TtlSeconds); OnOwnerDeleted (Delete/Anonymize/Keep); Counters (Count or Sum, optional GroupBy - maintained atomically, not allowed for expiring records); Integrations (QuestMetricOnCreate/Update/Delete advance quest objectives with Source ServerApi, AnalyticsEventOn*, TriggerOn* run a CloudCode handler asynchronously); Moderation.BlockedTerms; WriteGate (SegmentGate); PublicViews (published to the CDN for anonymous/site reads: SortKey, optional PartitionField, PageSize, MaxItems, PublishItems) and AnonymousSearch. Queries from a game may filter ONLY by Indexed fields and sort ONLY by declared SortKeys - there are no table scans on the shared cluster. Roles lists title user roles; they are assigned only by CloudCode (server.SetUserRoles) and the dashboard. The count of collections, searchable fields, sort keys, record size and storage are capped by the plan. Records themselves are NOT here - they live in the engine's DataCollection* collections; CloudCode reads and writes them with server.GetDataItem/QueryDataItems/CreateDataItem/UpdateDataItem/DeleteDataItem/BatchDataItems/GetDataCounter.

Input Schema

NameRequiredDescriptionDefault
title_idYesTitleID, для которого читаются данные.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: it is a settings-only read ('Records themselves are NOT here - they live in the engine's DataCollection* collections'), points to the server API for records, and notes that collection/searchable-field/sort-key/storage counts are plan-capped.

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 tool's own behavior is dispatched in one front-loaded sentence, but the body then runs to several hundred words of data-model design guidance (module selection, Economy/Ref rules, per-field options, quest/analytics integrations) that is tangential to invoking a getter. Much of it documents the returned field's shape, but the design-policy passages do not earn their place for a read call.

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?

With no output schema, the description carries the burden of explaining what the returned DataCollections field contains, and it does so exhaustively (Kind, Mode, Fields, SortKeys, Access, Limits, Counters, Integrations, PublicViews, AnonymousSearch, Roles). An agent can interpret the response without any further documentation.

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?

There is a single parameter with 100% schema description coverage, so the schema fully documents title_id. The description adds no format or sourcing detail for the parameter; baseline 3 applies when the schema does the heavy lifting.

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 opening states a precise verb+resource+scope: 'GET ONLY the DataCollections field of TitlePublicConfigurationModel.' This immediately separates it from get_title_data (whole config), save_data_collections (the write counterpart), and get_collection/get_item, so an agent can distinguish it without opening a schema.

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 establishes the read context and heavily guides the domain decision of whether a data collection should exist at all ('USE A READY PLATFORM MODULE FIRST... declare a collection only for what no module provides'). It does not explicitly name a sibling read alternative (e.g., get_title_data for the full model) or state exclusions for calling this getter, so it stops short of full when/when-not guidance.

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.