SteelFrame MCP servers & reference oracle

Drive the real mainframe engine from any MCP client — Claude Desktop, Claude Code, Cursor, a CI harness, or any remote-native connector. Two things you can do with it: write and run COBOL/JCL on the live engine (the developer loop), and use SteelFrame as a reference oracle for a modernization comparison — it returns files, joblogs, screens one keystroke at a time and scheduler cycles, and your harness does the comparing. Two servers, one engine: a persistent lane whose work lands in the shared store, and a private / ephemeral lane with the same tool surface that runs RAM-only with zero retention — one-shot sandboxes for a single answer, RAM-only workspaces for multi-step work including the whole oracle chain.

what it is which lane? setup authentication developer loop reference oracle worked oracle example modernization playbook kit VS Code MCP (your own VS Code) Git MCP (your own GitHub / GitLab) z/OS MCP (your own IBM mainframe) screen MCP (your own open page) pricing live tool reference REST API (same routes) language catalog back to the terminal

What it is

One engine, one route registry, two projections: every REST route that opts in becomes exactly one MCP tool (name, description and input schema are generated from the route — nothing is hand-written per tool, so the catalog cannot drift from the dispatcher). What you do with the tools falls into two uses:

Which lane? Persistent vs private / ephemeral

Both lanes expose the same engine and the same tool surface. The difference is one thing only: where the bytes live. Persistent work lands in the shared store and is web-visible; private work is RAM-only and zero-retention — a single-use sandbox per one-shot call, or a leased RAM-only workspace that survives across calls so a whole equivalence scenario runs inside it and then vanishes.

Setup

Live on steelframe.cobolstack.com: /mcp (server steelframe, both lanes), /mcp/vscode (steelframe-vscode, scope vscode.drive), /mcp/screen (steelframe-screen, scope screen.drive), /mcp/git (steelframe-git, scope connectors.use) and /mcp/zos (steelframe-zos, scope zos.remote). One API key can carry all five scopes (a Custom key); each door is a separate MCP server in your client. The sections below cover each one.

Two doors

Client config snippet

Claude Desktop / Claude Code (mcpServers), Cursor (mcp.json). Point args at your checkout's bridge:

{
  "mcpServers": {
    "steelframe": {
      "command": "node",
      "args": ["/path/to/mainframe/bin/steelframe-mcp.mjs"],
      "env": {
        "SF_URL": "https://steelframe.cobolstack.com",
        "SF_USER": "YOURUSERID",
        "SF_PASSWORD": "YOURPASSWORD"
      }
    },
    "steelframe-private": {
      "command": "node",
      "args": ["/path/to/mainframe/bin/steelframe-mcp.mjs"],
      "env": {
        "SF_URL": "https://steelframe.cobolstack.com",
        "SF_TOKEN": "sf_...",
        "SF_LANE": "ephemeral"
      }
    }
  }
}

SF_USER / SF_PASSWORD are YOUR OWN SteelFrame credentials — no shared account is published. Get a user ID with Get User ID on the logon screen (you choose your own password at first sign-on), then put that userid and password here.

SF_URL is your SteelFrame URL: https://steelframe.cobolstack.com for the hosted estate (the default above). Self-host only: use http://localhost:3270 if you run the engine from your own checkout — there is nothing listening on localhost:3270 otherwise, and the bridge will report connection refused.

Remote client (connector-style): for the hosted estate the door is https://steelframe.cobolstack.com/mcp, header Authorization: Bearer sf_... (or a session token). For a self-hosted plane use https://<plane>/mcp. No MCP client at all? Every tool is an ordinary REST route — the binding (method + path) is shown on each tool in the reference and the same routes are documented on /api.html; e.g. POST /api/mcp/compile with { "program": "HELLO", "lines": [...] } or POST /api/run/batch with { "member": "CARDDEMO.JCL(POSTTRAN)" }. Zowe, or your own app reading JES jobs and spool? SteelFrame also answers the z/OSMF jobs and data set REST interface at https://steelframe.cobolstack.com/zosmf/ (HTTP Basic with your userid and password, or a Bearer API key) — see z/OSMF-compatible REST on /api.html.

Connecting from another computer (remote, no local checkout)

On a different machine — no repo, no node, no bridge process — register the hosted door as an HTTP transport straight from Claude Code. This needs only Claude Code + internet:

claude mcp add -s user --transport http steelframe \
  https://steelframe.cobolstack.com/mcp \
  --header "Authorization: Bearer sf_..."

-s user makes the server available in every folder (drop it for project scope). --transport http selects the remote door; --header carries your bearer token. The sf_... value is a persistent scoped API key — mint one under Authentication below. (Flag names verified against Claude Code's claude mcp add --help; if yours differs, check that help for your CLI version.) Contrast with Door A — stdio bridge above, which runs bin/steelframe-mcp.mjs locally and therefore needs the repo checkout + node.

Authentication — two ways, pick either

datasets.write, jobs.write, db2.exec,
system.read, cics.read
(+ ephemeral.exec for the private lane)

cics.exec        # headless CICS sessions, scripts, LINK
sched.admin      # DEMAND / ORDER / define / import
workspace.write  # create / reset / destroy workspaces
(db2.exec already covers DB2 table dumps)

Use 1 — the developer loop

The persistent lane exposes the whole spine — compile-check, upload, compile+link, run, the raw JES2 job tools, WTOR, and the analysis suite. The private lane collapses this into five one-shot composites. Highlights:

Worked example — compile → run → read logs

Against Door B (POST /mcp, JSON-RPC 2.0). Step 1 compiles; the response carries maxcc, per-step RCs, parsed diagnostics and the load-module dsname:

1. compile_program

   curl -s https://<plane>/mcp \
     -H "Authorization: Bearer sf_..." \
     -H "Content-Type: application/json" \
     -d '{
       "jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{
         "name":"compile_program",
         "arguments":{
           "program":"HELLO",
           "lines":[
             "       IDENTIFICATION DIVISION.",
             "       PROGRAM-ID. HELLO.",
             "       PROCEDURE DIVISION.",
             "           DISPLAY \"HELLO FROM MCP\".",
             "           STOP RUN."
           ]
         }
       }
     }'
   # → { "jobid":"JOB00021", "ok":true, "maxcc":0,
   #       "steps":[{"name":"COB","pgm":"IGYCRCTL","rc":0}, ...],
   #       "diagnostics":[], "loadModule":"IBMUSER.LOADLIB(HELLO)",
   #       "jcl":"//IBMUSERC JOB ..." }

2. run_program — GO deck with STEPLIB <HLQ>.LOADLIB:

   -d '{"jsonrpc":"2.0","id":2,"method":"tools/call",
        "params":{"name":"run_program",
          "arguments":{"program":"HELLO",
            "dds":{"SYSOUT":{"sysout":"*"}}}}}'
   # → { "ok":true, "maxcc":0, "sysout":"HELLO FROM MCP" }

3. read_spool — pull the JES2 log for the compile job (tail-guarded):

   -d '{"jsonrpc":"2.0","id":3,"method":"tools/call",
        "params":{"name":"read_spool",
          "arguments":{"jobid":"JOB00021"}}}'
   # → { "content":"...JES2 job log...", "truncated":false }
   #   (pass "full":true or "tail":<n> for the whole spool)

A compile error comes back honestly — e.g. { "ok":false, "maxcc":12, "diagnostics":[{"line":7, "code":"IGYPS2121-S","message":"'WS-BOGUS' IS NOT DEFINED"}] } — the line number and symbol are parsed from the genuine cobc listing. A program that abends surfaces { "ok":false, "abend":"S0C7", "maxcc":"S0C7" }.

The same loop on the private lane

Point the client at SF_LANE=ephemeral (or POST /mcp?lane=ephemeral). One shot: call compile_and_run with the source, copybooks and data DDs inline — the verdict, diagnostics, RC, SYSOUT and requested output datasets come back in the one response and the sandbox is gone (jcl_inline is the generalization lever for any one-shot batch deck). Multi-step: create_workspace (a RAM-only workspace, seed fresh; asynchronous — on status:"CREATING" poll get_workspace until RUNNING), then the very same upload_source → compile_program → run_program → read_spool with workspace:<id>, then destroy_workspace — identical results, nothing retained.

Use 2 — SteelFrame as a REFERENCE ORACLE for modernization

The workflow

1. Find and export. search_source (content / regex / kind-classified members) and find_program (source, transitive copybooks, load modules, the JCL steps that run it, the CSD slice, mapsets, the scheduler jobs that run those decks) tell you what the estate knows. export_bundle hands it over in one call — programs + copybooks + JCL + procs + BMS (source, parsed model, physical map) + CSD slice + schedule + datasets as hex and copybook-decoded rows; text parts inline, dataset parts paged by get_bundle_part, or the whole thing as GET /api/export/bundles/{id}/download (tar.gz). Nothing is converted.
2. Isolate. create_workspace {seed:'clone', name:'…'} boots a child engine on a copy of the live estate (datasets, CSD, scheduler store; the parent's spool is left behind unless includeSpool:true) — or snapshot:<id> for a reproducible CI baseline, or fresh. Creation is asynchronous: the workspace is registered at once with status:"CREATING" (phase, progress) while the copy and the child boot run in the background, and the call answers as soon as it is ready or after waitSeconds (default 20, max 45 — under a 60 s MCP client timeout). On CREATING, poll get_workspace every 10–15 s until status:"RUNNING"; tool calls with workspace:<id> are refused (409 NOT READY) until then. Never call create_workspace again meanwhile: the same name returns the in-flight workspace (reused:true), a different name counts against your cap (429 naming the one still creating). A failed create shows status:"FAILED" with the error (destroy and recreate). Then pass workspace:<id> on any tool call to run it there as yourself; the live estate never changes. reset_workspace re-baselines it the same asynchronous way (optional jobNumber so JOBIDs line up across re-runs); destroy_workspace when done. On a CREATING one it cancels: the estate copy is stopped at once (a queued copy leaves the queue, a running copy process is killed), no child engine boots and the partial directory is removed; the row shows CANCELLING (or DESTROYING for a running one) and counts toward your cap only until that is done — the call waits for it (up to waitSeconds, default 15) and answers settled:true when the row is gone, else poll get_workspace until 404. A create/destroy loop therefore never queues copies ahead of other users. Inside a workspace every tool is checked against the scopes of the token making that call (not the one that created the workspace): no datasets.write → no write_member inside either; the one extra granted inside is cics.admin to a cics.exec holder, so cics_ceda / cics_cemt / cics_define act as a CICS administrator in your own throwaway copy.
3. Seed. load_dataset puts records in (rows + copybook, or hex with the charset stated): PS replace/append, KSDS replace/append/upsert, ESDS; allocate-on-demand. stage_gdg rolls a new generation through a real IEBGENER DISP=(NEW,CATLG) step. define_cluster for a new VSAM cluster; compile_program {loadlib, syslib} installs a program into the estate's LOADLIB. A mapset is installed by running an inline //S1 EXEC PGM=DFHBMSCP step through run_batch (//SYSIN DD = the BMS source, //SYSPUNCH DD = the symbolic copybook target). Load the same rows into your candidate system.
4. Batch. run_batch {member:'CARDDEMO.JCL(POSTTRAN)'} (or inline lines) submits, waits, and returns the run record: step RCs / abend, the whole joblog keyed STEP.DD, the output datasets (auto-derived from the deck's DDs) as hex + decoded rows, GDG (+1) resolved after the run, optional DB2 tables, an optional identical dump taken before the run (verbatim — no diff), WTORs auto-answered. clock:{fixed:'2022-07-18 10:20:30'} pins the COBOL runtime clock for that job. Persisted as a steelframe-run/1 record (get_run).
5. Online, screen by screen. cics_open_session gives you a headless terminal (the same engine terminal the web and TN3270E use) and its initial screen. cics_send sends one AID per call with fields addressed by BMS field name (or row/col) and returns every screen the engine painted during the step plus the final screen as steelframe-screen/1: named fields + attributes, cursor, keyboard state, 24×80 text (raw:true adds the TN3270E data stream). It settles on the engine's keyboard lock → unlock; task.alive:true means a CONVERSE/RECEIVE is waiting for your next send; 409 while the keyboard is still locked (re-read with cics_screen or type ahead with queue:true). cics_run_script runs a whole step list in one call and returns the transcript + a state dump. Both take clock:{fixed:…} to pin EIBDATE/EIBTIME, ASKTIME/FORMATTIME and FUNCTION CURRENT-DATE for that terminal's tasks only, so a re-run paints the same screens. cics_link LINKs a program headlessly with a COMMAREA (hex, or rows + copybook) and returns the COMMAREA back.
6. Scheduler (CA-7 / Control-M). sched_import takes a real LJOB report or DEFTABLE XML; sched_define_job adds one job with triggers/conditions from JSON; sched_jobs returns the dependency graph as data. sched_demand {job} (CA-7) or sched_order {folder} (Control-M) starts a cycle and returns its id; sched_wait_cycle {id} waits for it to end and returns the cycle log (the order the jobs ran, the triggers that fired), every job's state / jobid / maxcc / steps and joblog, and optional output datasets. sched_ca7_command speaks CA-7's own syntax (RUN,JOB=, LJOB, LQ, LPRRN, POST, …).
7. Pull the after-state and compare on your side. export_state {datasets, db2, spool} is a pure dump of what the mainframe holds right now (hex + rows, charset stated, sha256 per artifact), persisted for get_state. Take one before and one after, or one from the oracle and one from your candidate, and diff them in your harness. decode_records / encode_records convert between record images and JSON rows through a copybook whenever you need to cross the representation boundary yourself.

What comes back

Worked oracle example — CardDemo, Door B

One harness run, JSON-RPC over POST /mcp (every call below is the params of a tools/call). Result shapes are the routes' documented returns, abbreviated. Which door: with a self-service key (Developer preset) run this chain on POST /mcp?lane=ephemeral — a RAM-only workspace needs only ephemeral.exec, which the preset carries; create_workspace on the persistent /mcp needs the administrator scope workspace.write and answers 403 KEY_SCOPE to a Developer key. The same calls, the same results; nothing survives the workspace. A ready-made project that does exactly this, with Claude Code skills and the CardDemo POSTTRAN job ported and tested end to end, is the modernization playbook kit.

1. create_workspace — an isolated copy of the estate:

   {"name":"create_workspace",
    "arguments":{"seed":"clone","ttlSeconds":3600,"jobNumber":1000,"name":"posting-v1"}}
   # → { "workspace":"W1", "seed":"clone", "status":"READY", "jobNumber":1000,
   #       "expires":"..." }        # from here on: "workspace":"W1" on every call

2. load_dataset — seed the daily transaction file from rows + copybook:

   {"name":"load_dataset",
    "arguments":{"workspace":"W1",
      "dsn":"AWS.M2.CARDDEMO.DALYTRAN.PS",
      "copybook":"CARDDEMO.COPYLIB(CVTRA06Y)",
      "mode":"replace",
      "rows":[{"DALYTRAN-ID":"...","DALYTRAN-AMT":"125.00", "...":"..."}]}}
   # → { "ok":true, "dsorg":"PS", "charset":"ebcdic", "given":N, "written":N,
   #       "total":N, "sha256":"..." }   # load the same rows into your candidate

3. run_batch — the posting job, with decoded outputs and a pinned clock:

   {"name":"run_batch",
    "arguments":{"workspace":"W1",
      "member":"CARDDEMO.JCL(POSTTRAN)",
      "copybooks":{"AWS.M2.CARDDEMO.TRANSACT.VSAM.KSDS":"CARDDEMO.COPYLIB(CVTRA05Y)",
                   "AWS.M2.CARDDEMO.ACCTDATA.VSAM.KSDS":"CARDDEMO.COPYLIB(CVACT01Y)"},
      "records":"rows",
      "clock":{"fixed":"2022-07-18 10:20:30"}}}
   # → { "runId":"...", "jobid":"JOB01000", "maxcc":0, "abend":null,
   #       "steps":[{"name":"STEP15","pgm":"CBTRN02C","rc":0}],
   #       "joblog":{"JESMSGLG":{...},"JESYSMSG":{...},"STEP15.SYSPRINT":{"text":"..."}},
   #       "outputs":{"AWS.M2.CARDDEMO.TRANSACT.VSAM.KSDS":{"charset":"program",
   #                   "total":N,"sha256":"...","rows":[...]}, ...},
   #       "sha256":"..." }         # run YOUR posting job on the same seed; compare rows + RCs

4. cics_open_session + cics_send — the signon transaction, one AID at a time:

   {"name":"cics_open_session",
    "arguments":{"workspace":"W1","clock":{"fixed":"2022-07-18 10:20:30"}}}
   # → { "session":"S1", "termid":"...", "keyboard":"unlocked",
   #       "screen":{ "format":"steelframe-screen/1", "fields":[...], "text":[24 lines] } }
   
   {"name":"cics_send",
    "arguments":{"workspace":"W1","id":"S1","aid":"ENTER","text":"CC00"}}
   # → { "step":1, "screens":[...every screen painted...], "screen":{...COSGN00...},
   #       "task":{"transid":"CC00","alive":false}, "settled":true }
   
   {"name":"cics_send",
    "arguments":{"workspace":"W1","id":"S1","aid":"ENTER",
      "fields":[{"name":"USERID","text":"USER0001"},{"name":"PASSWD","text":"PASSWORD"}],
      "expect":{"text":"MAIN MENU"}}}
   # → { "screen":{ "fields":[{"name":"CURDATE","text":"07/18/22"}, ...] },
   #       "expectMet":true, ... }   # drive YOUR UI with the same inputs; compare fields

   …then cics_close_session {"id":"S1"}. Or the same steps as one cics_run_script {"steps":[...], "state":"auto"} → the transcript plus a dump of every CSD FILE dataset.
5. sched_demand → sched_wait_cycle — the CA-7 chain, in the order the oracle ran it:

   {"name":"sched_demand","arguments":{"workspace":"W1","job":"POSTTRAN"}}
   # → { "id":"CYC00004", "jobs":[...] }
   
   {"name":"sched_wait_cycle",
    "arguments":{"workspace":"W1","id":"CYC00004","joblogs":"all"}}
   # → { "cycle":"CYC00004", "ended":true, "result":"OK",
   #       "jobs":[{"name":"POSTTRAN","state":"ENDED-OK","jobid":"JOB01001","maxcc":0,
   #                "steps":[...],"joblog":{...}},
   #               {"name":"WAITSTEP","state":"ENDED-OK", ...}],
   #       "runId":"..." }          # compare job order, RCs and outputs with your orchestration

6. export_state — the after-state, hashed, to diff on your side:

   {"name":"export_state",
    "arguments":{"workspace":"W1","name":"after-posting","records":"rows",
      "datasets":[{"dsn":"AWS.M2.CARDDEMO.ACCTDATA.VSAM.KSDS","copybook":"CARDDEMO.COPYLIB(CVACT01Y)"},
                  {"dsn":"AWS.M2.CARDDEMO.TRANSACT.VSAM.KSDS","copybook":"CARDDEMO.COPYLIB(CVTRA05Y)"}]}}
   # → { "id":"...", "sha256":"...",
   #       "artifacts":[{"kind":"dataset","name":"AWS.M2.CARDDEMO.ACCTDATA.VSAM.KSDS",
   #                     "charset":"program","count":N,"sha256":"..."}, ...],
   #       "datasets":{"AWS.M2.CARDDEMO.ACCTDATA.VSAM.KSDS":{"rows":[...]}, ...} }

7. destroy_workspace {"id":"W1"} — nothing on the live estate changed.

Pricing (SteelFrame credit)

MCP and API-key calls draw on the same prepaid SteelFrame credit as the AI assistant. Working by hand in the web terminal, Studio and VS Code is never charged.

Failed and refused calls are free, an identical retry within 60 s is free when nothing of yours changed in between, and every billable result ends with its cost and your remaining balance (_meta['io.steelframe/billing']; each tool's class and price is in its _meta['io.steelframe/price'] in tools/list). At $0 a call answers CREDIT_REQUIRED (do not retry; top up). Each key has its own rolling 24-hour spending cap (DAILY_CAP). The other doors' prices are in their sections below: the same $0.03 write / compile and run rule, and $0.01 for a screen action on /mcp/screen.

The VS Code MCP — your agent drives your own VS Code

A second server, steelframe-vscode at POST /mcp/vscode (same transport and keys as /mcp), lets your agent (Claude Code, Cursor, Claude Desktop, any MCP client) drive your own SteelFrame VS Code seat (code-server + Zowe Explorer, logged on as you) — exactly the tools the AI assistant panel uses there. Every action happens visibly in your VS Code tab: text is typed at human speed, saves go through Zowe and are verified against the mainframe, Java builds and runs stream into the Output panel SteelFrame AI: Java, Python runs and tests into SteelFrame AI: Python, SQL into SteelFrame AI: SQL, and the page shows an amber ring with Your AI agent is working in VS Code (MCP).

• Keep the VS Code tab open (or use a headless window, next item). code-server runs extensions only for a connected window, so the tools work while you have the VS Code tab open in the SteelFrame web (it may stay in the background). vscode_status says whether it is connected; vscode_start starts your container seat and waits for the window. Without one, a call fails fast with VSCODE_NOT_CONNECTED and the page to open — never a hang, never a charge.
• Headless: no open tab needed (on here). A Custom key with vscode.drive and vscode.headless (in no preset) lets vscode_start, or the first vscode_* call, start your container seat and open a headless VS Code window for the agent on the SteelFrame engine, with no website logon. vscode_status says window: "headless" or "browser". The window closes after 10 minutes without a vscode_* call, at the operator's maximum lifetime, when the key is revoked or expires, and when you log on to the website VS Code tab (your window takes over). One seat stays reserved for website users (VSCODE_HEADLESS_BUSY, free). The window itself is free; the tools cost what they cost.
• Key scope: vscode.drive — in the Developer and Full presets, not in Read-only (keys minted before 2026-10-14 do not have it: mint a new one). A key without it gets 403 KEY_SCOPE; REST-only keys 403 KEY_SURFACE.
• Your seat only. No tool takes a user or bridge argument; a key reaches only the VS Code of the user it belongs to.
• Seat kinds. A container seat (your own isolated VS Code, JDK 25 / Java 21 target, Maven offline, Python 3.13 with pytest, numpy, pandas, basedpyright and an offline wheelhouse, and your own PostgreSQL 17 database) gets 29 tools, plus 5 .NET, 6 Node.js and 6 language tools (C / C++, Go, shell, PHP, Lua, Kotlin, Rust, PowerShell) where the seat image carries them (all 46 on steelframe.cobolstack.com). A new container seat has no language folders: the first tool call of a language creates its folder (java/, python/, dotnet/, node/, c/, ...) with only its required setup and ONE hello-world project (java/hello-java, python/hello-python with the venv, node/hello-js, angular/carddemo-ui, ...); the result says so. The other starters are samples, copied from the seat image when a tool names one as the project (e.g. vscode_java_build hello-postgres). In VS Code the user runs SteelFrame: New project…. Existing folders are never touched. The host seat (the operator's shared VS Code) gets the editing tools only: no vscode_run_command, no Java, no Python, none of the language folders, no database.
• .NET and Node.js / TypeScript / Angular (container seats). vscode_dotnet_open / _write / _build / _run / _test: the .NET 10 SDK under dotnet/, packages only from the seat's offline NuGet folder (Npgsql, Dapper, EF Core, xUnit), run starts the project's own built app. vscode_node_open / _write / _install / _run / _test / _build: Node.js 22 under node/ with a built-in TypeScript / tsx / Vitest / ESLint / pg toolchain (no install needed), and Angular 22 under angular/ (ng build, ng test with Vitest + jsdom, no browser; starter angular/carddemo-ui); install is an offline, script-less npm install of what the toolchain lacks. Fixed commands only; NuGet.Config, .npmrc, node_modules, lock files, URL / git / file: dependencies and install scripts are refused (free). The seat also has Prettier and the Vitest explorer (the Testing view), @types/express in the offline cache, the plain-JavaScript hello world node/hello-js (TypeScript: the sample node/hello-node) and Run and Debug configurations for tsx, node and Vitest.
• Languages: C / C++, Go, shell, PHP, Lua, Kotlin, Rust, PowerShell (container seats). ONE tool family, the language is the project's top folder: vscode_lang_open / _write / _build / _install / _run / _test on c/, go/, shell/, php/, lua/, kotlin/, rust/ or pwsh/<project>. C / C++: gcc / g++ 12, make, CMake 3.25, gdb 13, clangd 16 in the editor; build = CMake if the project has a CMakeLists.txt, else its Makefile, else gcc -std=c17 / g++ -std=c++20 of its sources into build/<project>; test = ctest, make test or the tests/test_*.c build; run = the built program. Go 1.27 with gopls, Delve and staticcheck: build = go build -o bin/ ./... + go vet, test = go test, run = the built program (never go run), install = go mod tidy OFFLINE from the seat's read-only module cache (pgx, chi, testify, cobra, shopspring/decimal, yaml.v3, x/text). Shell: bash 5.2; build = bash -n + shellcheck, test = bats, run = bash <script>. PHP 8.2 with Composer, Phpactor and Xdebug: build = php -l + composer validate, run = php <script>, install = composer update OFFLINE from the seat's package repository (PHPUnit 11, brick/math, monolog, league/csv; no package scripts or plugins), test = vendor/bin/phpunit. Lua 5.4: build = luac5.4 -p, run = lua5.4 <script>, test = tests/run.lua. Kotlin 2.4 on JDK 25 with Maven (kotlin-maven-plugin, kotlin-test + JUnit 5 from the offline repository): build = Maven package, run = java with the main class (e.g. hello.HelloKt), test = mvn test. Rust 1.99 with clippy, rustfmt and rust-analyzer: build = cargo build (limit 300 s; one build folder rust/.target for all projects), test = cargo test, install = cargo fetch against the seat's vendored crates (serde, serde_json, anyhow, thiserror, clap, tokio, postgres, rust_decimal, chrono, regex, rand, itertools, csv), run = the built program. PowerShell 7.6: build = the PowerShell parser + PSScriptAnalyzer, run = pwsh -File <script>, test = Pester 6. Runs stop after 60 s, builds and tests after 150 s (Rust 300 s); no stdin, no internet; something the seat's offline sets lack fails at once (free); build/, bin/, target/, vendor/, go.sum, go.work, Cargo.lock, composer.lock and auth.json are never written. Starters: c/hello-c, c/record-reader (a COBOL copybook record: packed decimal, zoned decimal and EBCDIC decoded in C), go/hello-go, go/go-postgres, shell/hello-shell, shell/jcl-to-shell (a SORT / SUM / report batch job as a shell pipeline), php/hello-php, php/php-postgres, lua/hello-lua, kotlin/hello-kotlin, rust/hello-rust, rust/rust-postgres, pwsh/hello-pwsh (the *-postgres ones use your own PostgreSQL). In the editor: the debuggers gdb (Native Debug; rust-gdb for Rust), Delve, bashdb, Xdebug (PHP Debug), Lua Debug and the PowerShell debugger; the language servers clangd, gopls, Bash IDE, Phpactor, Lua, rust-analyzer and PowerShell Editor Services (Kotlin: highlighting only). vscode_status returns langs, the language folders your seat has. Not in the seats (ask the operator): Scala, Swift, Dart, Haskell, Elixir, Ruby, R.
• PostgreSQL. vscode_db_schema and vscode_db_query (ONE read-only statement in a read-only transaction, at most 200 rows) are free; vscode_db_exec runs a DDL/DML script as one transaction (all or nothing); vscode_db_import brings a DB2 table over (DSNTIAUL unload into your own data sets through your z/OSMF door, EBCDIC and packed decimals decoded in the seat, CREATE TABLE + COPY) and reports PARITY OK or the mismatches (row counts, per-column sums and value hashes, DB2 vs PostgreSQL); vscode_db_import_vsam brings a VSAM cluster (KSDS, ESDS, RRDS) or a sequential data set over through its COBOL copybook (decoded by the mainframe's own copybook codec as you; PIC X to varchar, zoned and COMP-3 to numeric(p,s), COMP to integers, OCCURS to arrays, the KSDS key to the primary key) and reports PARITY OK with a byte proof (every PostgreSQL row re-encodes to the source record). The tools connect as your non-superuser role: no COPY, no server files or programs, no role, extension (outside a trusted list) or time-limit changes; 200 MB per database.
• No shell. Java runs only through fixed javac / Maven / java command templates with validated paths, class names and arguments; Python only through fixed python -u <file>, python -m pytest, basedpyright and offline pip install -r requirements.txt templates in your venv (requirements.txt holds package names and versions only; packages come from the seat's wheelhouse); vscode_run_command is an allow-list of 15 UI commands (no terminals, tasks, debugging, extensions or settings).
• Web apps — coming soon (not switched on at steelframe.cobolstack.com yet; these tools are not in its tools/list). Where an operator switches them on (container seats): vscode_java_serve, vscode_dotnet_serve and vscode_node_serve start your BUILT app with the run tools' fixed command and keep it running on an app port of your seat (3000-3009, 5000-5009, 8082-8089; at most 2 apps; stopped after 15 minutes without a request, after 2 hours, and when your seat ends). The app opens on a private address of its own (https://<port>-<you>-<nonce>.<apps host>/, only you can open it) and in the App Preview tab. vscode_app_list, vscode_app_logs and vscode_app_stop are free. No live reload: build, stop, serve again.
• Untrusted results. Results carry text from your own files, programs and spool; each starts with a header saying so. snapshot:true on an action tool appends what the VS Code tab shows afterwards.
• Limits: 120 calls a minute and 3 in flight per user (VS Code does one action at a time); build/test/install 180 s, run 90 s, SQL script 90 s, DB2 import 330 s per call.

Setup (your account page shows these with your key filled in):

claude mcp add -s user --transport http steelframe-vscode https://steelframe.cobolstack.com/mcp/vscode \
  --header "Authorization: Bearer sf_…"

# .mcp.json / Cursor / Windsurf
{ "mcpServers": { "steelframe-vscode": { "type": "http",
    "url": "https://steelframe.cobolstack.com/mcp/vscode",
    "headers": { "Authorization": "Bearer sf_…" } } } }

Tools and prices (same credit, caps, loop guard and retry rule as /mcp; ledger kind mcp):

Failed or refused calls are free; the same failing call five times in ten minutes is refused with LOOP_GUARD. The free identical-retry rule (60 s) applies only to tools whose arguments name the action (vscode_java_write, vscode_python_write, the Java build/run/test and the Python run/test/install/type check of a project, the .NET / Node write, build, run, test and install, vscode_open_member); the tools that act on the active editor (vscode_type, vscode_set_text, vscode_insert_lines, vscode_save, vscode_run_command, vscode_submit_job) and vscode_db_exec are charged every time. The same routes exist as REST (POST /api/vscode/<tool>, GET /api/vscode/status) for scripts.

The Git MCP — your agent uses your own GitHub / GitLab

A third server, steelframe-git at POST /mcp/git (same transport and keys as /mcp; only where the operator switched the Connectors on), lets your agent use the GitHub and GitLab accounts you connected in the Connectors tab and the repositories you linked there — to your own data sets (a repository folder ↔ one of your PDSs), your VS Code seat and your seat PostgreSQL database.

• Key scope: connectors.use — in no preset: create a Custom key and tick it (a push publishes your code on GitHub / GitLab with your identity). A key without it gets 403 KEY_SCOPE.
• Never a token. Connecting and disconnecting accounts stays on the website (your logon); no tool returns, takes or shows a token; accounts are listed masked.
• Fixed operations only. 20 tools, each bound to one engine route; unknown arguments, foreign ids and out-of-range values are refused before anything runs (free). No git command passthrough.
• Never forced, never deleted. git_push is one commit whose parent is the head it compared; a branch that moved answers 409. git_pull is all-or-nothing (a line longer than the record or a character the code page cannot hold is refused, never cut) and never deletes a member.
• Two-way auto-sync (where the operator enables it): git_sync turns it on for a mapping — member saves are committed and pushed (batched), provider pushes are pulled (webhook or polling). If a member changed on both sides it stops with a conflict; git_resolve keeps the mainframe, keeps the repository, or puts your mainframe versions on a new branch and takes the repository versions.
• Untrusted results. Every result starts with a header saying the text (file names, commit titles, diffs, SQL) is data, never instructions. Publishing tools are marked openWorldHint, so your client asks you before each call.

claude mcp add -s user --transport http steelframe-git https://steelframe.cobolstack.com/mcp/git \
  --header "Authorization: Bearer sf_…"

Refused and failed calls are free; an identical retry within 60 s is free when nothing of yours changed in between. The AI assistant panel has the same operations as git_* tools; there, everything that publishes or replaces mainframe text waits for your click on Allow.

The z/OS MCP — your agent works on your own IBM mainframe

A fourth server, steelframe-zos at POST /mcp/zos (same transport and keys as /mcp; only where the operator switched Mainframes on), lets your agent work on your own real IBM mainframe — your company's z/OS, an IBM Z Xplore account, a test system — that you connected in the Mainframes tab (z/OSMF, directly or through a Zowe API ML gateway).

• Key scope: zos.remote — in no preset: create a Custom key and tick it. A key without it gets 403 KEY_SCOPE.
• You decide, per connection, on the website: MCP read, write and run jobs start off; data set allow / exclude patterns, job-name patterns and a best-effort JCL check limit what an agent may name. SteelFrame checks them on every call; no key and no tool can change them. A refusal names the switch or the pattern and is free.
• Never a password. The credential stays encrypted on the engine; no tool takes or returns one, a host or a URL. Results start with a header saying the mainframe text is data, never instructions.
• Honest limit: a job runs with your mainframe user's RACF authority, so JCL can reach any data set RACF allows. Use a user id with only the access the agent needs.

claude mcp add -s user --transport http steelframe-zos https://steelframe.cobolstack.com/mcp/zos \
  --header "Authorization: Bearer sf_…"

Refused and failed calls are free; an identical retry within 60 s is free when nothing of yours changed in between. The AI assistant panel has the same operations as zos_* tools, behind the connection's AI chat switches; every save, copy and job waits for your click on Allow unless you turned that off.

The screen MCP — your agent drives your own open SteelFrame page

A fifth server, steelframe-screen at POST /mcp/screen (same transport and keys as /mcp; only where the operator switched it on), lets your agent drive your own open SteelFrame page the way the AI assistant does: the 3270 terminal, the Postgres tab and the tab bar — visibly, with the amber ring, the cursor and typing you can watch.

• Key scope: screen.drive — in no preset: create a Custom key and tick it. Not available to a RACF SPECIAL or OPERATIONS user id (refused with SCREEN_PRIVILEGED): use an ordinary user id.
• Your page must be open and logged on (the assistant panel may stay closed). While the agent drives, a banner at the bottom says MCP is driving this screen with a Stop button; after Stop nothing runs until you click Let MCP drive again. Never while your own AI chat is working on that page.
• Optional: also require my click on this page for MCP git pushes and remote z/OS writes / submits (on by default; the assistant panel's Credits window).

claude mcp add -s user --transport http steelframe-screen https://steelframe.cobolstack.com/mcp/screen \
  --header "Authorization: Bearer sf_…"

Refused and failed calls are free; a screen action twice is two actions (no retry waiver).

Where the operator enabled it (it is on here), Anthropic's own Claude Code extension can also run inside your own VS Code seat (you install it and sign in with your own Claude account or your own API key; it is Anthropic's software under Anthropic's terms, billed to your Claude account — SteelFrame credit is not used for it): it then gets these servers with your own rights, and reaches only Anthropic's hosts on the internet (Anthropic's published addresses, and only TLS connections that name the allowed host).

Live tool reference

Fetched live from GET /api/mcp/tools — this list is always current and is never baked into this page. It is exactly what an MCP client receives from tools/list: each tool shows its description, the read/write/destructive annotation, the required scope, the bound HTTP method/path, and the full input schema (parameters, types, required fields). The "instructions" box is the text the client receives from initialize. Click a tool to expand.