GripForge

Create map concept views or an editable map

gripforge_map_generate

Queue a persistent map job. stage=concept creates a private master overview plus optional views and stops. views: overview,top_down,entrance,objective. All additional views are conditioned on the SAME pinned master; they are illustrations, not exact 3D renders. reference is an environment screenshot for a NEW layout. To add views to an existing concept, pass source_concept instead; the master is kept unchanged and is free. One credit per new image (full new 4-view set = 4); default is overview only. Poll generation_read with include_preview=true to see the views. After the user selects the concept, submit stage=build with the returned concept and a new idempotency key. Build costs 1 credit and is the default for existing callers; legacy concept_item accepts a Library image ID, while concept pins its exact version. wizard: look stylized|painted|toon|anime|realistic|lowpoly|pixel (rendering, separate from style; omit for the theme default); style realistic|stylized|lowpoly|handpainted (legacy wording); world open_world|closed_arena|dungeon|linear|battle_map; terrain auto|plains|desert_canyon|forest|snow|island|volcanic; size small|medium|large; boundary fixed|infinite (open edge, finite terrain); spawn single|teams; teams 2|4; boss,safeZone,extraction booleans. sources selects catalog/workspace/community props. Build uses the common Scene Engine with independent terrain, regions, paths, zones and asset instances. Cancel/retry keeps successful images and billing. No automatic visual validation, promotion or Unreal import.

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": {
      "prompt": "<prompt>",
      "wizard": "<wizard>"
    },
    "name": "gripforge_map_generate"
  }
}

Input Schema

Name	Required	Description
`seed`	No
`stage`	No
`views`	No	Unique requested views, stage=concept only. The master overview is always included; omitting views keeps overview only.
`prompt`	Yes
`wizard`	Yes
`concept`	No	Exact chosen concept revision for stage=build. Mutually exclusive with concept_item.
`sources`	No
`reference`	No	Pinned source-environment screenshot for stage=concept only. Upload to Library and pin first.
`structure`	No	Optional explicit gripforge.map-structures.v1 plan for stage=build: terraces with polygon/elevation and separate ramp/bridge connections. Read gripforge_map_schema for the contract. Preserves canyon voids; validates bridge clearance, endpoints and slopes. Uses durable per-piece assets and the common SceneDocument. Dimensions must match wizard.dimensions. Solo maps only; result is a structural work version requiring visual review.
`concept_item`	No	Legacy Library concept image ID. Prefer an immutable concept reference.
`workspace_id`	No	Workspace authorized by the current key. Returned scene links open this workspace.
`source_concept`	No	Existing immutable master to add views to, stage=concept only. Mutually exclusive with reference; never regenerate this master.
`idempotency_key`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 3, 2026

addedInput schema / properties / wizard / properties / look

Added value: +{
+  "description": "Rendering look, separate from the game style: stylized (neutral) | painted | toon | anime | realistic | lowpoly | pixel. Old values (handpainted, cartoon, low_poly…) are read as aliases. Omit for the style default. Map: the theme gives the biome, the look the materials (LevelSpec.look).",
+  "enum": [
+    "stylized",
+    "painted",
+    "toon",
+    "anime",
+    "realistic",
+    "lowpoly",
+    "pixel"
+  ],
+  "type": "string"
+}

addedInput schema / properties / wizard / properties / style / description

Added value: +"Legacy wording kept in the intent; it does not change the rendering. Use look."

Changed12 schema fields changedSep 23, 2026

addedInput schema / properties / concept

Added value: +{
+  "description": "Exact chosen concept revision for stage=build. Mutually exclusive with concept_item.",
+  "properties": {
+    "assetId": {
+      "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_.:-]{0,159}$",
+      "type": "string"
+    },
+    "fileRole": {
+      "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_.:-]{0,159}$",
+      "type": "string"
+    },
+    "revisionId": {
+      "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_.:-]{0,159}$",
+      "type": "string"
+    }
+  },
+  "required": [
+    "assetId",
+    "revisionId"
+  ],
+  "type": "object"
+}

addedInput schema / properties / concept_item

Added value: +{
+  "description": "Legacy Library concept image ID. Prefer an immutable concept reference.",
+  "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_.:-]{0,159}$",
+  "type": "string"
+}

addedInput schema / properties / reference

Added value: +{
+  "description": "Pinned source-environment screenshot for stage=concept only. Upload to Library and pin first.",
+  "properties": {
+    "assetId": {
+      "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_.:-]{0,159}$",
+      "type": "string"
+    },
+    "fileRole": {
+      "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_.:-]{0,159}$",
+      "type": "string"
+    },
+    "revisionId": {
+      "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_.:-]{0,159}$",
+      "type": "string"
+    }
+  },
+  "required": [
+    "assetId",
+    "revisionId"
+  ],
+  "type": "object"
+}

changedInput schema / properties / seed / maximum

Previous value: -9007199254740991New value: +2147483647

changedInput schema / properties / seed / minimum

Previous value: --9007199254740991New value: +-2147483647

addedInput schema / properties / source_concept

Added value: +{
+  "description": "Existing immutable master to add views to, stage=concept only. Mutually exclusive with reference; never regenerate this master.",
+  "properties": {
+    "assetId": {
+      "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_.:-]{0,159}$",
+      "type": "string"
+    },
+    "fileRole": {
+      "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_.:-]{0,159}$",
+      "type": "string"
+    },
+    "revisionId": {
+      "pattern": "^[a-zA-Z0-9][a-zA-Z0-9_.:-]{0,159}$",
+      "type": "string"
+    }
+  },
+  "required": [
+    "assetId",
+    "revisionId"
+  ],
+  "type": "object"
+}

addedInput schema / properties / sources

Added value: +{
+  "items": {
+    "enum": [
+      "catalog",
+      "workspace",
+      "community"
+    ],
+    "type": "string"
+  },
+  "maxItems": 3,
+  "minItems": 1,
+  "type": "array"
+}

addedInput schema / properties / stage

Added value: +{
+  "enum": [
+    "concept",
+    "build"
+  ],
+  "type": "string"
+}

addedInput schema / properties / structure

Added value: +{
+  "additionalProperties": {},
+  "description": "Optional explicit gripforge.map-structures.v1 plan for stage=build: terraces with polygon/elevation and separate ramp/bridge connections. Read gripforge_map_schema for the contract. Preserves canyon voids; validates bridge clearance, endpoints and slopes. Uses durable per-piece assets and the common SceneDocument. Dimensions must match wizard.dimensions. Solo maps only; result is a structural work version requiring visual review.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

addedInput schema / properties / views

Added value: +{
+  "description": "Unique requested views, stage=concept only. The master overview is always included; omitting views keeps overview only.",
+  "items": {
+    "enum": [
+      "overview",
+      "top_down",
+      "entrance",
+      "objective"
+    ],
+    "type": "string"
+  },
+  "maxItems": 4,
+  "minItems": 1,
+  "type": "array"
+}

addedInput schema / properties / wizard / properties

Added value: +{
+  "boss": {
+    "type": "boolean"
+  },
+  "boundary": {
+    "enum": [
+      "fixed",
+      "infinite"
+    ],
+    "type": "string"
+  },
+  "dimensions": {
+    "description": "Explicit ground footprint in metres. Overrides size presets and world multipliers. Example: {width:500,depth:500}. Four-team maps require a square.",
+    "properties": {
+      "depth": {
+        "maximum": 5000,
+        "minimum": 100,
+        "type": "number"
+      },
+      "width": {
+        "maximum": 5000,
+        "minimum": 100,
+        "type": "number"
+      }
+    },
+    "required": [
+      "width",
+      "depth"
+    ],
+    "type": "object"
+  },
+  "extraction": {
+    "type": "boolean"
+  },
+  "safeZone": {
+    "type": "boolean"
+  },
+  "size": {
+    "enum": [
+      "small",
+      "medium",
+      "large"
+    ],
+    "type": "string"
+  },
+  "spawn": {
+    "enum": [
+      "single",
+      "teams"
+    ],
+    "type": "string"
+  },
+  "style": {
+    "enum": [
+      "realistic",
+      "stylized",
+      "lowpoly",
+      "handpainted"
+    ],
+    "type": "string"
+  },
+  "teams": {
+    "anyOf": [
+      {
+        "const": 2,
+        "type": "number"
+      },
+      {
+        "const": 4,
+        "type": "number"
+      }
+    ]
+  },
+  "terrain": {
+    "enum": [
+      "auto",
+      "plains",
+      "desert_canyon",
+      "forest",
+      "snow",
+      "island",
+      "volcanic"
+    ],
+    "type": "string"
+  },
+  "world": {
+    "enum": [
+      "open_world",
+      "closed_arena",
+      "dungeon",
+      "linear",
+      "battle_map"
+    ],
+    "type": "string"
+  }
+}

removedInput schema / properties / wizard / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```

First observedSep 20, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses billing (1 credit per new image, 4-view set = 4, master reuse is free, build = 1 credit), idempotency-key behavior, that cancel/retry preserves successful images and billing, and that there is no automatic validation, promotion or Unreal import. These are the operational traits an agent needs and none are in the annotation block.

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-loaded with a clear purpose sentence and almost every sentence carries information, but the middle is a dense, semicolon-chained enumeration of wizard values and billing rules that is hard to scan. It is compact rather than well-structured, mixing stage workflow, cost rules and enum documentation in one block.

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 13-param, nested-object tool with no output schema, the description covers the two-stage workflow, polling via generation_read with include_preview, and build inputs. It is slightly incomplete on return shape (job id) and on the required idempotency_key semantics for build, but overall sufficient to call the tool correctly.

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?

With only 54% schema coverage, the description compensates by enumerating wizard enum meanings (look vs legacy style, world/terrain/size/boundary/spawn/teams, boss/safeZone/extraction) and by explaining the mutually exclusive reference/source_concept/concept/concept_item relationships. It adds genuine semantics beyond the raw schema, though a few params (seed, workspace_id, idempotency_key) remain unexplained in the prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a concrete action ('Queue a persistent map job') and the description clearly separates the two modes (stage=concept creates views, stage=build produces an editable map). It does not, however, name any sibling (e.g. gripforge_map_concept, gripforge_map_plan) to route an agent away from, so differentiation must be inferred from the description alone.

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?

Gives real conditional guidance: use source_concept to add views to an existing master, use reference for a NEW layout, submit stage=build after the user selects a concept, and notes build is the default for existing callers. It stops short of stating when NOT to use this tool versus its map siblings.

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

All GripForge tools Inspect

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.