Use this MCP server to read and manage a local research workflow database, connect questions to code and evidence, and prepare human-reviewed operations without executing them.
List projects and confirmed foundations, create independent projects, and read exact records or historical versions.
Get concise project/task context with completed facts, pending gaps, and suggested actions.
Find reusable code implementations before building new code; query exact outputs across runs without merging repeats.
Save research questions, hypotheses, stages, judgments, parent links, and intended spec/code implementation links.
Save experiments; register immutable code, runs, artifacts, protocols, datasets, conversations, and evaluations.
Save comparisons, analyses, and report revisions with fixed evidence and foundation snapshots.
Define method specs before implementation; register servers, repositories, and execution environments.
Track artifact reuse across experiments/projects and revoke usage links without deleting originals.
Append, query, and freeze process metrics under run-pinned contracts; missing values stay missing.
Propose foundation revisions, amendments, and Git/task operations for review.
Apply/dismiss certain proposals only through human-review paths; approvals do not execute commands.
Does not run models, launch tasks, execute arbitrary shell commands, or read arbitrary files; actual execution requires the explicit CLI executor and human confirmation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@research-workflow-studio Open my latest project, summarize its foundation, and suggest the next research step."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A visual, human-guided research workflow — from questions to reusable code, evidence and reports.
Website & interactive demo · English website · 简体中文 · Quick start · MCP
Research rarely follows a straight line. You explore a question, inspect intermediate outputs, reuse a control, change a method and compare again. Research Workflow Studio keeps those relationships visible without treating every case as a new code version or every result as a new research claim.
It is a local desktop web workbench with a Python backend, SQLite storage and an MCP server. An AI client can create and read structured records through MCP; an explicitly invoked command-line executor can run reviewed Git and task requests. You decide the research direction, conclusions and project-level changes.
View | What it helps you do |
Research | Read the project foundation, follow branching questions and hypotheses, see the current stage and reuse evidence. Exploration does not require an improvement hypothesis. |
Code & execution | Define inputs and outputs before implementation; follow training, inference, evaluation, analysis and report code separately. Inspect actual execution provenance when needed. |
Outputs & comparison | Use image grids, compatible curve overlays or scoped metric tables. Freeze selected process data before reusing it in an analysis or report; missing values stay missing. |
Saved comparisons are working selections. Analyses explain observations and their limits. Reports preserve the exact evidence and project context used at the time; new results do not rewrite old reports.
The walkthrough and desktop previews below show the 0.3 interface and use a separate fictional project with generated geometric shapes and manually specified example metrics. No private research data or model execution is involved.
Watch the project-to-workspace walkthrough
Research
Code & execution
Outputs & comparison
Related MCP server: universal-research-mcp
Requires Python 3.9+. Runtime has no third-party Python or JavaScript dependencies. The UI is designed for desktop browsers; interface text is currently Chinese.
git clone https://github.com/BorgDiven/research-workflow-studio.git
cd research-workflow-studio
mkdir -p .local
python3 tools/seed_showcase.py --db "$PWD/.local/showcase.sqlite3"
python3 launch.py serve --db "$PWD/.local/showcase.sqlite3" --port 8831Open http://127.0.0.1:8831. The showcase includes a project home, branching research questions, code roles, geometric illustrations, curves and fixed reports. Seeding is repeatable and refuses databases containing unrelated projects. It does not run a model or measure image quality.
For your own empty workspace, choose a different database path and skip the seed command:
python3 launch.py serve --db "$PWD/.local/my-research.sqlite3" --port 8831Optional CLI installation in your Python virtual environment from this checkout: python3 -m pip install ., then research-workflow-studio serve --db /absolute/path/studio.sqlite3. Source-based development templates remain in this repository.
MCP is the structured tool interface between an AI client and Studio. Configure a stdio MCP server using your actual absolute paths:
{
"mcpServers": {
"research-workflow-studio": {
"command": "python3",
"args": [
"/absolute/path/research-workflow-studio/launch.py", "mcp",
"--db", "/absolute/path/studio.sqlite3",
"--web-url", "http://127.0.0.1:8831"
]
}
}
}The browser service and MCP process must use the same database. Adapt the configuration wrapper to your client, reconnect it and inspect its loaded tools. MCP configuration alone does not start the web server.
A useful first prompt:
Open my project in Research Workflow Studio. Read its foundation and current research context. Tell me what is already recorded, what is missing and the next useful action. Before implementing a method, find reusable code and agree on a specification. Do not execute an experiment or approve a scientific decision without my instruction.
The 37 advertised MCP tools let the model read context, manage research records, append/query process metrics, freeze evidence, register repositories/environments and propose concrete Git or task requests. Mutations such as starting or stopping a task, committing or pushing require a separate human confirmation. Read-only inspections can be claimed directly by the explicit CLI executor. Neither MCP registration nor approval executes a command; there is no arbitrary-shell or arbitrary-file-read MCP tool. See the current tool schemas and the 0.4 contract.
Inspect code without losing the research context. Related-code navigation highlights exact implementations and specifications. Details stay in the right column; cancelling highlights preserves the research context and current code selection.
Declare a process metric on the code specification, then batch its observations from your script. The workbench preserves metric identity, units, axis, data scope and the exact protocol/specification. Incompatible or unknown scopes stay separate; gaps are not zeroes. Switch between images, curves and metrics in the same output view.
Use tools/track_metrics.py for JSONL input or an explicitly selected MLflow HTTP history. Its local spool supports retries. MLflow import reads run-scoped metrics only; supply declared splits with --mlflow-split and use JSONL for explicit per-sample data. It does not install, discover, control or take over an MLflow service. Save a fixed metric-history artifact before using process data in a comparison, analysis or report. Usage and formats
Open 仓库与运行环境 (Repositories & environments) in the project. Register an existing local checkout or SSH alias, and pin the repository/environment on a run. Request a Git action or task, review its exact arguments, then copy the generated executor command to the Studio host's terminal:
python3 launch.py operate --db /absolute/path/studio.sqlite3 \
--project-id example-project --operation-id operation-example --version 2The identifiers above are fictional placeholders. Use the exact revision shown by your real request. This is an execution command, not a preview. The runner claims one request, checks the fixed source commit and records its receipt. Unknown launch outcomes are not retried automatically. Remote SSH behavior has been checked with mocked transport; a real server still needs its own explicit integration check. Execution and tracking clients target POSIX systems such as macOS/Linux.
python3 tools/scaffold.py --kind inference --destination .local/my-method --title "My method"
python3 tools/check_block.py .local/my-method --output .local/check.jsonThe checker is static by default. Add --execute only when you intend to execute that block locally. The supplied templates use small standard-library synthetic fixtures, with no model downloads or GPU usage.
A specification declares purpose, input/output semantics, configurable values, dependencies and acceptance checks. A registered implementation pins a ready specification revision, repository, Git commit, module path, entrypoint and supplied check evidence. Cases and ordinary parameter changes belong in inputs/configuration. See the five templates and contributor rules.
Question ≠ implementation lineage. A baseline can support several questions without changing its origin.
Declare purpose before running. Link a question to a code specification or existing implementation, then navigate both ways. Planned purpose, actual use and reused evidence remain distinguishable; see the relationship contract.
Artifact origin stays fixed. Reusing an image in another experiment or project adds a reference, not a new producer.
An execution may cover several cases or settings. Each artifact carries its actual configuration and output semantics. Execution details are available without another visible grouping layer.
Final output ≠ diagnostic output. A predicted clean image, velocity field, curve and metric table can be compared as the corresponding kind of evidence.
Corrections are audited. Approved amendments preserve the original record; previously frozen reports retain their original snapshot.
A completed run ≠ a supported hypothesis. Scientific judgments and project-foundation changes remain human decisions.
Comparisons and enlarged images use a separate reading copy. Managed PDF reports open a reading edition, while original downloads stay inside material details. The local cache has a configurable size limit; originals and fixed evidence are never eviction targets. You can keep everything locally or put originals on a separate volume without changing material links.
Image conversion is optional: install .[previews]; add .[pdf-readings] for reading PDFs. Missing converters show unavailable reading content instead of silently downloading originals. See storage, retention and reading copies.
The service binds to loopback. It supports an explicitly configured Tailscale Serve proxy for private cross-device use; see deployment. Real projects, SQLite files and managed materials stay on your server. This public repository contains software and synthetic examples, not a public hosted workspace.
Version 0.5.1 is an early, single-user workbench. It has no collaborative multi-user permissions, cloud synchronization, automatic experiment scheduler or mobile layout. Supplied check evidence is recorded, not independently certified. Review changes and keep a database backup when upgrading.
python3 -m unittest discover -s tests
node --test web/tests/*.test.jsSee usage, data formats, changes, architecture and contributing. Issues describing a concrete workflow are welcome.
MIT licensed. The title illustration and demo contact sheet are AI-generated branding/illustration assets, not experimental evidence; asset provenance.
Human-only approval of an exact pending amendment. Raw records and previous report snapshots remain unchanged.
Inputs: projectId (required), requestId (required), amendmentRef (required), expectedRevision (required).
Human-only dismissal of an exact pending amendment. Keeps the proposal history without applying its patch.
Inputs: projectId (required), requestId (required), amendmentRef (required), expectedRevision (required).
Propose an audited metadata/source/lineage/recovery correction for an exact record. Does not rewrite the source or approve the correction.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Save observations, interpretation and limitations; manual analysis may omit code.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Register an immutable output with its actual producer and configuration. For a legacy output with unresolved provenance, explicitly set provenance=unresolved with source evidence and a description; never invent a producer run. Does not read arbitrary files.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Find existing implementations before building new code. Returns exact identities and declared contracts; supplied check evidence is not independent verification.
Inputs: projectId (required), kind, limit, query, +1 more.
Register an immutable code identity and explicit parent references; never reads or runs the path.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Save exact comparison inputs and fixed/varying conditions without moving their original producers.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Register an existing conversation reference; does not create or send a chat.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Register an immutable dataset version and exact sample IDs.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Register a versioned execution directory and Python executable in the registered checkout. Does not execute or probe.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Validate and register existing typed evaluation results with fixed protocol/code/input versions; does not compute metrics.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Save an experiment and bind its confirmed project foundation; does not execute it.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Read concise project/task context, completed facts, pending gaps and suggested actions. Suggestions are not execution authorization.
Inputs: projectId (required), researchRef, experimentRef, selectionRefs.
Append actual process measurements in batches under the run's pinned processMetrics contract. Identical points deduplicate; conflicting values never overwrite. Does not run a model.
Inputs: points (required), runRef (required), projectId (required), requestId (required), +2 more.
Read bounded process series and compatible alignments. Reuse throughSequence on every page; null stays missing, with no interpolation.
Inputs: runRefs (required), projectId (required), toX, fromX, +4 more.
Freeze the selected run metrics through a previously read sequence into one immutable metric-history artifact. Includes complete definitions and points; rejects over 5000 points instead of silently truncating.
Inputs: title (required), runRef (required), projectId (required), requestId (required), +5 more.
Human only: approve this exact operation plan. Approval never launches it.
Inputs: projectId (required), requestId (required), operationRef (required), expectedRevision (required).
Human only: dismiss this exact operation plan. Approval never launches it.
Inputs: projectId (required), requestId (required), operationRef (required), expectedRevision (required).
Propose a literal reviewed Git/task operation. No execution occurs. Read-only inspections may be claimed by an explicit local runner; workspace/process mutations need exact human approval.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Human review only. MCP cannot approve its own suggestion; use the application review screen.
Inputs: projectId (required), requestId (required), proposalRef (required), baseRevision (required), +1 more.
Human review only. MCP cannot approve its own suggestion; use the application review screen.
Inputs: projectId (required), requestId (required), proposalRef (required), baseRevision (required), +1 more.
Save a proposed foundation revision for human review; this does not apply it.
Inputs: fields (required), reason (required), projectId (required), requestId (required), +3 more.
Create an independent project and its initial confirmed foundation; no demonstration records are inherited.
Inputs: name (required), requestId (required), demo, goal, +2 more.
List projects and confirmed foundations.
Inputs: no named parameters.
Human-only current-stage decision. Browsing and completed runs never advance stages.
Inputs: projectId (required), requestId (required), activeStages (required), expectedRevision (required).
Register immutable evaluation metric definitions, preprocessing, aggregation and missing-data policy.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Read one exact record or historical version.
Inputs: ref (required).
Create a report version with immutable foundation and transitive evidence snapshots.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Register an existing checkout and its exact server reference. Does not clone, inspect or change Git.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Save a research question or optional hypothesis. implementationLinks declares intended uses of exact spec/code revisions before execution; these links are not evidence and do not decide scientific validity.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Find exact outputs across runs in this project. Retains producer, case, configuration and observation coordinates; never silently merges repeats.
Inputs: projectId (required), limit, offset, codeRefs, +2 more.
Record an actual run and status. Registration never launches a program; producer bindings are immutable.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Register a versioned local/SSH workspace using an SSH alias, never credentials. Registration does not connect.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Define a method-level contract before implementation. Saves a new draft or ready revision; implementations pin an exact ready revision. Cases/configurations belong to runs, not method contracts.
Inputs: record (required), projectId (required), requestId (required), expectedRevision (required).
Revoke a material usage without deleting source artifacts or other uses.
Inputs: id (required), projectId (required), requestId (required), expectedRevision (required).
Reference precise artifacts in a target experiment, including cross-project reuse. Original producer remains unchanged.
Inputs: role (required), projectId (required), requestId (required), artifactRefs (required), +4 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 37 tools
Most tools target a distinct entity or lifecycle action, and the descriptions clarify boundaries between registration, querying, proposal, and human-only approval. There is still some potential confusion among the many save/register/propose variants and the three propose/apply/dismiss triads, but the domain objects remain distinguishable.
The naming is overwhelmingly consistent: an rws_ prefix plus snake_case entity/action names such as rws_project_create and rws_run_register. A few outliers like rws_get_context, rws_report_create_revision, and rws_project_stages_set break the dominant noun_verb pattern but remain readable.
37 tools is heavy for an MCP surface, even for a broad research lifecycle. Several lifecycle stages are fragmented into multiple tools, especially the propose/apply/dismiss triads, and consolidation would reduce the surface without losing core capability.
The surface covers a wide research workflow: project setup, records, code, runs, artifacts, datasets, evaluations, reports, metrics, proposals, and human approvals. Minor gaps remain around explicit retrieval or listing for some entity types, but generic record access and query tools mitigate most dead ends.
Read-only MCP over the LivingMeta AI-in-Research corpus: 12,400 papers, gaps, priority agenda.
AI-powered bioprotocol optimization — generate, search, and manage lab protocols via MCP
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Plan and verify evidence-aware research workflows with specialist execution receipts.
