Skip to main content
Glama
Konjkov

casino-mcp

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
casino_runA

Start a CASINO calculation in workdir and return immediately.

The runtype (vmc, vmc_opt, vmc_dmc, ...) comes from the input file in workdir; this tool only decides how the binary is launched. The calculation keeps running after the call returns and after this server is restarted.

A directory that already holds an out is refused, because runqmc appends to it and the result is two runs in one file. restart and resume are the two ways past that, and they are opposites -- pass one.

workdir: directory holding input and the wave function files. nproc: number of MPI processes (vmc_nstep in input is the total over all of them). version: binary flavour, 'opt' or 'debug'. restart: delete out and everything else the earlier run left -- .hist files, configs, optimisation output -- and start the calculation over. Inputs are kept. Destructive: config.in goes too, so what could have been continued no longer can be. Refused on a directory whose input haltqmc has set up to continue (NEWRUN : F), because CASINO then wants the config.in this would delete; casino_stop keeps a copy of the input as it was, and the reply to the stop says where. resume: carry the interrupted run on, keeping the work already done. Which of CASINO's two continuation routes that takes is read out of out, not chosen here: a run that CASINO stopped on max_cpu_time / max_real_time is continued by runqmc --continue, and a run that casino_stop halted is continued by a plain runqmc over the input that haltqmc -u rewrote. The reply says which one under resume. A run that reached its own end is refused -- there is nothing to continue. unlock: clear a stale .runqmc.lock left by a runqmc instance that died.

casino_prepareA

Copy a calculation into a new directory and write the input for the next run in it.

This is how a calculation becomes the next one: optimise a wave function, then prepare a vmc_dmc directory beside it; halve the timestep into another; change the target weight into a third. A copy rather than an edit, because a number whose input was overwritten in place can no longer be reproduced, and because casino_run refuses a directory that already holds a run -- rightly.

What is copied is what a calculation is given and never what a run produced: input, the orbital file, correlation.data, parameters.casl, the pseudopotentials, and config.in (which a dmc-only or opt runtype reads as an input). Not out, not the .hist files, not config.out. A symlinked orbital file is copied by content, so the new directory stands on its own.

runtype: the runtype the new directory is for -- vmc, vmc_opt, opt, vmc_dmc, vmc_dmc_equil, dmc_dmc, dmc_equil, dmc_stats. Every keyword that runtype needs and the source input does not set is filled from a working default; every keyword the source does set is kept, so the electron count, the basis and any hand tuning survive. Leave it empty to keep the source's runtype and only apply overrides. overrides: keywords to set, as {name: value}, and they win over both the source and the defaults. A null value deletes the keyword; a value containing newlines is written as a %block (that is how opt_plan and npcell are set). Values are written verbatim, so booleans are 'T' and 'F' as CASINO spells them. jastrow: the terms of a blank Jastrow factor to write into the new directory -- ['u', 'chi', 'f'] for the usual one, ['u'] for a system with no atoms. This is for the first calculation of a chain, the one whose directory holds an orbital file and nothing else: use_jastrow : T needs a correlation.data, no CASINO utility writes one, and the manual's own instruction is to copy an example and delete its numbers by hand. Every coefficient starts at zero, which is what the first optimisation cycle is for. Leave it unset when the source already has a correlation.data; asking for both is refused, because a blank Jastrow would discard an optimised one. Finite systems only so far: a periodic Jastrow wants a P term, whose stars come from CASINO's own make_p_stars. backflow: the terms of a blank backflow function, in the same file -- ['eta', 'mu', 'phi'] for the usual one. It goes with backflow : T in the input, and the two blocks are written together for a calculation that wants both. The electron-nucleus cusp type of each set is not a setting: it is read off the pseudopotentials in the directory, 1 for a bare nucleus and 0 behind a pseudopotential, because CASINO believes the flag without checking it. No AE CUTOFFS section is written -- it is optional, and CASINO chooses the lengths itself. jastrow_settings: the shape of both blocks, where the defaults are not wanted. Jastrow: trunc_order (3), n_u (8), n_chi (8), n_f_en (3), n_f_ee (3), spin_dep_u (1), spin_dep_chi (0), spin_dep_f (1), cusp_chi (0), cutoff_u / cutoff_chi / cutoff_f (0, which CASINO reads as "use your own default"), no_dup_u (0), no_dup_chi (0), optimizable (1, the cutoffs). Backflow: bf_trunc_order (3), n_eta (9), n_mu (9), n_phi_en (3), n_phi_ee (3), spin_dep_eta (1), spin_dep_mu (0), spin_dep_phi (1), cutoff_eta / cutoff_mu / cutoff_phi (0), irrotational (0), cusp_bf (-1, meaning derive it from the pseudopotentials).

Nothing is written unless the result would actually run: the keyword combinations CASINO only rejects at run time are checked first (an optimisation sample smaller than the DMC target weight, opt_backflow without backflow, a missing mandatory keyword), and so is the presence of every file the input tells CASINO to read. A refusal names the problems and creates no directory. What is legal but probably unintended -- a dtdmc still at CASINO's placeholder default, dmc_stats_nstep not divisible by its block count, keywords left over from the runtype this was copied from -- comes back in warnings and does not stop it.

casino_statusA

State of one job: running / finished / failed / stopped, pid, runtime in seconds, exit code.

casino_resultsA

Physics out of a job's files: energies, error bars, variance, per-block numbers.

Reads out and returns it as phases, because a CASINO run is a sequence of them and not one result: vmc_opt writes a VMC and an optimization phase per cycle, vmc_dmc writes VMC, DMC equilibration and DMC statistics accumulation. result points at the number that is this run's answer, and every value carries the file and line it was read from. Nothing is computed here that CASINO did not print, and a value it did not print comes back as null with the reason.

A DMC run that has not ended is readable too, and this is the only way to read one: CASINO writes the mixed estimators into out at the very end, and until then the current estimate lives in dmc.status, which it rewrites after every statistics block and deletes when the run finishes. When that file is there it is parsed into dmc_status and result points at it, so a running job answers with the estimate as of its last block -- and never with the VMC energy of the configuration-generation phase, which is the trial wave function's and not the calculation's. A run stopped by casino_stop keeps its dmc.status, so the last estimate it reached survives the stop.

While the run is still equilibrating there is no DMC energy anywhere yet, and result then says so rather than answering with an earlier phase.

casino_list_jobsC

Every known job, newest first, with its current state.

casino_stopA

Stop a running calculation and leave its directory ready to be continued.

SIGTERM goes to this job's casino processes, as haltqmc -k does for the whole account, so runqmc stays alive to finish writing out. CASINO has no graceful-halt signal: the blocks it had finished stay in out, vmc.hist and dmc.hist, the current block is lost. Then haltqmc -f -u tidies the directory -- config.out to config.in, the lock file, and input rewritten for the work that is left -- so casino_run(workdir, resume=true) carries this calculation on.

timeout: seconds the job gets to end on its own before the process group is killed.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 6 tools

Disambiguation5/5

Each tool addresses a distinct lifecycle stage: preparing a directory, launching/interrupting a run, listing/checking jobs, and extracting physics results. Status and list_jobs are adjacent, but one is explicitly per-job detail while the other is an overview, so there is no real ambiguity.

Naming Consistency4/5

All tools share the casino_ prefix and use snake_case, but the pattern mixes simple verbs (run, prepare, stop), a verb-object phrase (list_jobs), and bare nouns (status, results). This is readable and predictable, though not a uniform verb_noun convention.

Tool Count5/5

Six tools is a well-scoped set for a job-management server. Each tool covers a necessary action without redundancy, and the count sits comfortably in the ideal 3-15 range.

Completeness5/5

The tool surface covers the full CASINO workflow: prepare a calculation, run or restart it, monitor it, stop it, and retrieve physics results. Missing cleanup or job-forgetting operations are not essential to the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues