Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者による説明(英語の原文)
Inspect, author, validate, and run high-content microscopy workflows.
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
使っているAIアプリを選んで、設定をコピーしてください。
必要なもの
どのアプリを使っていますか?
上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。
Claude Desktop → Settings → Developer → Edit Config を開き、claude_desktop_config.json にこれを貼り付けます
{
"mcpServers": {
"openhcs": {
"command": "uvx",
"args": [
"openhcs",
"mcp"
]
}
}
}ターミナルでこれを実行します
claude mcp add openhcs -- uvx openhcs mcpプロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます
{
"mcpServers": {
"openhcs": {
"command": "uvx",
"args": [
"openhcs",
"mcp"
]
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
プロジェクトの .vscode/mcp.json に貼り付けます
{
"servers": {
"openhcs": {
"type": "stdio",
"command": "uvx",
"args": [
"openhcs",
"mcp"
]
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
これはパソコンで動くサーバーですが、ChatGPTがつなげるのはインターネット上のサーバーだけです。ほかのアプリを選んでください。
選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。
この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。
パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月6日にチェック
レジストリ名は、リポジトリを所有するGitHubアカウント OpenHCSDev で確認済みです
このリポジトリはまだGitHubから読み取っていません
このリポジトリはまだGitHubから読み取っていません
これはパソコンで動くため、インターネット上のエンドポイントはありません
パソコンで動き、代わりにローカルの設定を使います
パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。
あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません(サーバー自体がオンラインサービスを呼び出す場合を除きます)。
GitHubリポジトリの最終更新は–、最新バージョン(0.8.6)がレジストリに届いたのは2 か月前です。
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにPython (uv)も必要です。
同じカテゴリには:Spec Driven Development, Remote Desktop Commander, AI Deprecations
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i
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.
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
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
冒頭だけを表示しています。続きはリポジトリで読めます