Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Inspect, author, validate, and run high-content microscopy workflows.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 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个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Python (uv)。
同一分类中有:Spec Driven Development, Remote Desktop Commander, dotnet-mcp
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况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.
MCP server for .NET symbols, XAML, source generators, and restricted workspace edit
按原文从作者的仓库复制。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
只显示了开头部分;其余内容请在仓库中阅读