spriteship

Prepare and validate a map draft

prepare_map_draft

FREE. Resolve owned artwork and validate a complete editable map without changing the live map. Preserve stable placement IDs on edits and pass expectedRevision from context. Returns immutable draft ID/hash and graph-only topology report. Inspect canonical overview and camera-sized region images before commit; no browser is required. Walkable surfaces/transitions are ground-view only, visualParts/reveal apply across game types. Graph reachability is not body-clearance or gameplay proof. Missing assets use existing quoted generation with user approval.

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": {
      "projectId": "<projectId>",
      "name": "<name>",
      "document": "<document>"
    },
    "name": "prepare_map_draft"
  }
}

Input Schema

Name	Required	Description
`name`	Yes
`mapId`	No
`document`	Yes	Complete map JSON conforming to map_authoring_schema.
`projectId`	Yes
`expectedRevision`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 30, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=false and readOnlyHint=false, but the description adds real value beyond them: it is 'FREE,' it explicitly does not touch the live map, it returns an 'immutable draft ID/hash,' and it warns that 'Graph reachability is not ... gameplay proof' and that missing assets require user approval. This is meaningful behavioral context, though concurrency/idempotency expectations around expectedRevision could be clearer.

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?

Dense but every sentence carries operational weight (cost, scope, revision handling, return shape, inspection step, domain caveats). It is somewhat jargon-heavy (visualParts/reveal, graph-only topology) and leads with 'FREE' rather than the core purpose, but there is little genuine padding.

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?

With no output schema, the description usefully discloses return values (immutable draft ID/hash plus a graph-only topology report) and situates the tool in the prepare-inspect-commit workflow. For a complex, nested-document tool it covers the key operational facts, though the name/mapId/projectId semantics remain unaddressed.

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 only 20% (only the document field is documented), and 5 parameters are present. The description compensates partially by explaining expectedRevision ('pass expectedRevision from context') and hinting at placement-ID stability in the document, but projectId, mapId, and name carry no added meaning from the description.

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?

States a specific verb+resource: 'Resolve owned artwork and validate a complete editable map without changing the live map.' It also implicitly distinguishes itself from commit_map_draft by saying validation happens 'before commit.' However, it never names its closest siblings prepare_map_edits or preview_map_draft, so the agent must infer the boundary.

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 clear context for use: 'validate ... without changing the live map,' 'Inspect canonical overview and camera-sized region images before commit,' and 'no browser is required.' It also flags the condition for missing assets ('use existing quoted generation with user approval'), but it does not explicitly contrast with prepare_map_edits/preview_map_draft, so no true exclusion guidance is offered.

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

All spriteship 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.

Resources

Need Help?