Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Inspect, author, validate, and run high-content microscopy workflows.
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Du brauchst
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Öffne Claude Desktop → Settings → Developer → Edit Config und füge dies in claude_desktop_config.json ein
{
"mcpServers": {
"openhcs": {
"command": "uvx",
"args": [
"openhcs",
"mcp"
]
}
}
}Führe das in deinem Terminal aus
claude mcp add openhcs -- uvx openhcs mcpIn .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"openhcs": {
"command": "uvx",
"args": [
"openhcs",
"mcp"
]
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
In .vscode/mcp.json in deinem Projekt einfügen
{
"servers": {
"openhcs": {
"type": "stdio",
"command": "uvx",
"args": [
"openhcs",
"mcp"
]
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Dieser Server läuft auf deinem Computer, und ChatGPT kann sich nur mit Servern im Internet verbinden. Wähle eine andere App.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 6. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto OpenHCSDev bestätigt, dem das Repo gehört
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (0.8.6) kam vor 2 Monaten in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du Python (uv) auf deinem Computer.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, AI Deprecations
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
AI model shutdown dates, replacements, change feed and webhook alerts for 8 providers.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
OpenHCS
Turn high-content microscopy images into reproducible measurements\ One reviewable workflow across the GUI, Python, CellProfiler, and local agents
OpenHCS is designed for imaging scientists and research software teams running high-content studies where many wells, sites, channels, Z planes, or time points must be analysed consistently. Source selection, processing steps, and result definitions stay together in one validated pipeline instead of being split across interface-only state, scripts, and automation.
It is a good fit when a workflow must remain reviewable across visual editing, code, and automation. The same pipeline can be edited in the desktop GUI or as Python, imported from supported CellProfiler .cppipe files, and built or reviewed through the local MCP surface.
Windows installer · macOS installer · Installation options
The graphical installers set up an isolated CPU-safe desktop environment with the OpenHCS GUI, CellProfiler compatibility, local MCP server, Napari, Fiji/ImageJ, and Bio-Formats. GPU libraries remain optional.
Browse the UI and viewer gallery · Watch an agent build, debug, run, and inspect a workflow
OpenHCS processes large microscopy datasets with a compile-then-execute architecture. Pipelines are validated across the selected execution axes *before* processing starts, preventing late failures after expensive work. Design pipelines in the GUI, export to Python, edit as code, and re-import — switching between visual and programmatic workflows. The local MCP exposes that same workflow model to supported agents, so agent-authored pipelines remain visible, editable, and reviewable in the GUI and generated Python.
graph LR
subgraph Sources IX[ImageXpress] OP[Opera Phenix] BF[Bio-Formats] OM[OMERO] end
subgraph OpenHCS Platform PD["Pipeline Designer (GUI ⇄ Code ⇄ Agent)"] CO["Typed Compiler (resolve + validate)"] EX["Bounded Worker Executor (well scheduling · multi-GPU)"] FN["Registry-Discovered Functions scikit-image · CuPy · pyclesperanto PyTorch · JAX · TF · CuCIM · custom"] PS["PolyStore (Memory ↔ Disk ↔ Zarr ↔ Stream)"] end
subgraph Viewers NA[Napari] FJ[Fiji/ImageJ] end
IX --> PD OP --> PD BF --> PD OM --> PD PD --> CO --> EX EX --> FN --> PS PS --> NA PS --> FJ
Configuration is resolved once into step snapshots and a compilation session. Typed plans then validate sources, artifacts, materialization, memory contracts, and worker requirements before execution begins. Errors surface immediately, not after hours of processing.
Design pipelines visually, export as executable Python, edit in your IDE, re-import to the GUI. Code generation works at any scope level — function patterns, individual steps, pipeline configs, full orchestrator scripts — any window holding objects can generate and re-import code.
Give a supported MCP client a microscopy folder or plate and an analysis goal. It can inspect the connected execution server's functions, build and validate a typed pipeline, run it, inspect results in OpenHCS or a viewer, and revise the generated Python.
Bounded worker lanes use ProcessPoolExecutor by default, with deterministic well assignment and sequential processing inside each lane. Compiled callable contracts select framework-local GPU devices independently; single-worker and debugging configurations can use inline or threaded execution.
Register any Python function by decorating it with @numpy, @cupy, @pyclesperanto, @torch, or another memory-type decorator. Custom functions receive contract validation, UI integration, multiprocessing-safe import identity, and the same server-owned catalog projection as built-in functions. Persisted functions live in the platform-specific OpenHCS user-data directory.
Callable and module artifact contracts declare semantic outputs independently of Python argument names. The artifact graph and materialization plans route images, measurements, object labels, relationships, tables, and files to their configured stores and exporters.
Stream images to Napari and Fiji/ImageJ in real time during pipeline execution. OpenHCS StreamingConfig declarations and viewer adapters own identity, display, and persistence policy. PolyStore builds generic storage and streaming payloads; ZMQRuntime supplies process-isolated transport, readiness, acknowledgments, and lifecycle.
Edit a value in GlobalPipelineConfig — watch it propagate in real-time to PipelineConfig and StepConfig windows. Dual-axis resolution (context hierarchy × class MRO) with scope isolation per orchestrator.
Open .cppipe files in the desktop application or lower them from Python into ordinary PipelineConfig and FunctionStep declarations. Named images, objects, measurements, relationships, and exports use the same typed compiler and runtime as native OpenHCS pipelines. The source-backed Official30 suite continuously exercises 30 pipelines from CellProfiler examples, tutorials, and benchmark supplements under explicit equivalence policies.
Use the local stdio MCP server with ChatGPT desktop, Codex, Claude Desktop, and other supported clients, or deploy the separately secured HTTP surface. The graphical installers register detected local clients automatically. Capability profiles, schemas, knowledge, UI attachment, authoring, execution, runtime inspection, viewer review, and governed custom-function registration are projected from typed authorities rather than duplicated tool lists.
OpenHCS is built on 8 purpose-extracted, separately published libraries — each solving a general problem and all composed into one platform:
graph TD
OH["OpenHCS Platform (domain wiring + pipelines)"]
OH --> OS["ObjectState (config)"] OH --> AB["ArrayBridge (arrays)"] OH --> PS["PolyStore (I/O + streaming)"] OH --> ZR["ZMQRuntime (exec)"] OH --> QR["PyQT-reactive (Qt forms)"] OH --> FB["formbridge (form model + UI bridge)"] QR --> FB
OS --> PI["python-introspect (signatures)"] OH --> MR["metaclass-registry (plugins)"] OH --> PC["pycodify (serialization)"]
| Library | Role in OpenHCS | What It Does |
|---|---|---|
| ObjectState | Configuration framework | Lazy dataclasses with dual-axis inheritance (context hierarchy × class MRO) and contextvars-based resolution |
| ArrayBridge | Memory type conversion | Unified API across NumPy, CuPy, PyTorch, JAX, TensorFlow, pyclesperanto with DLPack zero-copy transfers |
| PolyStore | Unified I/O & stream payloads | Generic storage and streaming payload primitives, backend lifecycle, virtual workspaces, atomic writes, format detection, and ROI extraction |
| ZMQRuntime | Process & transport runtime | Generic request, status, progress, cancellation, process-lifecycle, and viewer-control transport protocols |
| PyQT-reactive | UI form generation | React-style reactive forms from dataclasses with cross-window sync and flash animations |
| formbridge | Toolkit-neutral forms and UI bridge | The form model, help and code documents, and the running-UI bridge contracts, client and server; imports no GUI toolkit, so headless MCP uses it without Qt |
| pycodify | Code ↔ object conversion | Python source as serialization format — type-preserving, diffable, editable, with collision handling |
| python-introspect | Signature analysis | Pure-Python function/dataclass introspection for automatic UI generation and contract analysis |
| metaclass-registry | Plugin discovery | Zero-boilerplate registry system powering microscope handler and storage backend auto-discovery |
Image Sources
| Source | Support |
|---|---|
| ImageXpress | Native plate and metadata handling |
| Opera Phenix | Native plate and metadata handling |
| Bio-Formats | Arbitrary folders and supported microscopy containers |
| OMERO | Remote image and metadata access |
| OpenHCS format | Native generated and materialized plates |
Source handlers are auto-detected and extensible through metaclass-registry.
Functions — Automatic Discovery
| Library or route | Execution memory |
|---|---|
| scikit-image and OpenHCS native | NumPy / CPU |
| pyclesperanto | OpenCL GPU |
| CuPy and cuCIM | CUDA GPU |
| PyTorch, JAX, and TensorFlow functions | Declared CPU/GPU arrays |
| User custom functions | Declared by their memory-type decorator |
The connected execution server owns the available catalog, so remote GPU and custom-function availability is reflected without a manually maintained list. ArrayBridge provides compatible memory conversion, including zero-copy paths where supported.
Processing domains: image preprocessing · segmentation · cell counting · stitching (MIST + Ashlar GPU) · neurite tracing · morphology · measurements
Dimensionality is function-defined rather than a global mode: true volumetric segmentation and measurement routes coexist with plane-local functions, whose labels are not silently stitched across Z. See the [dimensionality and measurement capabil
Nur der Anfang wird gezeigt; den Rest findest du im Repo