mock-gkn-hpc
A public MCP mock of GKN's internal HPC server for Ansys / Finite Element analysis. It lets external clients exercise the full submit → poll → fetch-artifacts loop against a fake HPC — no real solver, queue, or cluster behind it.
This is a sample MCP server developed alongside the DUCTILE agentic orchestration paper. See the DUCTILE repository or the paper (DOI: TBD) for context.
Install and run
uvx mock-gkn-hpc
Or wire it into your MCP client config:
{
"mcpServers": {
"mock-gkn-hpc": {
"command": "uvx",
"args": ["mock-gkn-hpc"]
}
}
}
Job artifacts default to a system tempdir (gettempdir()/mock-gkn-hpc). Override with --runs-dir /custom/path or the MOCK_GKN_HPC_RUNS_DIR env var.
Tool surface
submit_ansys_run mirrors GKN's qansys wrapper:
| Param | qansys flag | Default | Notes |
|---|---|---|---|
input_file |
-i |
(required) | Path to .ans / .cdb |
version |
wrapper version | "2025r1" |
Picks the qansysX release |
job_name |
-j |
input filename stem | Descriptive only — storage uses a UUID |
output_file |
-o |
auto | Recorded but not enacted by the mock |
np |
--np |
4 |
Cosmetic; doesn't scale runtime |
product |
-p |
"ansys" |
One of "ansys", "meba", "mechs" |
start_time |
-a |
None |
MMDDhhmm; recorded but doesn't delay |
high_prio |
--highprio |
False |
Cosmetic |
All parameters round-trip through meta.json, the log banner, and the rendered results.rst.
Other tools and resources:
| Name | What it does |
|---|---|
job_status(job_id, wait_s=0) |
Status of one job (pending/ready/failed/expired); with wait_s, waits up to that many seconds (max 120) for a pending job to finish |
get_job_log(job_id), get_job_results(job_id) |
The log so far and, once ready, the results file (for clients that cannot read MCP resources) |
list_jobs() |
Every job with its status and age |
delete_results(job_id) |
Deletes one job's log, results and metadata |
ansys://{job_id}/log, /results, /meta |
The job's log (as written so far), results file and meta.json |
The log is built from the job: the requested version and product, every file the deck reads,
and one LOAD STEP line per SOLVE the deck executes, with its load file.
Jobs are stateless: a job's status, log and results follow from its submit time (pending for ~30 s, then ready, expired 1 h later), so they need no running process and survive a server restart (e.g. when a client session ends and a new one starts).
Input pre-flight check (v0.6.0)
A real solve stops at the first /INPUT or CDREAD whose file it cannot read. The mock has no
solver, so submit_ansys_run walks the runscript at submission (parameters, arrays, *DO
loops, macros and %...% substitution) and checks every file the deck would read. A job sees:
- its staged directory, the input file's folder (relative paths resolve against it), and
- the cluster's shared
/projectstorage, described bysrc/mock_gkn_hpc/cluster_files.txt(override with theMOCK_GKN_HPC_CLUSTER_FILESenv var, one absolute path per line).
If any file is missing, the job is recorded as failed (its log holds the error) and the tool
returns status: "failed" with Ansys-style messages (a normal result, not an MCP error), e.g.
Job e816a8ac (runscript) failed during input processing: 6 file(s) read by the deck do not exist.
*** ERROR ***
/INPUT failed (runscript line 139). File /project/.../01_inputs/loads/limit_load_2.inp does not exist.
so an agent sees the failure in its context and can fix the deck and resubmit. A successful
submission reports input_files_checked (and notes, e.g. a character value cut to 32
characters).
The walker follows APDL's parameter rules:
- array parameters must be dimensioned with
*DIMbefore values are assigned, unless an implied (colon) loop defines them (a(1:3)=1,2,3); CHARarray elements hold 8 characters and scalar character parameters 32;- in a
STRINGarray the first subscript is the character position and the next ones select the string:name(1,j)is the j-th string. Writingname(2)='x'into a one-column STRING array therefore writes from character 2 of the same string.
It also handles *SET, NINT, INT, ABS, CHRVAL and STRCAT. A /INPUT or CDREAD
whose file name cannot be resolved with this subset is reported as a deck error, not skipped.
Each client can keep its own job store with --runs-dir (useful when several agents run in
parallel and should not see each other's jobs in list_jobs).
Metadata
Release files for mock-gkn-hpc 0.6.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| mock_gkn_hpc-0.6.0.tar.gz | 56.9 kB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| mock_gkn_hpc-0.6.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 74.2 kB
Release files / mock_gkn_hpc-0.6.0.tar.gz
| Download URL | mock_gkn_hpc-0.6.0.tar.gz |
|---|---|
| Size | 56.9 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
6c4cdfc4e3571075f032e42898fa75970004c976d0fe34c35c68a35945f3e717
|
|
BLAKE2b-256 checksum How to use checksums |
2446130380a111eabf530830f777415ccdebc652bf306fefa4250d10ea1ef407
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 1, 2026.
Transparency logRelease files / mock_gkn_hpc-0.6.0-py3-none-any.whl
| Download URL | mock_gkn_hpc-0.6.0-py3-none-any.whl |
|---|---|
| Size | 17.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
7a01ac5da4d1bbbad612cdd5c1a4ebc5aabf1ef125b0e5c47b4c6ea3e5b1b5b5
|
|
BLAKE2b-256 checksum How to use checksums |
5015a374f2cf2057c5e1ecfca35653a767b958f57f0eded84c77a9d6a9b6afc8
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 1, 2026.
Transparency logSecurity for mock-gkn-hpc 0.6.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for mock_gkn_hpc-0.6.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 1, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.