torch-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TORCH_PATH | Yes | Path to the Torch binary (e.g. /home/cody/.local/bin/torch). Used by torch-mcp to locate the Torch executable. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| torch_capabilitiesB | Probe Torch executable, inspect registered CLI subcommands, detect compiled features, and review registered asset types and upstream caveats. |
| torch_validate_projectB | Pre-flight validation for a Torch project: calculates ROM SHA1, parses config.yml, checks hash matches, verifies destination permissions, and validates asset paths. |
| torch_export_archiveB | Extract assets from an N64 ROM into an O2R (ZIP resource archive) or OTR (StormLib archive) file using Torch. |
| torch_export_codeB | Export decompiled C source code representation of N64 assets from a ROM using Torch. |
| torch_export_headersC | Generate C headers for assets from an N64 ROM using Torch. |
| torch_export_moddingA | Export editable asset files from an N64 ROM using Torch modding export. Produces modding.yml manifest and editable raw or XML assets. |
| torch_import_moddingB | Import edited modding assets from destdir/modding/modding.yml back into code, otr, o2r, or header targets. |
| torch_pack_archiveB | Pack a directory of prepared resource files into an O2R or OTR archive without requiring a ROM or config.yml. |
| torch_bk64_hashesB | Generate Banjo-Kazooie (BK64) baseline asset table hashes from a ROM at offset 0x5E90. |
| torch_diagnose_binaryA | Diagnose the upstream "torch binary" subcommand bug and get recommended workarounds for extracting raw binary assets. |
| torch_render_sequencesA | Headless audio extraction: renders sequence-driver audio assets and writes 16-bit PCM stereo 32kHz WAV files via Torch UI test harness without opening a display window. |
| torch_parse_configA | Parse, inspect, and summarize a Torch config.yml file, displaying registered ROM SHA1s, game titles, asset paths, GBI microcodes, output maps, and segment definitions. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool targets a distinct operation or output type. The four export tools differ by output format (archive, code, headers, modding), and import_modding is the clear inverse of export_modding. No two tools appear to serve the same purpose.
Most tools follow the verb_noun pattern (e.g., validate_project, parse_config, export_archive). However, torch_capabilities and torch_bk64_hashes are noun-only, breaking the otherwise consistent pattern.
With 12 tools, the server is well-scoped for the N64 ROM modding domain. Each tool covers a specific capability without redundancy, fitting comfortably in the ideal range.
The tool surface covers the full lifecycle: probing, validation, parsing, rendering, exporting/importing in multiple formats, packing, hashing, and even diagnosing a known bug. There are no obvious missing operations that would block common workflows.