• klyo games
• For developers
• MCP

How to connect it

1. 01

   Accept the terms in a browser

   Go to dev.klyo.pl and accept the developer terms. An assistant will not do this for you, and that is the point: a person signs the agreement.

2. 02

   Add klyo to your assistant

   Easiest: connect in one click: pick your AI (Claude, ChatGPT, Gemini, Copilot, Claude Code, opencode) and we do the rest. Manually: in your assistant's settings add the tool server (MCP) at https://panel.klyo.pl/mcp?profil=gry. You sign in with your klyo account and decide what you agree to, the same way you connect a drive or a mailbox.

3. 03

   Say what you want

   “Publish this game on klyo, the package is at this address” is enough. The assistant provides the ZIP address, the name, the description for players and the age questionnaire answers. Want a leaderboard and a place on the records hub? Say “add the klyo leaderboard” and the klyo_game_sdk tool describes the calls (ready → progress → score) and the score cap.

4. 04

   Look at it and release it

   The game waits in the studio with a preview and a QR code. You play it on your phone and then press “Release to the catalogue”. Only that click puts the game in front of players.

1. 01

   “Fill with your AI” in the New game form

   One button for the whole form. Your AI types the name, tagline, description in English and Polish, genre, controls and play time while you watch the fields fill in live. To change one field, ask in the same chat, for example “make the tagline shorter”, and the form updates right away. You tick the content survey yourself.

2. 02

   “Translate with your AI” in the translations window

   Pick languages with the buttons in the window; the missing ones are already selected. You can add more later in the chat, for example “now German”. Every translation lands in the “Translations” window as a proposal: you check it and press “Approve”. Google only counts text a person approved.

3. 03

   “Write with your AI” on your creator card

   Your AI writes “about me” and the tagline under your name only from your games. It shows you the text and saves it only after you agree.

4. 04

   The window checks the connection

   After the click the window says whether your AI is connected to klyo, using the same list as the connections page. Connected: a ✓ and the “Open in Claude” or “Open in ChatGPT” button. Not connected: “Connect klyo to your AI” comes first. You do it once.

Working in Claude Code, Cursor or VS Code? Press “Copy the instruction” in the window and paste it there. The tools are the same.

• You do not have to take our word for it. The entry is public and anyone can check it, together with our server address and the page you are reading.
• Your client can find us on its own. Tools that read the registry will suggest klyo when you ask about publishing a game, with no address hunting.
• The name is permanently ours. pl.klyo is our namespace in the registry; nobody else can publish under it, because nobody else controls our domain.

Checked on 23 September 2026 in each service's own documentation: Playgama, AIGameShare, Playfrog. Those services change their rules without notice; if something no longer matches, tell us and we will correct it the same day.

What else the tools can do

Fields and rules: the same as in the studio

The assistant fills in exactly what a person clicks in the studio. Limits live in the tool schema (a gate before the call), and the server checks them again and answers with an error code that points at the field.

Which AI clients work with klyo

Today's state, from our sign-in log, not from promises. If your client does not get through the sign-in, connect it with a key: the same address, the same tools.

• ChatGPTworks

  Sign-in through klyo (OAuth) on a paid ChatGPT plan, in the browser, with developer mode on.

• Claudeworks

  Sign-in through klyo (OAuth), on the web and in the apps. Custom connector: paste the address and leave the OAuth client fields empty.

• Your own program or agentworks

  A key from dev.klyo.pl in the header Authorization: Bearer klyo_sk_…. No sign-in window.

• Claude Code, Codex, Cursor, VS Codenot yet verified

  They support remote MCP servers with sign-in, but nobody has gone through the whole flow with them on klyo yet. If the sign-in does not start, use a key.

Did your client stop at the sign-in? The server then answers invalid_request with a description. Generate a key and send it in the header: it works in every client that lets you add an HTTP header.

Your own agent: a key instead of a login

Claude and ChatGPT sign in to your account themselves. If you are writing your own agent or script, you get a key and send it in a header. The same path and the same tools, without the login window.

1. 01

   Generate a key in the studio

   At dev.klyo.pl, under “MCP and key” → “Key for a program”, press “Generate a key” and then “Check”: you will see how many game tools your program gets and whether it has connected yet. We show it once, so save it straight away. The key starts with klyo_sk_ and you can revoke it at any moment.

2. 02

   Send it when you connect

   The header Authorization: Bearer klyo_sk_… against https://panel.klyo.pl/mcp?profil=gry. Your agent sees exactly the tools Claude sees, not one more.

3. 03

   Watch what the game does

   Once the preview is open, call the diagnosis. You get the files the game asked for but are missing from the package, and the errors from the browser, instead of guessing from a white screen.

Example: asking for a diagnosis

curl -s "https://panel.klyo.pl/mcp?profil=gry" \
  -H "Authorization: Bearer klyo_sk_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"klyo_game_diagnostics",
                 "arguments":{"slug":"lumina-thief"}}}'

Your browser is the eye

We run no browser farm and need none. The game runs on your machine, and our sensor inside the preview page reports what broke. Your assistant sees exactly what you would see by opening the game yourself.

1. 01

   Open the preview yourself

   Playwright, plain Chrome or a phone via the QR code. Append ?s=your-marker to the address (any 1–24 characters).

2. 02

   Actually play

   Click, drag, wait for the second screen. The sensor collects exceptions, failed files, console output and whether the game started at all.

3. 03

   Ask for the diagnosis

   klyo_game_diagnostics with sesja set to your marker. You get ONLY the errors from your run, plus the count of other people's, so nothing disappears quietly.

Order matters: asking before the game runs returns an empty answer, because there was nothing to collect.

Your assistant plays your game on your device

An assistant in a chat has no screen, so until now it knew your game only from error lists and thumbnails. Now it can play it: it presses keys, clicks, taps and drags, and after each run of moves it gets screenshots and the game state. The game runs in the studio open on your side, on your graphics card, so your assistant also sees 3D games our server cannot display. The klyo server does not draw a single pixel; it only passes the moves along.

1. 01

   Open the studio

   Go to dev.klyo.pl on the computer or phone you want to test on. If your assistant has already asked to play, you see “Your assistant wants to play …” right away (the request waits 10 minutes).

2. 02

   Click “Allow”

   From then on your assistant may play on this device. The game opens in a small window in the corner of the screen, full screen on a phone, and you see every move.

3. 03

   Your assistant plays and looks

   It sends up to 40 moves at a time on one timeline of up to 3 seconds, also at once: run, turn the camera, jump. It gets back up to 4 screenshots, whether the game started, the score and how smoothly the game itself runs.

4. 04

   Stop it whenever you like

   “Stop” in the game window or “Turn off” on the bar ends it at once. Your assistant's next request asks for your permission again.

• Only your games. Your assistant opens only your account's games: the workshop version or a waiting package under its preview address, otherwise the version players have.
• Screenshots stay in the chat. They go only to the chat that asked for them. We do not store them in a database or on disk; they wait in server memory for at most 10 minutes, so a retried call does not play twice.
• Moves like a player's, with one catch. The game gets keys, clicks, taps and mouse movement as if from a person, but the browser marks them as untrusted. Full screen and sound therefore wait for your click, and pointer lock for mouse-look games is simulated.
• The game needs the klyo SDK. The SDK from games.klyo.pl/sdk/klyo-gry-sdk.js runs the moves. A game without it, or with an old copy in the package, answers “no SDK”, and your assistant says what to replace.
• One run at a time. One call at a time per account, up to 600 an hour. A studio tab in the background pauses the game, so keep it visible next to the chat.
• Errors from this run. Each session has its own sensor tag, so klyo_game_diagnostics with sesja shows only the errors from your assistant's play.
• When the quality gate says it has not seen the 3D graphics yet. Our server measures games without a graphics card, so it cannot see a 3D game and will not give it a green light. Then the picture from your device shows your assistant whether the game works, and the release decision is yours, as always.

Step-by-step guide for developers, with the button names from the studio

A package from disk, without exposing the game

Do not open a tunnel and do not put an unreleased game on public hosting. The klyo_upload_package tool hands the assistant an upload pass (a token valid for one hour that opens nothing but sending files to your account) plus the list of packages already waiting with us without a game. An assistant with a shell (Claude Code, Codex, Cursor) sends the file itself in two requests; an assistant in a chat (claude.ai, ChatGPT) asks you to drop the ZIP in the studio: the package lands in the waiting room, nothing gets published, and it picks the number from the list. The short version is below.

1. 01

   Announce the file

   POST /api/upload/init with the header Authorization: Bearer <pass> and { filename, total_size, content_type } → you get upload_id and chunk_size.

2. 02

   Send the bytes

   PATCH /api/upload/<upload_id> with the same pass, Upload-Offset and Content-Type: application/offset+octet-stream. Up to 32 MB in one request; bigger files in chunks. To resume, HEAD tells you how much we already have.

3. 03

   Publish or update

   klyo_publish_game or klyo_update_game with upload_id instead of zip_url.

Keep the public ZIP address for a game that really is online already, for example when moving from itch.io.

The game production standard: the assistant knows the minimum before writing code

An ordinary person tells their assistant “I want a battleship game”. An assistant connected to klyo first calls klyo_game_requirements and receives the contract: phone, tablet and computer; touch, mouse and keyboard; portrait and landscape reacting to resize; audio that recovers after returning from the background; save, leaderboard, pause and one-gesture retry; one palette and one style; no third-party brands and no third-party ads. It does not ask the user about any of it, it builds at that level from the start. Version 1 of the standard is frozen since 23.09.2026: a new requirement is added only when a real game on klyo runs into a real problem.

1. Testing on the creator's machine, not on our server. The assistant downloads games.klyo.pl/sdk/klyo-test.mjs and runs it locally: four screens, scrolling, screen fraction, text, touch listeners, size, time, exceptions. Before a release it adds --slaby-telefon --jezyki: a cheap phone and both languages. The result has krytyczne (critical) and ostrzezenia (warnings), so it fixes and re-tests in a loop until it passes. The heavy work happens on the creator's computer; klyo measures at upload and at release with the same file.
2. Quality gate, also for packages uploaded by hand. Every package in the waiting room is measured on four screens right after upload; klyo_game_diagnostics and the studio preview show the same bramka: exceptions, missing files, third-party ads, no SDK, no touch and scrolling block a release as “finished” (demo and “in development” pass); small screen, small text, size, no leaderboard and third-party brands need a reason.
3. Release stages. Local → preview (g-podglad-…, outside the catalogue and Google) → publication with stage w_budowie / demo / gotowa → a new version with its own preview while players keep the old one, the previous version stays for restore. A human approves two moments: publication and releasing a version.

A new version of your game: through the assistant, the same as in the studio

Three steps, the same as the “New build” and “Release” buttons in the studio. The assistant does not guess what changed: we measure it from the files and tell it what that means for the clip. You record the clip for the new version yourself: in the studio, after the release (the recording window opens by itself for a new look or feature).

1. 01

   Upload

   klyo_update_game with slug and upload_id (a file from disk) or zip_url. The game in the catalogue does not change right away: the new version waits in the waiting room under its own preview address. The answer: zmiana (code / look / sound in %, new files and strings, podpowiedz: poprawka | funkcja | interfejs), adres_nowej, wyrok and dalej.

2. 02

   Play

   This is your check, not the assistant’s: open the preview address, ideally on your phone. The studio shows the same version in the game window with the track “version → play → release → clip”.

3. 03

   Release

   klyo_release_version with slug; skip zmiana (we take the measured one) or pass it when you know better; nowosc is one sentence for the feed with a new feature. Before the swap the whole new version goes through the check once more. Players get it right away (whoever is playing chooses: update or finish the round), the previous one stays with us, the game page rebuilds, and we measure the screens once, after the release. Followers get a notification when the game is in the catalogue.

What it means for the clip: a poprawka (fix) keeps the clip; a funkcja (feature) keeps the clip and “what is new” goes to the feed as “New”; with an interfejs (new look) the old clip comes off the tile and the feed until you record a new one in the studio.

Fix without a ZIP: the game workshop

Your assistant reads your game's files and edits them here, without a package from you. It works with a game in the catalogue and with a package waiting in the waiting room. Players keep the version they know until the end: the edits go to a workshop, a new version next to it with its own preview address. You release it the same way as any new version.

1. 01

   Start from scratch if there is no game yet

   klyo_game_patch with nowa (plansza, zrecznosciowa or logiczna) creates a package from the Klyo Kit skeleton right in the waiting room and writes the gameplay in the same call. An assistant in a chat, with no disk and no ZIP, has its own game at a preview address from that moment.

2. 02

   Read

   klyo_game_files with the game's slug or the package's upload_id. Without path you get the file list with a hash for each file, with path the file's content (up to 200 KB at a time, continue from from_line), and with changes: true what differs from the version players have.

3. 03

   Edit

   klyo_game_patch with a list of edits: an exact old_string replaced by new_string, a whole file in content, or delete: true. For a file that exists you pass expected_hash from your read: if someone changed the file in the meantime, nothing is saved. The edits of one call go in all together or not at all. The first edit opens the workshop, and the studio shows it straight away as “New version is waiting”.

4. 04

   Play and check

   The preview address comes back in the answer. Open it (a phone is the best test), and klyo_game_diagnostics shows the errors, missing files and check results of this very version, not of the one players have. An assistant without a browser passes zmierz: true: we open the preview for it and return the errors and thumbnails of four screens at full addresses, so it sees what the game looks like. Files unchanged since the last measurement do not start the browser again; one measurement at a time per account, six an hour. Your assistant can also play it itself, on your device: klyo_game_play, described above.

5. 05

   Release

   A game: klyo_release_version or “Release” in the studio. A package from the waiting room: klyo_publish_game publishes it together with the edits. Before the swap the whole game goes through the check once more.

• The version players have does not change. The workshop is a copy next to it and every save creates a new file, so what players download does not change for a moment.
• Text in the conversation, files by ticket. An edit's content writes text files (html, htm, js, mjs, css, json, svg, txt, xml, webmanifest). An image, sound, font or big file (up to 20 MB) the assistant sends with the klyo_upload_package ticket and passes in from_upload: no base64, and the start of the file has to match its extension.
• The same check as at upload. Every changed file is checked straight away: malicious code, third-party ads, nothing from outside klyo. A refusal saves nothing.
• Limits. A file up to 1 MB, one call up to 256 KB and 20 edits, three open workshops per account and one per game, up to 300 edits an hour. Releases, rollbacks and new packages up to 10 an hour: each one starts a screen measurement, and there is one measuring browser for all developers.
• Tidiness. A workshop with no changes for 7 days expires, and the version players have stays untouched. A preview nothing points to any more disappears after 7 days. Preview addresses stay out of Google.
• A trail. Every edit is written to your account's log: the file, the hash before and after, the size.
• Undo while you work. Before every edit we save a point auto-N (it is in the answer), and the assistant can name its own with checkpoint. revert goes back to any point, discard drops the whole workshop. This is not a release rollback: players see none of it.
• A weak phone before release too. At upload and at release we measure the game once more on a phone with the processor slowed down four times and a network like weak 3G: smoothness, stutters, memory and time to the first frame. Below 15 frames a second the game will not pass the gate as finished. An assistant without a browser orders the same measurement before a release: klyo_game_diagnostics with zmierz and pelny.
• In every language of the game. Klyo Kit speaks ten languages (Polish, English, German, French, Spanish, Portuguese, Italian, Russian, Ukrainian, Turkish), and the game speaks those it has its own texts for. We open the same phone in every declared language, with a thumbnail. A key instead of a word and a declared language the game does not show block the release; English in place of a translation, a sentence identical to the English one and text that does not fit its button or runs off the screen are warnings. Text drawn on a canvas you check on the thumbnails side by side.
• Slow frames with a cause. The frame count alone does not say whose fault it is. We measure separately the time of the game code in each frame, the browser's work and how much of the picture really changes. Slow code is niski_fps; light code with slow drawing is wolne_rysowanie, with advice on what to draw once and what every frame.
• Security. We open game code on our side only in an isolated browser with no access to our internal network. A game at its own address cannot act on behalf of a signed-in player either.

Premium quality review: seven points before a release

The quality gate catches errors, but it cannot tell whether a game looks cheap. So before the assistant publishes a game as finished, or releases a new look or feature, it goes through seven points and gives evidence for each: what exactly it did. We do not judge taste and we run no model of our own. We match the declaration against traces in the code and show you in the studio the points the code does not back up, before you click “Release”.

• Art direction: one visual direction: one palette, one style, scene and elements from one skin, no bare rectangles.
• Animation: every change of state has a transition, there is a win and a loss animation, and motion turns off for people who ask for that.
• Sound: a sound for every action and every result, mute in the settings, sound back after returning from the background.
• Feedback on every move: an answer to every action within 100 ms: picture, sound, vibration on a phone; it is clear whose move it is and why a move is not allowed.
• Light and dark theme: both variants following the device setting, plus a switch in the game.
• Languages: every text from a translation table, at least Polish and English, every declared language checked on a phone (not needed for a game with no words).
• Online: invite by link, waiting for the opponent, coming back after a disconnect, a rematch in one gesture (not needed for a solo game).

Leaderboard: a game that declares a score (wynik_max) but does not send it with klyo.score will not pass the gate as finished. A game with no points gives the reason in its description. The review can be skipped for a demo and a game in development, and for a plain fix (zmiana: "poprawka") too.

Common questions