Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

by EL4CTEO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Read and write saved data

datastore
Destructive

Inspect and modify saved player data in DataStore, MemoryStore, or OrderedDataStore from Studio or live servers. Identify lost progress or corrupted saves by listing stores, reading keys, and reviewing version history before writing.

Instructions

Reads and writes the game's saved data — DataStore and MemoryStore — from the connected Studio.

This is the only tool here that looks at anything outside the place file. Every other tool answers 'is the instance right'; this one answers 'is what the player saved right', which is a different question and the one behind most reports of lost progress, reset stats, or items that come back after a rejoin.

kind="data" (the default) is DataStoreService: permanent, per-player, and version-tracked. kind="memory" is MemoryStoreService: a shared scratchpad that expires on its own — queues, locks, live leaderboards.

The workflow for a bug report is: list with no store to see what exists, list with one to see its keys, get the player's key, and — the part worth knowing about — versions then get with a version to see what that same key held BEFORE it broke. You cannot diagnose a bad save by looking only at the bad save.

Writes need confirm: true on kind="data", because nothing in this server can undo one: there is no recording to cancel and no Ctrl+Z. Read the key first.

DataStore needs 'Enable Studio Access to API Services' ticked in Game Settings → Security, and a published place. If it is off, this tool says so in those words rather than reporting the raw 502. MemoryStore needs neither.

target="live" is the other half of this tool and the one that answers a real bug report. It goes to Roblox directly instead of through Studio, so it sees exactly what the running servers see — not what the place happens to be connected to, and with no Studio API toggle involved. Use it whenever the question is about a player who is actually playing. It needs an Open Cloud key and a universe id; the user sets both once with cloud in the Studio panel.

kind="ordered" (live only) is OrderedDataStoreService, the leaderboard backend: numbers only, always sorted, no history. list returns it ranked highest first, which is the leaderboard itself.

op="snapshot" is the safety net. It tells Roblox to snapshot every data store in the experience, so support can roll them back. TAKE ONE BEFORE ANY LIVE WRITE. Roblox allows one per experience per UTC day, and the result says whether this call actually took one — a second call the same day reports success while doing nothing, and anything written since the first one is not covered.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNoget only: read the version that was current at this Unix time in MILLISECONDS. Use when the player says when it broke but no version id is known.
opNo'list' shows stores (no `store`) or a store's keys (with one). 'versions' is DataStore only and is how you see a key's history.list
keyNoThe key. Usually the player's UserId as a string.
ttlNomemory set only: seconds before the value expires. Defaults to an hour.
kindNo'data' = DataStoreService, permanent and versioned. 'memory' = MemoryStoreService, shared and expiring. They are separate storage — a key in one is not in the other.data
limitNolist/versions only: rows to return. Defaults to 50.
scopeNoDataStore scope, if the game uses them. Omit for the default — but if a store reads as empty and you expected data, a scope is the usual reason.
storeNoData store name, or the sorted map's name for memory. Omit on `list` to see which stores exist.
valueNoset only: the new value as JSON — {"coins":10}, 42, or a bare string. Read the key first and edit what comes back rather than writing a value from scratch: a save is usually a whole table and writing part of one deletes the rest.
amountNolive increment only: how much to add. Negative subtracts. Safer than get-then-set for currency, which loses whatever the player earned in between.
createNolive set only: allow writing a key that does not exist yet. Off by default — Open Cloud separates create from update, and a typo'd key silently creating a second empty save beside the real one is exactly what looks like a player's data resetting.
cursorNolist only: continue from a previous call's cursor.
prefixNolist only: only names starting with this.
targetNo'studio' reads through the connected Studio — right while building. 'live' goes to Roblox over Open Cloud and sees what the published game's servers see — right for a bug report.studio
confirmNoRequired for set and remove on kind="data". This is real player data and nothing here can put it back.
versionNoget only: read this exact version instead of the current value. From `versions`.
studioIdNoTarget Studio; omit for the active one.
universeIdNolive only: which game. Omit to use the one set with `cloud universe <id>` in the panel.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.6.8
    • addedInput schema / properties / amount
      Added value: +{
+  "description": "live increment only: how much to add. Negative subtracts. Safer than get-then-set for currency, which loses whatever the player earned in between.",
+  "type": "number"
+}
    • addedInput schema / properties / create
      Added value: +{
+  "description": "live set only: allow writing a key that does not exist yet. Off by default — Open Cloud separates create from update, and a typo'd key silently creating a second empty save beside the real one is exactly what looks like a player's data resetting.",
+  "type": "boolean"
+}
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "data",
-  "memory"
-]New value: +[
+  "data",
+  "memory",
+  "ordered"
+]
    • changedInput schema / properties / op / enum
      Previous value: -[
-  "list",
-  "get",
-  "versions",
-  "set",
-  "remove"
-]New value: +[
+  "list",
+  "get",
+  "versions",
+  "set",
+  "remove",
+  "increment",
+  "snapshot"
+]
    • addedInput schema / properties / target
      Added value: +{
+  "default": "studio",
+  "description": "'studio' reads through the connected Studio — right while building. 'live' goes to Roblox over Open Cloud and sees what the published game's servers see — right for a bug report.",
+  "enum": [
+    "studio",
+    "live"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / universeId
      Added value: +{
+  "description": "live only: which game. Omit to use the one set with `cloud universe <id>` in the panel.",
+  "type": "string"
+}
  2. Addedv0.6.5

TDQS

A4.9/5.0
Behavior5/5

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

The description goes well beyond the annotations, disclosing that writes on kind='data' cannot be undone, that confirm: true is required, that DataStore needs a Studio API access setting, and that live snapshots are limited to one per UTC day while still reporting success on duplicate calls. There is no contradiction with the annotations.

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?

The description is long but every section earns its place for an 18-parameter, dual-target tool. It is front-loaded with the core purpose and sibling differentiation, then moves through workflow, safety warnings, authentication prerequisites, live targeting, ordered stores, and snapshot limits in a labeled, scannable structure with no filler.

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?

For a tool with no output schema, it is remarkably complete: it covers preconditions, auth requirements, live vs studio behavior, per-kind constraints, failure wording, the snapshot safety net, and the exact workflow needed to diagnose lost progress. An agent has enough context to invoke every operation correctly and know what to expect.

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 coverage is 100%, so the baseline is 3, but the description adds substantial operational meaning around parameters: the meaning of kind, the behavior of target='live', the confirm requirement, the read-before-write advice for value, and the special semantics of op='snapshot'. It does not repeat every schema field, which is appropriate given the schema already documents them.

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 specific verb and resource: 'Reads and writes the game's saved data — DataStore and MemoryStore.' It then distinguishes itself from all sibling tools by saying it is the only tool that looks outside the place file, answering a different question than 'is the instance right'.

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?

It gives explicit guidance on when this tool is appropriate versus every other tool, and further divides usage between studio and live targets. It also outlines a concrete bug-report workflow: list stores, list keys, get the player's key, then versions and get with a version to see the prior state.

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

Deploy Server

Other Tools