mcp

MCP server that exposes game-asset generation to AI agents: characters with animation sets, weapons bound to hand bones, seamless textures, terrain and map layouts, VFX, HUD kits, and playable game kits assembled from modular capabilities. It's built for developers driving Claude Code, Cursor, Windsurf, VS Code, or any other MCP client who want assets landing in their repo rather than a chat window. Python, with tools covering the full pipeline from prompt or concept image through rigging, engine-specific snippets for Unity, Godot, Unreal and Three.js, and a searchable asset Library.

Features

Character work

• Text-to-3D or concept-image-to-3D — pass a picture and the T-pose sheet is built from it instead of inventing a character.
• Boss and enemy kits ship with stats, phases, attacks, arena and engine snippets together.
• Clip packs can be applied to existing Mixamo-style characters, retargeted between skeletons, or re-based to an arms-down rest pose while weapons stay on the armed bind.
• Hitbox output — body capsules and per-weapon volumes derived from a bind or a full loadout.

Attaching props

// Request shape (paths or Library ids)
{
  "character_id": "lib_...",
  "prop_id": "lib_...",
  "style": "melee",        // melee | gun | shield | staff
  "export_glb": true       // writes attached.glb into out_dir
}

Second held items are supported for off-hand props, and an existing armed bind can be reused as the character for the next attachment.

Level, map and world building

• Room graphs generated from a prompt, walkable AABB navmesh, lights and fog.
• Top-down FPS/bomb layouts with spawns, A/B sites, lanes and walls; sagging electrical spans for dressing.
• Reference-photo workflow: collect, graph, greybox, zone, camera-match, dress.
• Shader catalog browsing and per-engine source pulls into the repo with an assignment snippet.

Game kits, modular gameplay

• Search the catalogue by text, capability, tag or engine target; inspect manifests, config schemas and dependency trees.
• Install, remove, configure and update kits with automatic dependency resolution and a lockfile.
• Delivery produces engine bundles with planned actions, local backups and a rollback path for the previous delivery.
• Ask what a project already provides and which kits fill the remaining gaps for a goal; get a browser play URL for the current revision.

Client-side authoring helpers

• FPS input map, third-person character-facing logic, and CS-style viewmodel arms + gun kits.
• Loading-page overlays for Godot, Unity and Unreal, with an optional still render.
• Server-side PNG previews so the agent can inspect results without a browser.

Diagnostics

Game FPS, frame timing, CPU/render submission and optional GPU/network latency can be analyzed from an explicitly shared capture or a pasted report — findings are separated from recommendations, and no measurement is ever invented.

Requirements

• Python — the runtime this app is built on; a modern 3.x install is assumed.
• An MCP-capable client — Claude Code, Cursor, Windsurf, VS Code, Grok, or any client that speaks the Model Context Protocol, over stdio or streamable HTTP.
• A GripForge API key — every generation, attach, and Library call is authenticated with it.
• An engine to consume the output (optional, depending on what you generate) — Unity, Godot, Unreal, or Three.js. Assets ship with the binds and snippets each engine expects, so the tool runs without one, but you need it to drop results into a project.
• A writable output directory (optional) — only when a tool writes files into your repository (out_dir, defaulting to a per-tool folder such as ./gripforge-hud or ./gripforge-library).

Client configuration shape

Every MCP client expects the same triple; consult your client's docs for where the file lives.

{
  "mcpServers": {
    "gripforge": {
      "command": "python",
      "args": ["-m", "mcp_server"],
      "env": { "GRIPFORGE_API_KEY": "gf_..." }
    }
  }
}

Remote-capable clients can skip the local process and point at the hosted endpoint with an x-api-key header instead.

Engine targets

Environment variables

Things that are not required

• No GPU or local 3D toolchain — generation and rendering happen server-side; gripforge_render returns previews so the agent can see results without a browser.
• No game engine installed to generate assets — only to import them afterward.
• No hosted account for read-only Library operations beyond your API key.

Configuration

Configuration is driven entirely by the MCP client's server definition. The server reads its credentials and endpoints from environment variables; everything else is per-request.

Environment variables

Keys are read once at startup. Restart the MCP server after changing them.

Client configuration

Any MCP-capable client accepts the same command / args / env triple. Provide the API key through env rather than hardcoding it in a shared config file when possible.

{
  "mcpServers": {
    "gripforge": {
      "command": "python",
      "args": ["-m", "mcp"],
      "env": {
        "GRIPFORGE_API_KEY": "gf_...",
        "GRIPFORGE_API_URL": "https://gripforge.ai",
        "GRIPFORGE_OUT_DIR": "./gripforge-output"
      }
    }
  }
}

For remote-capable clients, point at the hosted endpoint instead and send the key as a header:

{
  "mcpServers": {
    "gripforge": {
      "url": "https://gripforge.ai/mcp",
      "headers": { "x-api-key": "gf_..." }
    }
  }
}

Output directory behavior

• Tools that emit files (gripforge_attach with export_glb, gripforge_hud, gripforge_hud_bar, gripforge_cape, gripforge_library_list/pull, gripforge_shader_pull, gripforge_gamekit_deliver_local) write under GRIPFORGE_OUT_DIR unless the tool call passes an explicit out_dir.
• Per-call out_dir always wins over the environment variable.
• The directory is created if missing. Intermediate subdirectories are named after the tool and request so repeated runs stay separate.

Option resolution order

Most tools accept the same value from several places. Settings resolve in this order, first match winning:

1. Per-call argument (for example out_dir, style, polycount).
2. Environment variable (for example GRIPFORGE_OUT_DIR).
3. Server default compiled into the tool.

Precedence notes

• GRIPFORGE_API_URL without a scheme is rejected; include https:// or http://.
• The hosted endpoint ignores GRIPFORGE_API_URL and GRIPFORGE_OUT_DIR; it always operates against the production API and never writes to your filesystem.
• A missing GRIPFORGE_API_KEY fails the first authenticated call with a clear error rather than at startup, so client health checks can still pass.
• Credentials are never written to logs, even at debug level; only the last four characters of the key appear in diagnostic output.

How it works

The server is a thin Python MCP layer in front of the asset API. Your client sends a tool call, the server validates the arguments, forwards the job, and hands the result back into the