Skip to main content
Glama
wfbcargo

spawn-mcp

by wfbcargo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

spawn_latest

Pull upstream project changes into a Spawn game project: sync saved specs or rebase git work before builds and after refused pushes, refusing dirty trees and aborting colliding rebases safely.

Instructions

Take upstream's work into your project. ON ENGINE 6.0+ (git lane) this is git pull --rebase: Savi, exec, and other clones commit to the same repo, so pull before you build and again after a refused push. A dirty tree is refused rather than stashed, and a rebase that collides is aborted with your commits intact and the colliding paths named. mode / version / updateSlug / applyLocal are document-lane concepts and are refused there. ON A PRE-6.0 WORLD (document lane) it is unchanged: pull a saved spec — head (mode=dev, default), published live (mode=live), an exact version, or a published updateSlug. Head pulls sync scripts (untouched fast-forward; both-changed → .theirs) and update the base-version rail — use after version_conflict. Non-head pulls are read-only unless applyLocal:true. version and updateSlug are mutually exclusive.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo'dev' = saved head (default); 'live' = published live versiondev
versionNoExact saved spec version (mutually exclusive with updateSlug)
applyLocalNoWrite pulled scripts/base-version (and game.json when saveGameJson). Defaults true for plain head pulls, false for mode=live / version / updateSlug
projectDirNoAbsolute path to the Spawn game project (game.json / .env). Defaults to SPAWN_PROJECT_DIR or the MCP process cwd.
updateSlugNoPublished update slug → pinned spec version (mutually exclusive with version)
saveGameJsonNoWhen applying: write pulled spec to game.json
engineVersionNoOptional engine version this call assumes: a semver ('6.0.0', '5.4') or an era name ('6.0' for a git world, 'document' for a pre-6.0 one). Omit it and the world's engine is detected from the API and cached. When passed it is CHECKED against the real pin and a mismatch fails the call without writing anything — it is an assertion, not an override.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • addedInput schema / properties / engineVersion
      Added value: +{
+  "description": "Optional engine version this call assumes: a semver ('6.0.0', '5.4') or an era name ('6.0' for a git world, 'document' for a pre-6.0 one). Omit it and the world's engine is detected from the API and cached. When passed it is CHECKED against the real pin and a mismatch fails the call without writing anything — it is an assertion, not an override.",
+  "type": "string"
+}
  2. First observedv1.2.0

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and does so richly: dirty trees are refused (not stashed), colliding rebases are aborted with commits intact and paths named, behavior is asserted by engineVersion rather than overridden, and lane-specific parameters are refused. This is unusually detailed behavioral disclosure.

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?

Front-loads the core action, then splits behavior into ON ENGINE 6.0+ and ON PRE-6.0 blocks, which is sensible structure. It is dense and jargon-heavy (Savi, exec, clones, rail) but nearly every sentence conveys a behavioral fact rather than filler.

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 7-parameter, no-annotation mutation/sync tool with no output schema, the description covers the behavioral surface an agent needs: lane differences, refusals, mutual exclusivity, and read-only vs write semantics. Return-value shape is left implicit, though 'colliding paths named' hints at it.

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% and the schema already documents each parameter, but the description adds cross-parameter semantics beyond it: version and updateSlug mutual exclusivity in effect, mode/version/updateSlug/applyLocal being 'document-lane concepts' refused on git lanes, and applyLocal defaults differing per pull type.

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 'Take upstream's work into your project' states a specific action (pulling/syncing upstream) and the description distinguishes two engine lanes clearly. It is distinguishable from spawn_push through the mention of 'a refused push,' though it never names the sibling tool directly.

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 concrete when-to-use cues: 'pull before you build and again after a refused push,' and 'use after version_conflict'; non-head pulls are read-only unless applyLocal. It stops short of explicit when-not-to-use framing or naming sibling alternatives.

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