bring your own agent

Practice from your own agent.

Claude Code, Codex, pi, crush, omp, qwen — anything that speaks MCP can read the exercises, submit to the same graded sandbox, and see your progress. The whole product, through one URL:

https://blankcode.dev/mcp

1 · Mint a practice token

The key your agent will carry. It can read exercises and submit as you — nothing else: no billing, no settings, no minting more keys. Revoke it any time in Settings.

The snippets below show the shape meanwhile.

2 · Point your harness at it

Streamable HTTP, bearer auth, stateless — no OAuth dance, no callback URLs.

Cursor

{
  "mcpServers": {
    "blankcode": {
      "url": "https://blankcode.dev/mcp",
      "headers": {
        "Authorization": "Bearer bck_…mint-a-token-above…"
      }
    }
  }
}

Put this in .cursor/mcp.json. Take-homes use the same server; load the projects skill so the agent does not write src/.

Claude Code

claude mcp add --transport http blankcode https://blankcode.dev/mcp \
  --header "Authorization: Bearer bck_…mint-a-token-above…"

Codex CLI

# ~/.codex/config.toml
[mcp_servers.blankcode]
url = "https://blankcode.dev/mcp"
http_headers = { "Authorization" = "Bearer bck_…mint-a-token-above…" }

Anything that reads mcpServers JSON (pi, crush, omp, qwen…)

{
  "mcpServers": {
    "blankcode": {
      "type": "http",
      "url": "https://blankcode.dev/mcp",
      "headers": {
        "Authorization": "Bearer bck_…mint-a-token-above…"
      }
    }
  }
}

The field names vary slightly per harness; the three facts are constant — HTTP transport, this URL, this bearer.

Harness cannot send HTTP headers? Bridge over stdio

# any harness that can launch a stdio MCP server (sonar, older CLIs)
- name: blankcode
  command: bunx
  args: ["-y", "mcp-remote", "https://blankcode.dev/mcp",
         "--header", "Authorization: Bearer bck_…mint-a-token-above…"]

mcp-remote speaks stdio to the harness and streamable HTTP to us, carrying the bearer. Same product, one hop longer.

3 · Teach it the etiquette

A skill file that explains the loop to your agent: confirm whose work it is, never claim a pass the sandbox did not grant, and hand recall back to you — an agent pass on a memory exercise is recorded as assisted and leaves the review owed. Your schedule models your memory; that is the whole product.

4 · What a session looks like

Five calls from a real sitting, in order, and exactly what came back — nothing smoothed over.

whoami
→ practicing as you
get_due_reviews
→ 3 due — these are yours; an agent pass on recall leaves the review owed
get_exercise
→ description, starter code, hints — solution and hidden tests redacted
run_tests
→ 2 of 3 passing — feedback only, nothing recorded · iterate and run again
submit_solution
→ the sandbox's verdict is the only verdict · labeled via agent

5 · Run a course from your agent

Paste this into the harness you just connected. It reads the path, walks it exercise by exercise, and stops to talk before anything is submitted.

Prompt

Connect to BlankCode. Call whoami, then list_paths and let me pick one. Walk it in order: fetch each exercise, discuss the approach with me before anything is submitted, check work in progress with run_tests (it records nothing), and only call submit_solution when we believe in it. After every verdict, ask me the reflect questions it returns and wait for my answers — if I cannot explain the pass, we redo it together. Never claim a pass the sandbox did not return.

Paths and tracks are all walkable this way — the catalogue is the course.

6 · What people ask first

Does agent work move my review schedule?: The vibecoding forms, yes — recall stays owed.
Where do I see agent activity?: Your dashboard, labeled — never merged silently.
Do practice runs spend my submissions?: No. run_tests has its own daily budget on free accounts and records nothing; submissions are the verdicts of record.
What can a leaked token do?: Practice as you, nothing else. Revoke it right here — or in Settings.