Summer Engine: MCP server, CLI and skills

---

Install

• Start a game now (Node 22+): npx -y summer-engine@latest dev. It asks before it installs the Summer Engine app (about 660 MB, free) when it is missing, creates a starter project here (in ./my-game when this folder has other files) and opens it, ready for your agent. No sign-in needed to build.
• Chat apps (Claude, ChatGPT, Cursor…): add https://mcp.summerengine.com/mcp. Nothing to install.
• Homebrew: brew install summerengine/tap/summer
• npm (Node 22+): npm install -g summer-engine

CLI only (summer-engine 4.2.0 or newer), no MCP server: summer setup --cli. summer ops search "publish my game" finds any operation, signed in or not.

Connect

Cloud work: https://mcp.summerengine.com/mcp. Nothing to install. Add the URL to your agent and sign in to your Summer account once. Your agent then makes assets (images, 3D models, motion, sound effects, music, voices, video), searches and downloads your Summer asset library, plans games, and runs your projects, the store, publishing, prices, analytics, A/B tests, your team and Studio. It has no engine tools: for those, use the local server below.

Engine work: npx -y summer-engine@latest setup --yes (needs Node 22+). It writes the local server (summer mcp) into your agent’s config with the skills. The local server drives the Summer Engine app on your machine: build scenes, write scripts, play the game, take screenshots, read errors. After summer login it also runs every cloud operation, so your agent needs one server. Or paste the prompt in Get started and your agent does every step.

CLI only (summer-engine 4.2.0 or newer): npx -y summer-engine@latest setup --cli --yes. No MCP server: your agent runs Summer as commands in its shell. Setup installs the skills for your agent, with summer-cli, the guide to the commands, and writes no MCP entry. Your agent signs you in with summer login, finds an operation with summer ops search "" and runs it as summer -- , with --dry-run, --wait and --json. Engine commands (summer engine …) drive the Summer Engine app on your machine. Each skill ends with a table of the command for every tool it names. Add --assets-only for only the asset skills. --no-mcp is the same as --cli.

ChatGPT and Claude’s connector directory use two reviewed store versions with a fixed tool list: https://mcp.summerengine.com/chatgpt (games, assets and generation; no publishing, no billing links) and https://mcp.summerengine.com/directory (the store, publishing and Grow reads; no image, 3D, audio or video generation). They keep their 3.x tool names and have no summer_search or summer_call. For everything else, use /mcp.

What this is

Summer Engine is the game engine built for AI. This repo connects your AI coding agent (Claude Code, Cursor, Codex, Copilot and many more) to it: the agent builds a whole game in the engine, tests it, publishes it to summer.games and reads how players play it.

This repo is not the engine itself. The CLI downloads the Summer Engine app for you.

With Summer installed, your agent can:

• Build real games: scenes, scripts, physics and UI, through live MCP tools.
• Build multiplayer games on Summer’s own networking: matchmaking, parties, leaderboards, player data and world saves.
• Add analytics to the game and read it back: store page views, launches, play sessions, play time and your own events.
• Publish games to the summer.games store: the store page, art, the build, a private preview link and the release. Summer’s automatic checks run before anything goes live; staff review games afterwards.
• Use proven recipes: skills, templates and references, all searchable through one index.
• Check its own work: play the game, take screenshots, read the debugger, press real keys.
• Resume any project: .summer/ project memory lets a fresh agent pick up where the last one stopped.

You decide what your agent may do

Studio > Settings > Agent permissions has six switches. They apply to every app you connect, like Claude or ChatGPT. These defaults apply now. You can change them soon. Until then, Summer Games still asks the game’s owner before an agent publishes, and price, A/B test and member changes ask you first.

When a switch is off, the agent asks you first. It gives you a link (https://www.summerengine.com/studio/approvals/), and an open Studio tab shows the request with Approve and Decline. Nothing changes until you approve. The agent always asks before it changes agent permissions or auto top-up, enters a jam, or changes the analytics event limit. Studio > Settings > Agent activity lists what agents changed or asked for, newest first, with Undo for prices, sales, country prices, member roles, team names and the event limit.

Generation and paid builds spend your Summer credits. Turn on auto top-up in Studio Billing: when your credits fall below an amount you pick, Summer adds the amount you choose, up to a monthly limit you set. Agents can never change auto top-up on their own. When credits run out, your agent gets the error no_credits with one link: https://www.summerengine.com/studio/credits.

Summer never installs software without your explicit confirmation. Library entries are structurally prevented (by a capability lint in CI) from instructing agents to touch the network, credentials, or package managers.

Get started: one prompt

Open your AI agent (Claude Code, Cursor, Codex, Copilot, Devin Desktop, etc.) and paste:

Install Summer Engine and let’s make a game. Read github.com/summerengine/summer, check what I already have installed, install whatever is missing, and open a starter project so we can start building.

The agent reads this README, checks what is already on your machine, and runs only the missing steps in its shell.

The first run will:

1. Fetch the summer-engine npm package (~2 MB) through npx.
2. Install Summer’s game-dev skills into ~/.claude/skills/ (or your agent’s user-skill directory) so the agent loads them next session.
3. Run npx -y summer-engine@latest dev: download the Summer Engine app (about 660 MB) if it’s not installed, create a starter project and open it in the engine.

Building needs no sign-in. Your agent asks you to sign in only when you first use Summer’s cloud (generating assets, publishing).

Agents with no shell (Claude Desktop, chat apps with the local server) do the same through the MCP: summer_projects_create_local writes the starter project and summer_projects_open_local opens it, after you say yes to installing the engine.

In most agents (Claude Code, Codex, Cursor, GitHub Copilot (VS Code, CLI, JetBrains), Zed, Cline, Kilo Code, OpenCode, Devin Desktop, Antigravity, Kiro, Trae, Warp, Goose, Hermes, Crush, Amp, Factory, Junie, Qwen Code, Kimi Code, Grok Build and Mistral Vibe), setup also connects Summer Games (summer-games), so the agent can see your friends, start parties and send messages as you. You sign in once; setup prints the step for your agent (Claude Code: /mcp, choose summer-games; Codex: /mcp login summer-games; Cursor: Connect next to summer-games in its MCP settings). A summer.games page opens in your browser; sign in and choose Allow.

Then ask the agent to build something.

Claude Code: the Summer plugin

In Claude Code, type:

/plugin install summer --marketplace summerengine/summer

Then type /summer:start. It gets a first game playing in about five minutes, with one OK from you and no sign-in: from a template that already plays, or from a plan of concept art Summer draws for your idea right in the chat, built in the Summer Engine desktop app. The plugin brings Summer’s skills and two MCP servers: summer-engine drives the desktop app (needs Node), and summer-cloud is Summer’s hosted server (sign in once with /mcp). Use the plugin or summer setup claude-code, not both: they install the same skills.

Only want assets?

Sound effects, music, voices, images, 3D models, motion and video are made on Summer’s servers, so you do not need the Summer Engine app for them. The quickest way is the hosted server in Connect: no Node, no install. To get the asset skills too, paste this instead:

Connect Summer to this agent so I can make game assets. Read github.com/summerengine/summer, connect yourself to Summer and log me in. Skip the Summer Engine app and the starter project, I only want assets.

The agent installs the asset skills and the MCP config (summer-engine 4.0.0 or newer) and signs you in. It does not download the engine. Each asset lands in your Summer library as a normal file: GLB for 3D models, PNG, JPG or WebP for images, MP3 or WAV for audio, MP4 for video. The agent saves each file into your project (your engine’s asset folder, or the folder you name), so any engine or web app can use it.

---

AGENTS READING THIS: install playbook

---

The lifecycle: create → test → publish → grow

These are operations on the hosted Summer server; the local server runs them too after summer login.

How agents call Summer

Every capability is an operation named .: assets.generate_image, store.publish, pricing.set_base.

• Direct tools cover the common jobs: summer_ plus the operation name, with _ for . (games.list is summer_games_list). Engine tools keep their 3.x names (summer_add_node, summer_run_script, summer_play, summer_screenshot), and makers keep summer_tool_.
• Everything else: summer_search finds the operation for a job you describe in words and returns its exact input. summer_call runs it: {op, input, dryRun?, idempotencyKey?}.
• One answer shape: done with a result, running with a job (summer_jobs_wait waits up to 50 seconds per call), needs_approval with a link for you, dry_run with a preview, or an error with a code, a message and exactly one next step.
• Safe to try: every change takes dryRun: true (it changes nothing and spends nothing; a spend shows your own credit estimate) and an idempotencyKey, so a retry never runs twice.
• Error codes: invalid_input, not_signed_in, forbidden, not_found, conflict, idempotency_conflict, in_progress, rate_limited, no_credits, over_limit, engine_not_running, engine_lacks_op, unsupported, not_in_profile, moved, outcome_unknown, unavailable, internal.
• 3.x names keep working for all of 4.x: summer_call accepts them on every server, summer mcp --toolsets legacy lists them on the local server, and the local server lists them by itself while your installed skills are older than 4.0. Its first start after an upgrade refreshes the Summer skills you installed, so after an upgrade the legacy list stays off unless you ask for it. The map from old names to operations is registry/operations/legacy-names.json.

The same operations run from a shell: summer -- (for example summer assets generate-image --prompt "a cozy pixel-art tavern" --aspect-ratio 16:9), with --dry-run, --wait (follows a job or an approval to the end) and --json (prints the answer only; exit code 0 for any ok answer, 1 for an error). summer whoami shows who is signed in. summer ops search and summer ops describe find an operation and its input. Every command that reads something takes --json.

What’s in this repo

summer/
├── README.md          # you are here: overview + the install playbook
├── AGENTS.md          # the agent guide: trust, the library, navigation, engine rules
├── src/               # the Summer software (TypeScript)
│   ├── core/          #   shared implementations (capabilities used by both CLI and MCP)
│   ├── cli/           #   the `summer` command surface
│   ├── mcp/           #   the MCP server and tool adapters
│   ├── project-memory/#   .summer/ read/write
│   └── installer/     #   agent detection and config writing for every supported client
├── library/           # the Library: tools, skills, templates, references
├── registry/          # schemas + generated/ (the compiled index everything reads; never hand-edited)
├── evals/             # evidence the library works: routing, skills, examples, templates, tools, end-to-end
├── integrations/      # one folder per supported agent: what gets installed where
├── commands/          # the shipped slash commands (/summer, /gameskill, the plugin's /summer:start)
├── hooks/             # lifecycle hooks: session-start orientation, opt-in pre-commit doctor
├── assets/            # files the tools ship with: offline API docs, engine-side probe and audit scripts
├── scripts/           # generate-registry (the compiler), validate-library (schema + capability lint)
├── tests/             # v2 prose behaviour specs (the code tests sit next to the code in src/)
├── docs/              # development guide, migration notes, design contract
└── .claude-plugin/ …  # plugin manifests for Claude Code, Codex, Cursor and Factory (generated)

One rule ties it together: every entry is described once (a resource.yaml in library/), and the registry compiler generates everything else — the searchable index, every agent plugin manifest, the skill installer data, counts, and legacy aliases. CI fails on any drift. See docs/design/CONTRACT.md.

The library

Six kinds of entry, all searchable through the same generated index:

• Skills — how to do something well (FPS controllers, scene composition, debugging discipline, VFX recipes, audio direction…). Open Agent Skills format, so any conformant tool picks them up.
• Examples — proven working instances with required evidence (screenshots, verification receipts) — an example that can’t show it works doesn’t ship.
• Templates — complete project foundations (platformers, FPS, racing, roguelikes, multiplayer starters…), each pinned to an exact commit with a verified tree digest. summer create fetches exactly that commit, recomputes the digest and refuses on mismatch, then records the pin into the project’s .summer/project.json — never whatever a branch happens to contain today. Two small templates (3d-basic, empty) are built in and generate offline. Browse with summer list templates; pinning rules and the digest formula in library/templates/README.md.
• Collections — curated, compatible creative materials: asset sets with style rules and presets. None ship yet.
• References — facts: engine version compatibility, GDScript style, tool references.
• Tools — the executable capabilities themselves, described in the same registry so agents can discover what they can do.

Agents don’t browse folders; they search the compiled index (registry/generated/index.json) through summer_docs_search (or summer tool search-library) by summary, use-cases, and facets, then load the hit with summer_docs_read. IDs are permanent, so feedback and evidence follow an entry across any reorganization.

The ecosystem

 Claude Code · Codex · Cursor · Gemini · Copilot · OpenCode · …
        │            (any AI coding agent)
        ▼
 ┌──────────────────────────────────────────────┐
 │  Summer (this repo, npm: summer-engine)      │
 │  library · registry · MCP tools · CLI        │
 │  project memory (.summer/) · evals           │
 └──────────────────────────────────────────────┘
        │ MCP / local API
        ▼
 Summer Engine (desktop app: editor + runtime)
        │
        ▼
 summer.games store · your players

Summer works with any agent: integrations/ adapts one generated system to each. The map of what gets installed where is integrations/README.md.

Project memory: .summer/

Every Summer project carries its own memory, as readable Markdown and JSON:

• GameSoul.md — the game’s promise, written at brainstorm, read by every build skill.
• memory/ — locked facts that must not drift: character voices, world canon, provider bindings.
• project.json — the template pin (id, version, repo + commit + tree_digest, or builtin: true), the toolkit_version that scaffolded it, and created_at: exactly which template, at which commit, started this project.

The point: a fresh agent — any agent, any session — can answer what game is this, what’s done, what’s verified, what’s next without the original conversation. Inspect it yourself with summer memory.

Bring your own skills

Two ways to extend Summer with your own material:

1. Drop skills into your agent the normal way (~/.claude/skills/, .cursor/rules/, etc.) — Summer’s skills are standard Agent Skills format and coexist with yours.
2. Give them to Summer (planned): external Summer-format resources will install project-, user-, or studio-scoped and be recorded in .summer/project.json, so every agent on the project sees them. The schema side is in place — external entries are namespaced (//) and can never silently shadow an official ID — the installer is not built yet.

Official entries land in this repo by PR, gated by schema validation and the capability lint.

Library feedback

• Agents can report how an entry worked (summer_call with docs.feedback): worked / worked with fixes / wrong / outdated / incomplete / did not apply / misrouted. What is sent, in full: the entry ids, one outcome word each, an optional note and deviation (280 characters max, about the entry), the engine version, the agent’s self-reported model id, this CLI’s version, the host app name/version, a random per-process session id, and — only when logged out — a random install uuid (when logged in, the account token is sent instead). The schema cannot carry your code, files, or chat. The very first call on a machine sends nothing and returns a notice; SUMMER_NO_TELEMETRY=1 or DO_NOT_TRACK=1 turns it off entirely.
• Today those reports land in a write-only mailbox that maintainers read. Only verified outcomes count; popularity never ranks an entry.

Telemetry

Summer sends a few usage lines so we can see which tools and commands work, in which agent apps. It never sends prompts, code, file contents, file paths, project names, tool arguments or results, or anything you typed. Turn all of it off with SUMMER_NO_TELEMETRY=1 or DO_NOT_TRACK=1.

The first summer command on a computer (any command, summer mcp too) prints this notice once, to stderr:

Summer collects usage data to improve its tools: which commands and tools run, whether they worked, and which agent app ran them.
No prompts, code, file names or project names. Opt out: SUMMER_NO_TELEMETRY=1
Details: https://github.com/summerengine/summer#telemetry

Every line goes to /api/mcp/log-local-call on the Summer server. Every request also names this package’s version in a header.

Fields a tool call or command adds when they apply:

The library feedback mailbox is separate and described above. Requests to Summer’s servers (generation, assets, the store) also name your agent app, its version and the tool in headers; the same two variables remove them.

What gets downloaded

We tell you before we touch your disk.

Not downloaded, not collected:

• No telemetry beyond what Telemetry lists. Diagnostics stay local.
• No silent engine updates. summer install checks the installed version and asks before replacing it (or needs --yes); nothing updates the engine behind your back.
• No model weights. AI generation runs in Summer Engine Studio (cloud), never on your machine.

What’s open and what’s not

Publishing to summer.games, multiplayer hosting, matchmaking and Grow are live.

CLI reference

Agents: claude-code, claude-desktop, codex, cursor, windsurf, antigravity, cline, cline-cli, kilo-code, github-copilot, vscode-copilot, visual-studio, copilot-jetbrains, opencode, zed, kiro, goose, hermes, trae, qwen-code, kimi-code, crush, amp, factory, junie, warp, rovo-dev, qoder, grok-build, mistral-vibe, lm-studio. Legacy (still accepted, warn on use): gemini, roo-code. Aliases: devin/devin-desktop → windsurf, agy → antigravity, droid → factory, copilot → github-copilot, vscode → vscode-copilot, kilo → kilo-code, qwen → qwen-code, kimi → kimi-code. Scopes: --scope user (default), --scope project.

Contributing

The library grows by PR, and CI holds the line:

1. Report a bad entry. Open an issue quoting the prompt and the response — or, if you’re an agent, file docs.feedback through summer_call after a verified failure.
2. Improve or add an entry. Add library/// with a resource.yaml (plus SKILL.md for skills). Run npm run validate:library, regenerate with node scripts/generate-registry/cli.ts, and commit both. Schema, capability lint, and registry parity are enforced in CI.

docs/DEVELOPMENT.md is the contributor guide; docs/design/CONTRACT.md is the rulebook. Testing an unpublished build end to end against the real engine and a real agent: docs/TESTING.md.

Docs

• Agent guide (AGENTS.md) — how agents use Summer, including the verification ladder
• Development guide · v2 → v3 migration
• Design: contract · decisions
• Agent support map · Template pinning · Evals
• Per-host notes: Claude Code · Codex · Cursor · OpenCode

License

MIT for everything in this repo. Summer Engine itself is proprietary. See What’s open and what’s not.

Some process skills (brainstorming, writing-plans, writing-skills, investigating-bugs) are adapted from obra/superpowers, MIT licensed. Attribution is in NOTICE.

Links

• Website
• Download Summer Engine
• Documentation
• Issues
• Support · Privacy policy · Terms