Work with your game
through MCP.

Setup

Three steps to your first call.

1. 01

   Open Developer access

   Sign in to ReelGrove and open Developer access, or choose Help → Connect an agent in a project’s Lab. Select the studio that contains your game. You need a ready project and current project-read permission.

2. 02

   Create a project key

   Choose the project, give the key a recognizable name, and select its scopes. Expiry defaults to 7 days; you can choose 1–30 days. Save the secret from the one-time dialog.

3. 03

   Add a manual HTTP connection

   In your MCP client, choose a remote Streamable HTTP server. Copy the endpoint from Developer access and add the authorization header below. Then connect and ask for project_context.

For example, an account at https://studio.example uses https://studio.example/mcp. Use the actual endpoint shown in your account; this example host is a placeholder.

Client configuration formats differ. Enter the URL and header in your client’s manual settings; there is no universal configuration JSON or OAuth sign-in flow for this endpoint. A client that only supports OAuth cannot use a project key through that flow.

Keep the secret in your client’s credential settings. Do not put it in a URL, a prompt, source control, or a shared screenshot. Signing into ReelGrove in a browser does not authenticate an MCP client.

Access

Give the client a specific job.

Every key includes projects:read. Choose the additional scopes its task needs. Developer access includes matching read scopes for discipline writes. Whole-game import access (projects:import) includes project read and every Art, Sound, Motion, Math and Frontend read/write scope; existing keys keep their original scopes.

A key can never grant more access than its creator currently has. Its saved scopes are an upper limit, including for a studio owner. Membership changes and permission reductions take effect on later calls. The capabilities returned by project_context describe this intersection; they do not confirm current trial or paid editing capacity.

Reference

Customer project tools.

The hosted service provides 122 project tools. They cover creative work, exact QA history, profile matrices, read-only readiness assessment, exports, hosted math and browser observations, and explicit project creation, restoration, cloning and kit installation. Current permissions and feature availability are checked on every call.

Run project_context first. Use its project.activeRevision wherever the tool requires expectedActiveRevision or expectedAnchorRevision. Build status and chunk calls use the admission ID returned by their original request. The key selects the project; do not send a game, studio, project, actor, or filesystem path.

Discovery describes the tool contract. Hosted math and browser execution require separately enabled workers; a listed tool does not confirm installation availability or permission. Source inventory paths are returned by the server and can only select files inside the retained owned project.

Workflows

Ask clearly. Check the result.

These are prompts you can give your connected assistant, followed by example MCP tools/call parameters. They are tool calls, not client configuration files.

Inspect the project before making changes

Identify the project this key belongs to. List its artwork slots and current image assets. Tell me which images are replaced. Don’t change anything.

{
  "name": "project_context",
  "arguments": {}
}

Read project.activeRevision from the result. The UUID below is illustrative: replace it with that exact value. Slot and cue names must come from the current registry.

{
  "name": "art_slots",
  "arguments": {
    "expectedActiveRevision": "11111111-1111-4111-8111-111111111111"
  }
}

Then call list_assets with the same revision and assetClass: "image". Use a returned assetId to read or bind an asset.

Replace artwork, or restore it deliberately

Read the current circle binding, upload the supplied PNG, replace that slot using the latest observed revision, then reread to confirm. Stop on a conflict.

upload_asset takes assetClass, filename, base64 data, and its matching lowercase SHA-256 in sha256, plus the active revision. Uploading makes an asset available; bind_image assigns it to a declared slot.

For a replacement, send the returned assetId. For a restore, use restoreDefault: true instead. The example assumes the current registry declares circle at binding revision "3":

{
  "name": "bind_image",
  "arguments": {
    "expectedActiveRevision": "11111111-1111-4111-8111-111111111111",
    "slot": "circle",
    "expectedRevision": "3",
    "restoreDefault": true
  }
}

People watching the project’s Lab, or returning to it in the same browser, see slots saved with your key marked Changed elsewhere in Art Lab, with a time, until they open the slot or choose Mark all seen. The Lab does not say whether a person or an agent made the save. With Auto preview on, the saves apply to an open Lab’s running preview on builds that support live updates; the Lab never restarts the game for them. A saved bind does not prove the game draws the image, so ask a person to check the preview. In the Lab, Copy brief gives your assistant a starting point for up to 60 shown slots, with their sizes, binding revisions and these argument names.

Set a sound cue’s level

Inspect the spin cue and its current audio. Keep the same take, set its gain to 45%, and confirm the saved binding. Stop if another person changes the cue first.

Call sound_cues, then bind_sound with cue, the existing assetId, the observed expectedRevision and integer volumePpm: 450000. The range is 0–1,000,000; one million means full volume. Omitting volumePpm uses the cue’s declared default gain, so send it explicitly when preserving a mix. It cannot accompany restoreDefault.

Adjust a declared Motion state

Read the circle slot’s supported Motion settings. If its idle state allows this, save a gentle 1-second bob at intensity 550, with sineInOut easing and looping. Use the current saved revision. Tell me what changed and how to sample it in Art Lab.

Start with list_motions. Each build declares its own supported presets, timing and intensity limits. This example only applies when the returned idle capabilities permit these settings:

{
  "name": "set_motion",
  "arguments": {
    "expectedActiveRevision": "11111111-1111-4111-8111-111111111111",
    "slot": "circle",
    "state": "idle",
    "expectedRevision": "0",
    "settings": {
      "preset": "bob",
      "durationMs": 1000,
      "intensity": 550,
      "easing": "sineInOut",
      "loop": true
    }
  }
}

A successful save confirms persisted settings. To check rendering, open the project’s Art Lab and sample the saved Motion state. The MCP save itself does not prove that an animation rendered.

Understand the published math

List the published math libraries and summarize the default variant’s theoretical return, outcome weights and evidence gaps. Separate what the report measures from anything it does not prove.

{
  "name": "math_report",
  "arguments": {
    "expectedActiveRevision": "11111111-1111-4111-8111-111111111111"
  }
}

Call list_math_libraries first. For another published variant, add its exact name as variant. Omitting it, or sending an empty string, selects the default. A report does not certify game-event correctness or external platform approval.

QA review

Keep an exact scenario.

Give the key projects:read, art:read, sound:read, motion:read, frontend:read and math:read to inspect scenarios. Add reviews:comment to save one. This does not use an editor seat.

Call capture_scenario with the active revision, a fresh requestId UUID, a short name, the exact published mode and decimal-string bookId. Add variant for a named math variant and profile for expected dimensions, currency, language, reduced motion and ordered actions.

ReelGrove reads the published outcome and computes the source and creative commitments. Saving records an expectation; it does not execute the browser or approve a game. After a timeout, retry the exact UUID and payload to recover the saved receipt. Reusing the UUID with changed arguments conflicts.

list_scenarios returns up to 50 records and a nextOffset for paging. Use get_scenario with a returned scenarioId to read exact original events and current stale components. An older trace remains reviewable after a reset; it is not evidence that the current game passed QA.

Select a regression case

Find a published outcome before saving it.

Call find_scenario_outcomes with the current expectedActiveRevision, published mode, optional variant and one explicit kind. It uses the same outcome finder as the workspace, with project read and all five discipline reads. Search remains available after editing expires; canCapture separately reports current capture access.

• SCENARIO_OUTCOME_KIND_LOSS: payout is exactly zero.
• SCENARIO_OUTCOME_KIND_PAYOUT_RANGE: supply inclusive minPayoutX100 and maxPayoutX100 as decimal strings. For 5× through 100× base stake, use "500" and "10000".
• SCENARIO_OUTCOME_KIND_MAXIMUM: the largest published payout, including records with zero draw weight.
• SCENARIO_OUTCOME_KIND_EVENT: supply an exact recorded eventType. Names do not establish feature behavior.

Send only the fields for your selected filter. Each page contains at most 32 numeric-ID-ordered summaries with exact string IDs, payouts and draw weights, plus book hashes and event counts. Zero-weight records are not drawn by weighted selection; you can still choose one explicitly for replay review.

To continue, copy nextAfterBookId into afterBookId and copy mathSha256 into expectedMathSha256, preserving the same filter and revision. The hash is required for continuation. Start a new search if published math changes. Keep IDs and payout bounds as strings, including values above JavaScript’s safe integer range.

{
  "expectedActiveRevision": "CURRENT_REVISION_UUID",
  "mode": "base",
  "kind": "SCENARIO_OUTCOME_KIND_MAXIMUM"
}

studioctl -url YOUR_PROJECT_MCP_URL -key-file /private/project.key \
  call find_scenario_outcomes -args-file outcomes.json

Searching does not save a scenario, open a preview or run a game. Explicitly call capture_scenario with a selected mode, variant and book ID after reviewing its name and browser profile. Capture reads the current book again; the search response is not a frozen expectation or browser evidence.

Regression workflow

Carry an expectation into the next build.

Read the original with get_scenario, then call prepare_scenario_carry_forward with its sourceScenarioId and exact sourceScenarioSha256, the current expectedActiveRevision, a target name, published mode and bookId, and optional variant and profile. The server reads the current book independently; an old outcome identifier does not promise the same events in new math.

Inspect the returned plan and exact target eventsJson. Input changes, event positions, payout, selection and profile comparisons are separate. Equal payouts can still have different symbols or feature events. The plan always records browserEvidence: "not_recorded".

To retain the expectation, call carry_forward_scenario with that exact preparation request inside target, a new durable requestId UUID and the plan’s sha256 as reviewedSha256. The server checks the target again before saving both the new scenario and its parent link. Changed inputs require a fresh review; the original remains unchanged.

After a lost reply, retain the UUID and identical arguments. If the active revision changes, use get_scenario with the request UUID as scenarioId and the current revision to recover a historical save. An absent receipt does not prove an outstanding request cannot commit. Completed identical requests remain recoverable after review permission or editor capacity expires, provided all current read scopes still apply. New saves require current review access and available studio resources.

The saved scenario is an expectation for a later release execution. It does not prove the new build passed, create named suite membership, or approve a release. The account QA workflow provides the same review and retained history.

Repeatable QA

Keep a named set of exact expectations.

Use list_regression_suites to find each suite’s current head, list_regression_suite_versions to follow its nextOffset history, and get_regression_suite with an exact suiteId and versionId to inspect its definition and each case’s stale inputs. Keep the current expectedActiveRevision on every call, including historical reads.

save_regression_suite takes a suiteId, a new durable requestId, name, optional multiline description, and 1–32 cases. Each case contains a short stable key, an exact saved scenarioId and its lowercase scenarioSha256. Case keys and scenario selections must be distinct. For a new suite, omit both expectedVersionId and expectedVersionSha256; later saves must supply both values from the current head. Every save appends an immutable version.

To capture a candidate, call capture_regression_suite_release with the chosen suiteId, versionId, versionSha256, a new durable requestId, title and optional multiline requirements. Every case must still match current inputs. Changed expectations need reviewed replacement scenarios and a new suite version. A captured candidate remains linked to its original version even after later suite edits.

New saves and captures require all five discipline reads, reviews:comment and current trial resource access, without an editor seat. Retry an uncertain operation with its exact original UUID and arguments; a changed body conflicts. Completed exact retries and history remain available after trial expiry or comment permission removal while all current reads still apply. After a project revision changes, recover a saved version using its request UUID as versionId, or a candidate using get_release, with the current revision.

Suite capture saves expectations. Start native observations separately with start_release_execution using the returned release ID and candidate digest, then inspect or compare the retained results. Saving a suite or candidate never creates a browser pass, human release decision or Engine approval.

Complete regression coverage

Every selected outcome. Every saved profile.

The matrix workflow saves explicit viewport, currency, language, reduced-motion and ordered-action combinations. It applies every combination to every exact selected saved outcome, with a maximum of 32 cells. A matrix records expectations; an isolated browser run supplies observations.

1. 01

   Save an exact profile version

   Use save_profile_matrix with a durable matrixId, requestId, name and 1–32 combinations. Each contains a stable key and a scenario profile. Preserve the action array’s order. For later versions, send both observed expectedVersionId and expectedVersionSha256; previous versions remain unchanged.

2. 02

   Prepare the complete set

   Call prepare_profile_matrix_expansion with that exact matrixId, versionId, versionSha256, a new durable requestId and selected outcomes. Each outcome has a stable key, original scenarioId and scenarioSha256. Repeated captures also pin both current expectedSuiteVersionId and expectedSuiteVersionSha256. Inspect every returned cell and its original provenance.

3. 03

   Capture, then run deliberately

   Send the unchanged prepared request as target and its plan digest as reviewedSha256 to capture_profile_matrix_expansion. Every case and one suite version are saved together. Use that returned version with capture_regression_suite_release, then start its execution separately. There is no automatic run, math promotion or human approval.

Keys use up to 31 lowercase letters, numbers, underscores or hyphens. Changed original inputs must first be reviewed through scenario carry-forward. Too many cells, stale outcomes or unsupported runner profiles reject the complete preparation; no cells disappear silently. The runner currently accepts replay, wait:complete, skip and turbo in the saved order, with viewports up to 4096 pixels per dimension. Actual game support is checked during each isolated run, where unsupported controls remain explicit failed results.

All operations require project and every discipline’s read access. New versions and captures also need reviews:comment and current studio resources, without an editor seat. Retained reads and exact completed retries remain available after resource expiry under current key authority. Keep the original request UUID and body after an uncertain reply; read its exact version or expansion before another mutation. Human decisions remain in the account workflow.

new owned projects

Reserve a separate project from your build pipeline.

Explicit projects:create access lets a key on an existing project upload an initial-contract TAR, request isolated validation and register a distinct new project. It requires the complete import scope set and current editor access. Existing import keys keep their original scopes.

The selected project is the authorization anchor. Its source stays unchanged, and the key gains no ordinary access to the destination. Issue a separate destination key in Developer access for later automated editing. Portable restoration adds a separate explicit plan review below; machine cloning uses a separate explicit capture.

Call project_context first and send its current revision as expectedAnchorRevision. Keep the begin request UUID, exact archive and returned admission ID; use a separate UUID for explicit registration. A later anchor edit can change this authorization precondition on an exact retry without changing the original reservation. Same-actor replacement read keys can inspect or cancel permitted work and recover completed registration; unfinished writes require the original key.

The studioctl owned-project workflow saves private retry receipts before new effects. Upload never validates or registers automatically.

explicit portable restoration

Review a portable plan before creating its editable copy.

Prepare a portable archive, upload its TAR through owned-project, and validate it. get_project_restoration_context returns its exact archive and plan digests. Start only with the reviewed planSha256 and a separately saved request UUID; the worker verifies the complete capsule before copying.

All five calls use the current expectedAnchorRevision. The original creation key owns new effects; a replacement read key for the same actor and anchor can recover or request permitted cleanup. A changed anchor revision never recaptures the destination. Imported reviews remain unattested, and later automated editing needs a separately issued destination key.

Use the CLI inspection, explicit start and status commands. Inspection and polling never start work automatically. Keep both receipts after an uncertain response.

copy saved work

Keep the exact source behind each copy.

start_project_clone copies the current saved source and Lab state into a different project in the same studio. Supply the current expectedActiveRevision, immutable sourceRevision, name and saved request UUID. New captures require creation, import and export scopes with current editing capacity. A context read starts no work.

Keep the source revision, name and request UUID after an uncertain reply. On an accepted retry, use the current authorization revision while preserving the original source revision. The result returns the same captured build and destination. A changed semantic request is refused; recovery never silently copies a newer source.

The original key owns unfinished effects. A same-actor replacement read key can recover accepted history and request permitted cleanup, including after editing expires. The destination needs its own separately issued key. Imported history grants no destination approval. Use the durable clone CLI workflow.

reusable creative work

Review a kit before installing it.

Twelve scoped tools bring the existing Studio kits workflow to MCP. The key selects one existing project; every call names its current revision. Selected artwork, sound and animations use their matching permissions, including media embedded in animation documents.

1. Check get_kit_context, then persist the exact ZIP hash, decimal byte count, selected inventory paths and a request UUID before begin_kit_upload.
2. Upload verified 1 MiB chunks at the committed offset, then explicitly call inspect_kit_upload.
3. Persist another UUID and call plan_kit_installation. Review the exact added or reused media, fresh animation identities and storage charge.
4. Confirm that reviewed planSha256 with a separate persisted UUID through install_kit. Refresh the Lab, inspect playback and configure bindings explicitly.

Get and list tools recover your original receipts; list calls accept either a cursor or the exact planning/upload request UUID. A lost response keeps the same request, archive and plan. Upload and plan deadlines remain 30 minutes, including rate-limit pauses. Completed and expired receipts remain readable with current permissions after editing expires.

Continuing work requires its original live key. A replacement key for the same actor and project can read or cancel authorized history, but cannot adopt an upload or installation. Completed installations and restored review holds stay protected. Imported content remains an unverified source claim; installation creates no bindings, rendered-pass result or release approval.

project archives

Keep a verified copy from CI.

Export tools use a key with projects:export, project read and Art, Sound, Motion, Frontend and Math read access. Existing keys keep their original permissions. Each operation stays within the key’s project and its creator’s own export history.

Call create_project_export with the current expectedActiveRevision, a new durable requestId and kind: PROJECT_EXPORT_KIND_STANDALONE, PROJECT_EXPORT_KIND_DEVELOPMENT or PROJECT_EXPORT_KIND_PORTABLE. Repeat the same request after an uncertain response. Poll get_project_export using the returned exportId until it is ready.

studioctl -url YOUR_PROJECT_MCP_URL -key-file /private/project.key \
  export download -export-id EXPORT_UUID -expected-revision CURRENT_REVISION_UUID \
  -output /private/project-backup.zip

The CLI verifies each chunk and the complete archive’s SHA-256 before creating the destination file, and never overwrites an existing file. It pauses and retries the same read when admission is busy. Downloads allow 30 minutes by default, with an explicit timeout up to one hour. Archives are limited to 2 GiB and expire after 24 hours; job history lasts seven days. A reset or newly activated revision prevents downloading a capture from the previous revision. Download before switching builds.

Revoking or expiring the requesting key stops its unfinished export work. A new authorized key can recover its creator’s retained history without replacing the original request. cancel_project_export revokes delivery; storage cleanup can finish later. This scope grants no project creation, restoration, kit installation or release approval.

Readiness and CI

Inspect the exact evidence behind a decision.

Six read-only tools connect the account’s structured readiness policies and human reviews to your assistant and CI. They require project read plus Art, Sound, Motion, Frontend and Math read access. Editing access can expire while those authorized historical reads remain available.

Discover policies with list_readiness_policies, follow list_readiness_policy_versions, and inspect an exact versionId with get_readiness_policy. The returned suite is the version selected by that policy. Use get_release and get_release_execution to inspect a candidate and its observed runs.

assess_release_readiness takes the current expectedActiveRevision, exact releaseId and candidateSha256, and an explicit observations array. Select up to 32 distinct runs using each executionId, runId and lowercase receiptSha256. An empty array records missing observations. The tool never chooses a passing run automatically.

Optionally supply retainedReviewId to reuse the original human assertions for this same candidate. The server verifies that review and its evidence first. Omit it to leave human requirements unrecorded. Machines cannot supply their own requirement resolutions, browser verdicts, exceptions or approval. Use get_readiness_review and list_readiness_reviews for immutable decisions and separate current stale markers.

studioctl -url YOUR_PROJECT_MCP_URL -key-file /private/project.key \
  call assess_release_readiness -args-file readiness-selection.json > readiness-result.json

Stop CI on a command error. A successful call can still return report.ready: false: inspect that field and every reported check. Keep the exact selection, report and its SHA with your build artifacts. A human exception preserves the failed check, so it cannot pass a strict all-checks-pass gate. Policy changes and human decisions stay in the account review workflow; a computed ready report creates no studio or Engine approval.

Animation workflow

Edit a document. Pin the version you reviewed.

Use list_animation_documents and get_animation_document to inspect the exact saved native document. list_animation_revisions discovers retained revisions; pass a returned UUID as projectRevision while keeping the current expectedActiveRevision. Follow nextCursor on history lists.

To save, send documentId, base64 native json, its lowercase sha256, the observed expectedSequence as a decimal string, and a new durable requestId UUID. Explicit "0" creates the first head. Native document validation still applies to documents up to format version 13, including tint, dark colour, blend modes, clip loop and tags, and event values; use Animation Lab to author visually and inspect the result. A rejected document returns invalid_argument with an issue naming the first fault’s JSON path (for example animations[0].tracks[3].keys[2].easing), reason code, message and any suggestion. Nothing is saved; fix that field and save again.

Every embedded image needs art:read, and every embedded sound needs sound:read, including unused assets. Introducing new bytes also needs that discipline’s write scope. Existing authorized media can be preserved; an optional mediaClaims entry can select exact project Lab bytes using mediaId and labAssetId, or exact retained media using documentId, versionId and mediaId inside retained. Claims never grant permission or authorize changed bytes.

Run list_animation_scenarios to discover the game’s declared animation hooks. These hooks are separate from saved QA scenarios. set_animation_binding requires the exact document version and digest, current declaration and source hashes, the observed binding sequence, and an explicit clip or mix selection. Send sound: false for silent playback; enabling sound requires Sound read permission. Later document edits do not retarget an existing binding.

Save, restore, set and clear operations append history. After an uncertain reply, keep the same request UUID and identical inputs, or query get_animation_save_result / get_animation_binding_save_result. The receipt distinguishes the originally applied version from the current head. A missing receipt does not prove an outstanding request cannot commit. Reads and your retained receipts remain accessible after editor capacity expires; mutation retries still require current editing authority.

Native JSON reads and saves through MCP are limited to 4 MiB; metadata for larger saved documents remains available. Use Animation Lab for larger bodies. A saved document or binding does not prove that a game rendered it: inspect the preview and capture the relevant outcome evidence separately.

The project-key animation file commands transfer native documents up to 24 MiB without an account session. They preserve the editor’s permission checks and exact save receipts. Inline MCP keeps its 4 MiB limit.

exact retained evidence

Archive saved QA explicitly.

These three tools use the same service as the account archive controls. get_qa_history_usage returns project and studio working counts, retained counts and exact decimal byte usage. Archiving frees working capacity; it does not delete records, free retained storage or create an approval.

Read the selected record first. Persist a new requestId UUID and the full request before calling archive_scenario with scenarioId and scenarioSha256, or archive_release with releaseId and candidateSha256. Both require the current expectedActiveRevision, every evidence read capability, reviews:comment and effective editing capacity. The key fixes the studio and project; the receipt identifies its real human actor.

Retry only the same UUID and exact body after an uncertain reply. A completed retry remains readable after editing expires. If the active revision changes, use get_scenario or get_release with the current revision and compare its summary.archive to the original request, actor and digest. Do not replace the saved request’s revision or create another archive automatically.

The history filter on list_scenarios and list_releases accepts QA_HISTORY_SELECTION_ACTIVE, QA_HISTORY_SELECTION_ARCHIVED or QA_HISTORY_SELECTION_ALL. Omission keeps complete history. Follow nextOffset through pages of at most 50; scenario offsets are bounded at 4096 and release offsets at 2048. Archived records retain their exact identity, stale-input information, books, human decisions and suite membership.

Connected review

Capture a candidate, then inspect its evidence.

Use capture_release with expectedActiveRevision, a durable requestId, a short title, optional multiline requirements and up to 32 distinct scenarioIds. Every selected scenario must match the current source, math and creative inputs. The server captures those commitments; the client cannot supply an approval or replace their hashes.

Retry the exact UUID and body after an uncertain response. Read list_releases with optional offset, then get_release with the returned releaseId. A changed input marks old evidence stale while preserving its history. The account shows the same candidate and historical human decisions. Human approval and requests for changes stay in the account review workflow.

Optional workers

Request observations and math experiments explicitly.

These tools require enabled hosted workers. A candidate's executionAvailable and the result of math_experiment_context report installation availability. Your key and current membership are checked independently on every operation. Local browser QA and math commands remain available for local workflows.

Observe a frozen release candidate

Pass the exact releaseId, candidateSha256, active revision and a new durable requestId to start_release_execution. Keep these arguments until the receipt is known. List and inspect the resulting executions to distinguish observed passes or failures from interrupted infrastructure. Your frontend needs the documented observer integration; unsupported controls fail the check. This observation does not grant human or Engine approval.

Use compare_release_observations with the current expectedActiveRevision and explicit baseline and target selections. Each selection contains the exact executionId, runId and receiptSha256 returned by get_release_execution. Both runs must belong to this project and retain their verified artifacts; you may compare observations from earlier revisions after a new build becomes active.

The comparison reports changed input commitments, expected and observed event positions, payout differences, pass/fail direction and screenshot pixel counts. It identifies whether replay conditions match and marks each side stale against the current project. Different dimensions or screenshots beyond the pixel budget have an explicit unavailable pixel-diff status. Differences describe observations; they do not establish a cause, carry a scenario forward to a new build, or grant approval. All five discipline read scopes are required. Retained observations remain comparable after paid or trial editor capacity expires, while current membership and key access still apply.

Cancellation preserves completed observations. Retirement requests file removal after containers have stopped; receipt identities remain. Use the account review screen for screenshots and larger evidence files. Account download URLs are not project-key capabilities.

Generate and compare math

Build receipt comparisons are a separate workflow.

Start with math_experiment_context. Select exact listed source files, an available profile, Python commands, a seed, time/output limits and mode costs with optional RTP or hit-rate targets. Submit the reviewed specification with inputsReviewed: true, its exact sourceSha256, active revision and a durable UUID. Workers run without network access; dependencies must already exist in the selected profile or reviewed source.

The optional pinned Engine Math SDK profile supplies Python generation dependencies and source-path helpers. Use it only when the context lists it; the standard-library profile remains a separate choice.

find_math_experiment_outcomes reads up to 32 exact generated books per page. Supply the retained jobId, expectedOutputSha256, expectedReportSha256, generated mode, optional variant and the same explicit outcome filters used by find_scenario_outcomes. Keep both hashes on continuations with afterBookId. Search requires current Project and Math read access and remains available after paid editing expires. It creates no preview or build. Frozen replay opens only through the account’s Math experiments controls.

Read the retained experiment and independent validation report before comparing results. Keep decimal strings and rational values exact. MCP responses are bounded to 8 MiB; the account handles larger reports. An explicit promote_math_experiment request prepares an ordinary owned build. Review its validation and activate it separately: neither a successful experiment nor promotion changes the active game automatically.

native build evidence

Compare recorded builds.

get_math_build_receipt accepts only a retained jobId and returns canonical JSON bytes, their SHA-256 and the recorded limitations. compare_math_build_receipts takes beforeJobId and afterJobId from the same project and returns both receipt hashes plus separate subject, recipe, selected-byte, output-byte and independent-run checks. Both need current Project and Math read access, including on historical revisions; editing capacity is not required.

The separately enabled python313-normalized-v1 profile measures fixed input metadata and its actual toolchain before each isolated phase. Only two distinct eligible native runs with matching inputs, recipe, toolchain and output can state two clean runs matched. That statement does not guarantee future determinism or approve a game. Legacy, SDK and optimizer observations retain their original limitations.

Imported JSON, equal submitted hashes and repeated use of one job cannot create native evidence. The tools accept no uploaded receipt or trust flag. A canceled or removed result cannot issue a new receipt. MCP responses remain bounded to 8 MiB. The workspace view supports larger receipt downloads. See the CLI examples; ordinary compare_math_experiments continues to compare distributions.

Research

Math tools and market activity.

The seven research tools accept expectedActiveRevision and an input object. The discovered schema describes each input and its decimal-string units. Published comparisons and simulations can only read the project selected by your key.

{
  "name": "get_engine_tracker",
  "arguments": {
    "expectedActiveRevision": "11111111-1111-4111-8111-111111111111",
    "input": {"ranking": "games", "period": "past30Days", "sort": "turnover", "query": "Waylanders", "limit": 20}
  }
}

The tracker includes every source-tracked game, with search, provider filtering and optional pagination. Missing statistics and artwork remain null. Turnover uses USD micro-unit strings; RTP is source-declared. imageUrl and thumbnailUrl reference public artwork. Cached snapshots include source and freshness information; updates are normally checked every 15 minutes.

Submitted archives and lookup CSVs are limited to 4 MiB through the customer API, within an 8 MiB total request. Browser imports run locally and support up to 32 MiB. Simulations run at most 2 million rounds. Private inputs are not logged or saved. These tools model test outcomes and never place bets or modify project files.

Working together

Two revisions keep changes deliberate.

expectedActiveRevision

The project revision UUID from project_context. A project reset changes it. Refresh the context and inspect the new state before continuing.

expectedRevision

The current binding revision from art_slots, sound_cues or list_motions. Send it as a decimal string, including "0" when that is the observed value.

If a teammate edits the same binding, the older write is rejected with aborted. Reread the current value, compare the changes and decide what to save. Do not automatically resend with an incremented revision.

After a timeout, cancellation or an unconfirmed response, a change may already have been saved. Read the current state before trying again. The client should inspect MCP isError and the structured code and message; an error is not a successful tool result.

Credentials

A small key with a clear lifetime.

• The secret is shown once. Closing its dialog, changing pages or studios, or signing out clears the displayed secret. It cannot be retrieved from the key list.
• If key creation times out, refresh the list and revoke any key from that attempt before creating another. An uncertain response is not a reason to create several keys.
• Use Developer access to revoke your own keys, including keys for studios you have left. A revoked or expired key cannot authenticate.
• Signing out of the browser does not revoke machine keys. Revoke a key explicitly when you no longer need it. Password recovery revokes your existing keys; removing your membership revokes that studio’s keys.
• Resetting a project does not move the key to another project. Fetch the new active revision. Rejoining a studio does not revive a revoked key.

You can have up to 5 active keys per user and project. Keys do not add paid seats; creating more keys cannot increase your permissions or editing capacity.

When something needs attention

Find the next useful check.

Product scope

What this connection supports today.

Asset reads and uploads through MCP are limited to 4 MiB per file. Images support PNG, JPEG and WebP; SVG uploads are not supported. Audio supports WAV, MP3, OGG, FLAC, M4A and AIFF. Files still undergo the Lab’s format and storage checks. Use the Lab UI for supported larger files.

list_motions and set_motion edit the build’s declared idle and win presentation states. Supported presets are pulse, bob and tilt, with linear, sineInOut or quadOut easing; individual states may allow only a subset and impose tighter bounds. The separate animation-document tools read and save native timeline and rig data and bind exact versions to declared game hooks.

When owned projects are enabled, MCP supports prepared TAR uploads, isolated validation and explicit revision activation for the key’s existing owned project. Create the initial project in the account or use scoped initial creation through MCP with explicit creation access. The studioctl download provides owned-build upload|status|validate|cancel|activate commands with durable retry receipts; upload never activates automatically. Keep the same receipt and archive after an uncertain response. A revoked or expired admitting key stops new queued effects.

The customer MCP endpoint supports scoped asset and animation edits, prepared builds, retained review evidence and explicitly enabled math and browser workers. It does not generate images or audio, edit repository source, run arbitrary build commands, operate real-money games, publish to Engine, or manage keys, teams and billing. Human review remains a separate account action. Validation and browser observations do not grant Engine approval.