Biofact
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| record_stepA | Record one executed analysis step under a named run. Hashes (SHA-256) every listed input/output file. Use this AFTER running a tool so the agent's work becomes auditable and replayable. The first call for a run_name creates the run; later calls append steps. |
| validate_fileB | Validate a bioinformatics file (FASTA, FASTQ, VCF, BED, GFF, CSV, TSV, JSON). Returns validity, record count, and up to 5 issues. Catches truncation, FASTQ length mismatches, broken VCF headers, ragged tables. |
| check_runB | Verify a run record: do the recorded files still exist, and do their hashes still match what was recorded? Detects silent data drift. |
| replay_runB | Re-execute every recorded command in a run and compare output hashes. Returns per-step reproduction status. True reproducibility = same exit codes AND identical output content hashes. |
| provenance_reportB | Print the provenance report for a run: steps, tools used, files hashed, environment, timings. Cite this in a manuscript's methods/availability. |
| list_stored_runsA | List all recorded runs in the Biofact store (newest first). |
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 6 tools
Each tool targets a distinct action on the run/provenance domain: record_step writes, list_stored_runs enumerates, check_run verifies file hashes, replay_run re-executes for reproducibility, provenance_report summarizes, and validate_file inspects file format. The verification-flavored tools (check_run vs replay_run vs validate_file) could be momentarily confused, but their descriptions clearly separate drift-checking, re-execution, and format validation.
Mostly consistent verb_noun: replay_run, record_step, validate_file, check_run, list_stored_runs. The only deviation is provenance_report, which is a noun_noun form rather than a verb-led name, but it remains readable and predictable.
Six tools is well-scoped for a provenance/reproducibility server, with each tool earning its place along the record-list-check-replay-report-validate axis. No redundant or trivial tools, and no padding.
The run lifecycle is well covered: recording, listing, integrity checking, replay, reporting, and file validation. Minor gaps exist, such as no delete/prune run, no export/import, and no way to amend or annotate a recorded step, but agents can work around these.