Loading ToolBench
MCP server for the Retro Hardware Database. A thin wrapper over the REST API that exposes native tools to list / get / create / update / delete computers and parts over the Model Context Protocol. It holds no data itself -- every tool call is an HTTP request to the API.
Server has 7 tools with complete input schemas and descriptions. Naming follows verb_noun convention (list_, get_, create_, update_, delete_). However, descriptions vary significantly in quality: some are exceptionally detailed (create_computer at 1200+ chars), while others are minimal (list_computers at 60 chars). Parameter descriptions are present but inconsistent, some parameters lack actionable constraints (e.g., 'name' has no length limits, format rules, or examples). Output schemas are not documented. Error handling guidance is absent. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Composition is sound: tools chain logically (list → get → create/update/delete). Security: no credentials exposed as parameters, but no audit trail or permission gate documentation.
Create a computer. The server assigns the asset id from the register shared with parts. CPU, installed_ram and drives (floppy/optical/CF-SD, ';'-separated) are attributes of the computer, not separate parts. installed_ram takes a plain amount ('640KiB'); the per-module breakdown is entered in the GUI. topbench is what the machine scores in TopBench, the DOS benchmark -- an x86 machine only, and only once it has actually been run on this machine. Leave it out otherwise: an unmeasured machine has no score, and one must never be guessed from the CPU. serial is the number stamped on this particular machine, which is the one field here that is not a fact about the model. Only ever from the object itself: it cannot be inferred from anything else, and a wrong one is worse than none. location is where the machine is physically kept, in the owner's own words -- 'Loft, blue crate 3', 'Garage shelf B'. Free text, and only ever what somebody has said: it cannot be worked out from anything else in the record. For a home computer or a console -- a Spectrum, a C64, an Apple IIe, an MSX -- the machine_* arguments file it against the catalogue that list_machine_models returns: machine_model_key is that model's key, machine_issue the board as its make marked it ('Issue 6A', 'ASSY 250425', 'VA6'), machine_style the case or keyboard it was built with, machine_region the market it was sold in, and machine_chips a {role: part number} map for its sockets ({'ula': 'Ferranti 6C001E-7'}). A role that model has no socket for is refused. work_needed is what the thing needs doing, one job to a line, written at the moment it is checked in -- 'recap the PSU', 'new belt', 'keyboard sticks'. It raises a project about this item with each line as a job on it, named after the item -- what it is called, or its tag where it has no name yet -- and the reply's `project` names it. Readable by anybody, like the rest of the register (ADR-0004); the tick on a project's own form is what keeps one back. Only what somebody actually said is wrong: a fault is an observation, never a guess from the age or the model. work_project puts it on a project already going instead of raising one -- what a part bought for a build in hand is for -- and takes that project's asset id; one that does not exist is refused.
Delete a computer by asset id. Its parts are not deleted -- they are unlinked and become standalone. Its photos, drive and memory rows and history go with it, and none of it comes back; to take a machine out of the collection reversibly, set disposed instead.
Output schemas not documented. LLMs cannot plan downstream calls or extract required fields (e.g., asset_id from create_computer response). Breaks tool chaining.
Tool annotations missing. create_computer, update_computer, delete_computer lack readOnlyHint/destructiveHint metadata. Agents cannot distinguish safe reads from destructive writes without parsing descriptions.
Parameter descriptions lack actionable constraints. 'name' (string) has no length limits, format rules, or examples. 'year' (integer) has no min/max bounds. 'location' accepts free text but no guidance on format. Invites invalid LLM input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Fetch one computer by its asset id, e.g. RH-0001.
List every computer (whole machine) in the asset register.
The catalogue of known home computers and consoles -- three hundred of them from seventy-odd makers in Britain, Europe, America and Japan: Sinclair, Commodore, Atari, Acorn, Amstrad, Oric, Dragon, Thomson, Apple, Tandy, TI, Sega, Nintendo, NEC, Sharp, Fujitsu, MSX and more -- and the variations each model was built in: its standard memory sizes, board issues, case and keyboard styles, regions, and the chip sockets with the part numbers that turn up in them. Call this before creating or updating one of these machines: `key` is what the `machine_model_key` argument takes, and the chip roles it lists are the keys of `machine_chips`. Every list names what is commonly seen rather than everything that exists, so a board or a chip from outside one can still be recorded as it is.
List parts, optionally filtered by computer_id and/or type.
Partial-update a computer: only the fields you pass are changed. Set disposed true to flag it disposed, with disposed_at (ISO date) and disposed_note for when and why; set it false to undo. The machine_* arguments record a catalogue machine's identity and work the same way (see create_computer and list_machine_models): passing one leaves the others as they are, and machine_chips replaces the whole set of chips rather than merging into it. An empty machine_model_key files the machine out of the catalogue, which forgets its board issue and chips with it.
Error handling guidance absent. No recovery hints (e.g., 'asset_id not found, call list_computers() to discover valid IDs'). Agents cannot self-correct on failures.
list_computers and list_parts lack pagination parameters (limit, offset, page). No total count or next_cursor in response schema. Large collections will blow context window.