Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
คำอธิบายจากผู้ทำ (ภาษาอังกฤษตามต้นฉบับ)
Inspect, author, validate, and run high-content microscopy workflows.
สามเรื่องนี้ไม่รวมเป็นคะแนนเดียว เพราะความเห็น การวัด และความนิยม เป็นคนละเรื่องกัน
ตัวนี้ยังไม่ได้เรียบเรียงเป็นภาษาไทย ด้านล่างคือข้อเท็จจริงที่เราอ่านจาก registry
เลือกโปรแกรม AI ที่คุณใช้ แล้วคัดลอกค่าตั้งไปวาง
ต้องเตรียมก่อน
คุณใช้แอปไหน
เลือกแอปด้านบน เราจำไว้ให้ ครั้งหน้าปุ่มจะขึ้นว่า “ติดตั้งลง …”
เปิด Claude Desktop → Settings → Developer → Edit Config แล้ววางค่านี้ในไฟล์ claude_desktop_config.json
{
"mcpServers": {
"openhcs": {
"command": "uvx",
"args": [
"openhcs",
"mcp"
]
}
}
}พิมพ์คำสั่งนี้ใน Terminal
claude mcp add openhcs -- uvx openhcs mcpวางในไฟล์ .cursor/mcp.json ของโปรเจกต์ หรือ ~/.cursor/mcp.json
{
"mcpServers": {
"openhcs": {
"command": "uvx",
"args": [
"openhcs",
"mcp"
]
}
}
}เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง
วางในไฟล์ .vscode/mcp.json ของโปรเจกต์
{
"servers": {
"openhcs": {
"type": "stdio",
"command": "uvx",
"args": [
"openhcs",
"mcp"
]
}
}
}เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง
ตัวนี้รันในเครื่องคุณ แต่ ChatGPT ต่อได้เฉพาะ server บนอินเทอร์เน็ต ลองเลือกแอปอื่น
ตัวเลือกเก็บในคุกกี้บนเครื่องนี้ ไม่ต้องมีบัญชี
ค่าตั้งนี้สร้างจากข้อมูลใน registry ของผู้ทำ ถ้าไม่ตรงกับ README ให้เชื่อ README
รันในเครื่องคุณ รายการเครื่องมือจะขึ้นในแอป AI หลังติดตั้ง
เราตรวจจากข้อมูลที่ใครก็เปิดดูได้ ยังไม่ได้อ่านโค้ด ข้อที่ไม่เกี่ยวกับตัวนี้ไม่นับในตัวหาร · ตรวจเมื่อ 6 พ.ย. 2569
ชื่อใน registry ยืนยันด้วยบัญชี GitHub OpenHCSDev ซึ่งเป็นเจ้าของ repo
ยังไม่ได้อ่านข้อมูล repo จาก GitHub
ยังไม่ได้อ่านข้อมูล repo จาก GitHub
ตัวนี้รันบนเครื่องคุณ ไม่มี endpoint บนอินเทอร์เน็ต
ตัวนี้รันบนเครื่อง ใช้ค่าที่ตั้งในเครื่องแทน
รันในเครื่องคุณ เราอ่านรายการเครื่องมือได้เฉพาะตัวที่มี endpoint บนอินเทอร์เน็ต
เทียบกับทุก server ที่ยังใช้งานในหมวดนี้ทั้งทะเบียน ดาวนับเฉพาะเมื่อผู้ลงทะเบียนเป็นเจ้าของ repo
จากการตรวจเบื้องต้นของเรา ผ่าน 1 จาก 1 ข้อที่ตรวจได้ เรายังไม่ได้อ่านโค้ด ก่อนใส่กุญแจหรือ token ให้ดูว่า server ขอสิทธิ์อะไร และเลือกกุญแจที่ทำได้เท่าที่จำเป็น
registry ไม่ได้ระบุว่าต้องใช้กุญแจ แต่บางตัวจะขอให้ล็อกอินตอนใช้ครั้งแรก
รันบนเครื่องของคุณ โปรแกรม AI จะเปิด server ขึ้นมาเองเมื่อใช้ ข้อมูลไม่ต้องผ่านเซิร์ฟเวอร์ของผู้ทำ (ยกเว้นตัวที่ไปเรียกบริการออนไลน์ต่อ)
repo บน GitHub มีการแก้โค้ดล่าสุด – และส่งรุ่นล่าสุด (0.8.6) เข้า registry 2 เดือนที่ผ่านมา
โปรแกรมที่รองรับ MCP เช่น Claude Desktop, Claude Code, Cursor และ VS Code ตัวนี้ต้องมี Python (uv) ในเครื่องด้วย
ในหมวดเดียวกันมี Spec Driven Development, Remote Desktop Commander, AI Deprecations
server หมวดเดียวกันจากผู้ทำคนอื่น เรียงตามดาว
อ่านการ์ด:★ ดาว GitHubiสามเสา: รีวิว · ผลตรวจ · การใช้งานiอัปเดต = วันที่ส่งรุ่นล่าสุดเข้า registryi
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.
ส่วนนี้คัดจาก repo ของผู้ทำตามต้นฉบับ 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
ตัดมาแค่ช่วงต้น อ่านต่อใน repo