Skip to main content
Glama
Sign In

iDos Games

by com.idosgames
OverviewDiscussionsAdmin

Get Game Spec settings

get_game_spec
Read-only

GET ONLY the 'GameSpec' field of TitlePublicConfigurationModel. GameSpec - the WHOLE game of a game-constructor title (module kit-game) as data, stored as ONE JSON string (a JSON object serialized to text). The game reads it at sign-in and plays it; a spec that does not validate runs the built-in demo and logs why. Shape (format v1): {"v":1, "engine":"phaser", "seed"?:string, "modes":[{"id", "preset" (a genre preset id, e.g. "runner"), "role":"core"|"meta"|"embedded", "params"?:{preset params, e.g. difficulty 0..1, generosity 0..1, lanes, lives}, "blockParams"?:{blockId:{param:value}} }], "resources"?:[{"id" (snake_case), "kind":"currency"|"item"|"score"|"local", "ref"? (the title's currency/item id for currency/item), "name"? (text key)}], "flows"?:[{who produces/consumes which resource}], "rules"?:[{"id", "on" (event), "when"? (formula), "do":[effects]}], "palette"?:{role:"#rrggbb"} (roles background, ground, lane, primary, secondary, danger, coin, accent, text, muted), "texts"?:{key:{language:text}} (keys title, hint and the resource name keys), "rewards"?:{"adMultiplier":3, "vipMultiplier":5}}. A currency/item resource needs a source and a sink (a mode or system: like system:store). Unknown fields are kept. Max 64 KB; v must be an integer >= 1. Edit by reading it with get_game_spec, changing the JSON and saving the whole string back.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title_id": "<title_id>"
    },
    "name": "get_game_spec"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds genuinely useful behavior: an invalid spec falls back to the built-in demo and logs the reason, unknown fields are preserved, and the value is capped at 64 KB with v required as an integer >= 1. These are non-obvious runtime traits an agent could not infer from annotations or schema; only auth/permission requirements are unaddressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The scope constraint is front-loaded in the first clause, and the remaining bulk is the format-v1 shape spec, which earns its place because there is no output schema to describe the payload. Some nesting inside the shape block is dense, but no sentence is 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?

With no output schema, the description must describe the return value itself, and it does so exhaustively: the JSON shape, mode roles, resource kinds, flow/rule/palette/text/reward sections, validation semantics, and the 64 KB / v>=1 bounds. An agent can both interpret the response and construct a valid edit from this description alone.

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% for the single title_id parameter, so the schema already carries the parameter meaning. The description never mentions title_id or adds constraints on it, which is acceptable at high coverage but means no value is added on this dimension.

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?

"GET ONLY the 'GameSpec' field of TitlePublicConfigurationModel" states a specific verb, a precisely scoped resource, and explicitly delimits it from the broader title-configuration read. The follow-up identifies the backing module (kit-game) and the storage form (one serialized JSON string), so an agent knows exactly what object it is fetching.

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?

The "GET ONLY" framing tells the agent to use this rather than a whole-model read when only the game spec is needed, and the closing sentence gives the edit workflow (read here, mutate the JSON, save the whole string back). It stops short of naming the sibling write tool (save_game_spec) or stating when-not to use it, so it is clear context but not fully explicit routing.

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