sciflow-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SCIFLOW_STORE | No | Path to the sciflow content-addressed artifact store. The README examples set this via the MCP client env configuration. |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_operationsA | List available operations with their input kinds and output kind. Optionally filter by category (intervals, series, filtering, peri-event, correlation, alignment). |
| describe_operationC | Full documentation and JSON schema of an operation's parameters. |
| import_dataB | Import a .npy/.npz/.mat/.csv file into the store and return its artifact id. Series: the array under |
| list_artifactsB | List every artifact in the store. |
| inspect_artifactA | Summarise an artifact (parametric axis and unit, shape, axes, extent, sample rate, NaN fraction) and how it was produced. Accepts a full id or a unique prefix. |
| register_datasetB | Register an experiment: {name, sessions: [{id, subject, attributes: {condition: ..., day: ...}, inputs: {: | {path, kind, options}}}]}. File inputs are imported (options are import_data's keyword arguments). Returns a content-derived dataset id that pins the exact data. |
| get_datasetC | A registered dataset's sessions, subjects, attributes and input artifact ids. With no id, lists datasets. |
| compare_artifactsA | Check whether two artifacts agree numerically, e.g. the same step run on a laptop and on a cluster. Ids are hashes of exact bytes, so different hardware can give different ids for results that agree to ~1e-15; this compares kind, axes, stamps, coordinates and data within |a - b| <= atol + rtol * |b|. |
| validate_workflowA | Statically check a workflow or pipeline (JSON object, YAML/JSON text, or file path): references, cycles, input/output kinds and parameters. Returns the execution order and each step's output kind; pipelines are compiled first (session steps appear as '__'). |
| run_workflowA | Run a workflow or pipeline locally. Steps whose (operation, version, params, inputs) already ran are
reused from cache unless |
| visualize_workflowA | Draw a workflow or pipeline: Mermaid flowchart text (render it for the user), or the node / edge graph as JSON for a visual editor. Pipelines show their session steps once, inside an 'each of N sessions' block, with the artifact kind on every edge. |
| get_runA | Full provenance record of a run (resolved workflow, environment and package versions, every step's params, inputs, outputs and cache key). With no run_id, lists recent runs. |
| export_workflowB | Compile a workflow or pipeline into cluster jobs that each run one step against a shared store (a pipeline's sessions run in parallel; its aggregate steps wait for all of them). slurm options: store_path, partition, time, mem, cpus, account, setup (shell lines, e.g. module load), sciflow_cmd, extra_sbatch. argo options: image, namespace, store_pvc, cpu, memory. |
| export_artifactC | Write an artifact to disk as .npz, .mat (Collate struct layout, readable in MATLAB), .csv, or 'table': a long-format CSV with one row per element and columns for every axis plus subject / condition / other attributes of stacked sessions (ready for mixed-effects models in R or statsmodels). |
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 14 tools
Most tools map to a distinct resource+action: operations (list/describe), artifacts (import/list/inspect/compare/export), datasets (register/get), workflows (validate/run/visualize/export) and runs (get_run). The only soft overlaps are the four *_workflow tools and three *_artifact tools, but their descriptions (static check vs. execute vs. draw vs. compile to cluster jobs; inspect vs. compare vs. write to disk) clearly separate them. get_dataset doubling as 'list datasets' when no id is given is a minor collision with list_artifacts.
Every tool follows a single snake_case verb_noun convention (list_operations, register_dataset, run_workflow, export_artifact). Verbs are reused consistently for the same intent (list_, get_, export_, *_workflow), making the surface predictable.
14 tools sits squarely in the well-scoped range and each one corresponds to a real lifecycle stage (discovery, import/store, dataset registration, workflow validate/run/visualize/export, provenance, artifact export). No obviously redundant or filler tools.
The core pipeline is covered end to end: discover operations, import data, register datasets, validate/run/visualize/export workflows, inspect provenance, and export results for R/statsmodels. Gaps are minor: no delete/prune for artifacts or datasets, no explicit in-memory artifact data read (only summary via inspect or disk write via export), and no workflow listing tool.