80mcp is an MCP stdio server that runs and asserts on CP/M and DOS packages in Z80/x86 emulators, inspects guest files, and probes what a package needs.
Install/run: pip install -e ., then 80mcp doctor or 80mcp for MCP JSON-RPC over stdio.
x80_profiles: list machine profiles, backends, tiers, capabilities, required images, readiness; call first.
x80_cpm_run: run a CP/M package in a fresh sandbox; collect stdout, file manifest, termination reason, and assertions (no exit_code).
x80_dos_run: run a DOS package in a fresh sandbox; supports meaningful exit codes, assertions, env, args, stdin.
x80_diff_run: run inputs through a guest program and host reference, compare outputs byte-for-byte under declared normalization.
x80_files: move/list files between host and guest, show guest open handles, resolve guest paths without running.
x80_probe: run a package on the cheapest profile and report the OS/syscalls it actually needs, with a next call.
x80_images: download and verify pinned disk images; never called implicitly and requires explicit fetch permission.
Current scope: Phase 1 only, seven tools registered; only cpm-hosted and dos-hosted run today; hardware profiles report ready:false.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@80mcp Run the 1986 ARC test suite on cpm-hosted and show byte-exact diff vs reference"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server over the Z80 and x86 emulator family in the sibling repos — so an agent can run a CP/M, MP/M or DOS package and assert on what came back, and debug the emulators themselves without a human doing it by mouse click and screen read.
Phase 1 ships. Phases 2-5 are still proposal. The full design is in SPEC.md; this file is the short version. If you are an agent about to make a call, read DRIVING-WITH-AI.md instead — it is the operating manual, and its Gotchas chapter is measured rather than remembered.
pip install -e .
80mcp doctor # every backend and profile, exiting nonzero on any problem
80mcp # speak MCP JSON-RPC on stdioPython 3.11+, no third-party runtime dependencies. pytest and
jsonschema are dev-only: pip install -e ".[dev]".
Register it as an stdio server:
{"mcpServers": {"80mcp": {"command": "80mcp", "args": []}}}80mcp doctor is the first thing to run and the first thing to paste into a
bug report. The doctor output, backend discovery and protocol notes are in
docs/status.md.
Related MCP server: pet-tools-mcp
Seven batch tools over two backends: x80_profiles, x80_cpm_run, x80_dos_run,
x80_diff_run, x80_files, x80_probe and x80_images. The other sixteen tools
are not registered. Two profiles run today: cpm-hosted (cpmemu) and dos-hosted
(dosiz). Every hardware profile reports ready:false with the phase that will
unblock the profile. The full tool and profile tables are in
docs/status.md.
For an agent that writes, assembles and single-steps a CP/M program on period 8080/Z80 hardware, use deltecent/altairsim alongside 80mcp. docs/background.md explains why.
file | for |
an agent about to make a call. The seven tools, the profile decision tree, the two tiers, and twelve measured gotchas | |
a runnable end-to-end exercise: unpack an archive, prove it byte-correct, then break it four ways on purpose | |
how to run the suite and which tests need which backend binary | |
the full design: all 23 tools, the MBP boundary, and the measured-facts index in Appendix A | |
the raw transcripts every number in the spec traces back to | |
| |
prior art (altairsim, Spice86, DOSBox-X), what is missing, the mode matrix, and two design conclusions |
repo | role here |
the Z80 + RomWBW HBIOS core, and the primary interactive backend. Already headless, pipe-driven, with a | |
BDOS-level CP/M 2.2 translator — the | |
real MP/M II V2.1 with a banked XIOS, 60 Hz preemption and up to 8 SSH consoles — the | |
DOS-API translator (INT 21h/31h/67h → host C++) — the | |
owns | |
the sha256-pinned ROM and disk-image catalog every profile resolves through | |
not an emulator — the reference fixture. Ships the same unpacker as a CP/M | |
GUI clients. Explicitly not automation targets — see docs/background.md |
GPL-3.0-or-later, matching the rest of the family.
Run one CP/M package to completion in a fresh sandbox and return its console output, a manifest of the files it created, a termination reason, and your assertions. This tool deliberately has no exit_code field, because no CP/M backend has one: CP/M has no exit-status concept, cpmemu exit(0)s on every path including its runaway watchdog, romwbw_emu always returns 0, and a run that extracted 1 of 23 files and printed "Error" still exited 0 (measured). Success must be asserted from stdout plus the file manifest.
Inputs: profile (required), program (required), cpu, args, +9 more.
Run the same inputs through a guest program and a host reference implementation and compare the outputs byte for byte under a declared normalization. Built for the case 80un proves: the same algorithm shipped as a CP/M .COM and as Python.
Inputs: guest (required), inputs (required), reference (required), compare, +2 more.
Run one DOS package to completion in a fresh sandbox. Unlike x80_cpm_run this does have a meaningful exit code — dosiz propagates the DOS AH=4Ch AL value (measured: rc 7) — but rc 1 is ambiguous between "the guest exited 1" and "dosiz failed to load the program", so exit_code_meaning disambiguates it from stderr.
Inputs: profile (required), program (required), env, args, +8 more.
Move files between the host and a guest, list what the guest can see, show what it has open right now, and answer "where would A:FOO.TXT come from?" without running anything. The direction is in the op name, not in a flag, because the single most common agent failure in this domain is editing a host copy of a file instead of the one the guest can see.
Inputs: op (required), via, hash, drive, +13 more.
Download and verify disk images from the pinned romwbw_disks catalog. Every other tool in this server is openWorldHint:false. Never called implicitly — no tool call may trigger a download.
Inputs: dry_run, image_ids, timeout_ms, allow_fetch, +1 more.
Run a package on the cheapest profile and report what operating system it actually needs, from the syscalls it made — evidence instead of a screen read. Returns a literal next call to make.
Inputs: program (required), args, stdin, family, +2 more.
List the machine profiles this installation can actually run: backend, tier, capabilities, required disk images and whether they are present. Call this first. Capabilities differ enormously between backends, and a profile with a missing image or a ROM/disk version mismatch will fail x80_open.
Inputs: probe, family, profile, only_ready.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 7 tools
The tools are mostly distinct: profiles, images, files, probe, CP/M run, DOS run, and diff run each target a different phase or concern. The run/probe/diff tools could be confused at a glance, but their descriptions clearly separate OS detection, full execution, and guest-vs-host comparison.
All tools share the x80_ prefix and use domain-specific suffixes, with the run tools following an <os>_run pattern. There is a minor mix of noun-style names like x80_files and x80_profiles with verb-style x80_probe, but the overall pattern remains predictable.
Seven tools is well within the ideal range and each tool earns its place by covering a distinct part of the emulation workflow: environment discovery, image provisioning, file transfer, probing, execution, and diffing. There is no obvious redundancy or bloat.
The set covers the core run-to-completion loop well: discover profiles, provision images, transfer files, run CP/M or DOS packages, probe OS requirements, and diff against a host reference. Minor gaps exist, such as no exposed x80_open/session tool and no package catalog listing, but agents can work around these.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Persistent memory, knowledge graph, task management and more for AI agents via MCP.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
214 tools for AI agents over one MCP endpoint: image, video, audio, 3D, data, storage, mail, GPUs.