ZenML

MCP Server สำหรับ ZenML

โปรเจกต์นี้ติดตั้งเซิร์ฟเวอร์ Model Context Protocol (MCP) สำหรับโต้ตอบกับ API ของ ZenML

MCP คืออะไร?

Model Context Protocol (MCP) เป็นโปรโตคอลแบบเปิดที่กำหนดมาตรฐานวิธีที่ แอปพลิเคชันจัดเตรียมบริบทให้กับ Large Language Models (LLMs) โดยทำหน้าที่เสมือน "พอร์ต USB-C สำหรับแอปพลิเคชัน AI" ซึ่งเป็นวิธีมาตรฐานในการเชื่อมต่อโมเดล AI กับแหล่งข้อมูลและเครื่องมือต่าง ๆ

MCP ใช้สถาปัตยกรรมไคลเอ็นต์-เซิร์ฟเวอร์ ซึ่งประกอบด้วย:

• MCP Hosts: โปรแกรมอย่าง Claude Desktop หรือ IDE ที่ต้องการเข้าถึงข้อมูลผ่าน MCP
• MCP Clients: ไคลเอ็นต์โปรโตคอลที่รักษาการเชื่อมต่อแบบ 1:1 กับเซิร์ฟเวอร์
• MCP Servers: โปรแกรมขนาดเล็กที่เปิดให้ใช้ความสามารถเฉพาะผ่านโปรโตคอลมาตรฐาน
• แหล่งข้อมูลในเครื่อง: ไฟล์ ฐานข้อมูล และบริการบนคอมพิวเตอร์ของคุณที่ MCP servers เข้าถึงได้อย่างปลอดภัย
• บริการระยะไกล: ระบบภายนอกที่ใช้งานได้ผ่านอินเทอร์เน็ต ซึ่ง MCP servers สามารถเชื่อมต่อได้

ZenML คืออะไร?

ZenML เป็นแพลตฟอร์มโอเพนซอร์สสำหรับสร้างและจัดการไปป์ไลน์ ML และ AI โดยมีอินเทอร์เฟซแบบรวมสำหรับจัดการข้อมูล โมเดล และการทดลอง

ดูข้อมูลเพิ่มเติมได้ที่ เว็บไซต์ ZenML และ เอกสารประกอบของเรา

ฟีเจอร์

เซิร์ฟเวอร์มีเครื่องมือ MCP สำหรับเข้าถึงฟังก์ชันการอ่านหลักจาก เซิร์ฟเวอร์ ZenML เพื่อให้เรียกดูข้อมูลล่าสุดเกี่ยวกับสิ่งต่อไปนี้ได้:

เอนทิตีหลัก

• ผู้ใช้ - บัญชีผู้ใช้และสิทธิ์
• Stacks - การกำหนดค่าโครงสร้างพื้นฐาน
• ส่วนประกอบของ Stack - องค์ประกอบย่อยแต่ละรายการของ Stack
• Flavors - ประเภทส่วนประกอบที่พร้อมใช้งาน
• Service Connectors - การยืนยันตัวตนบนคลาวด์

การเรียกใช้ไปป์ไลน์

• Pipelines - คำจำกัดความของไปป์ไลน์
• Pipeline Runs - ประวัติและสถานะการเรียกใช้
• Pipeline Steps - รายละเอียด โค้ด และบันทึกของแต่ละขั้นตอน
• Schedules - กำหนดการเรียกใช้อัตโนมัติ
• Artifacts - ข้อมูลเมตาเกี่ยวกับอาร์ติแฟกต์ข้อมูล (ไม่ใช่ตัวข้อมูลเอง)

การติดตั้งใช้งานและการให้บริการ

• Snapshots - การกำหนดค่าไปป์ไลน์ที่ตรึงไว้ (อาร์ติแฟกต์ที่ระบุว่า "จะเรียกใช้/ให้บริการอะไร")
• Deployments - อินสแตนซ์การให้บริการขณะทำงาน พร้อมสถานะ URL และบันทึก
• Services - Endpoint สำหรับให้บริการโมเดล

องค์กรและการค้นหา

• Projects - คอนเทนเนอร์สำหรับจัดระเบียบทรัพยากร ZenML
• Tags - ป้ายกำกับข้อมูลเมตาที่ใช้ร่วมกันเพื่อการค้นหา
• Builds - อาร์ติแฟกต์การสร้างไปป์ไลน์ที่มีข้อมูลอิมเมจและโค้ด

โมเดล

• Models - รายการในรีจิสทรีโมเดล ML
• Model Versions - อาร์ติแฟกต์โมเดลที่มีการกำหนดเวอร์ชัน

API เพื่อความเข้ากันได้ (แนะนำให้ย้ายข้อมูล)

• เทมเพลตการเรียกใช้ไปป์ไลน์ ยังคงใช้งานได้ใน ZenML 0.97.0 แต่แนะนำให้ใช้ Snapshots สำหรับเวิร์กโฟลว์ใหม่ (ดู คู่มือการย้ายข้อมูล)

เซิร์ฟเวอร์ยังช่วยให้คุณ เริ่มการเรียกใช้ไปป์ไลน์ใหม่ โดยใช้ snapshots (แนะนำ) หรือพารามิเตอร์ทริกเกอร์แบบใช้เทมเพลตที่เลิกแนะนำแล้วได้ด้วย

หมายเหตุ: เราปรับปรุงการผสานการทำงานนี้อย่างต่อเนื่องตามความคิดเห็นจากผู้ใช้ โปรดเข้าร่วม ชุมชน Slack เพื่อแบ่งปันประสบการณ์ และช่วยให้เราปรับปรุงให้ดียิ่งขึ้น!

โปรไฟล์เครื่องมือและนโยบายการเขียนข้อมูล

โปรไฟล์ compact ซึ่งเป็นค่าเริ่มต้นจะแสดงเครื่องมือ 16 รายการ เครื่องมือทั่วไป 7 รายการครอบคลุม แค็ตตาล็อกทรัพยากร การอ่าน การเปลี่ยนแปลงทั่วไป และการดำเนินการวงจรชีวิตที่มีขอบเขตชัดเจน:

เครื่องมือ	วัตถุประสงค์
zenml_describe_resources	ค้นหาประเภททรัพยากรที่รองรับและสคีมาของการดำเนินการที่มีขอบเขต
zenml_list_resources	แสดงรายการทรัพยากรประเภทหนึ่งด้วยตัวกรองและการแบ่งหน้าที่ผ่านการตรวจสอบแล้ว
zenml_get_resource	ดึงทรัพยากรหนึ่งรายการ โดยระบุขอบเขต parent และ project เมื่อจำเป็น
zenml_create_resource	สร้างทรัพยากรที่รองรับจาก payload ที่มีชนิดข้อมูลกำกับ
zenml_update_resource	อัปเดต UUID ของทรัพยากรที่ระบุอย่างเจาะจง
zenml_delete_resource	ลบหรือเก็บถาวร UUID ของทรัพยากรที่ระบุอย่างเจาะจง
zenml_action_resource	ดำเนินการวงจรชีวิตหรือการเชื่อมโยงที่อนุญาต โดยไม่มีการลองซ้ำ

ยังคงมีเครื่องมือเฉพาะทางอีก 9 รายการ เนื่องจากให้ความสามารถด้านการวินิจฉัย บริบทที่ใช้งานอยู่ บันทึกหรือโค้ดแบบสตรีม การเรียกใช้ไปป์ไลน์ หรือ App แบบโต้ตอบ:

• diagnose_zenml_setup
• get_active_user และ get_active_project
• trigger_pipeline
• get_step_logs, get_step_code, และ get_deployment_logs
• open_pipeline_run_dashboard และ open_run_activity_chart

get_step_logs ส่งคืนรายการได้สูงสุด 50,000 รายการ เรียงจากเก่าไปใหม่ พร้อมแฟล็ก possibly_truncated และ note ที่ระบุว่ารายการใดขาดหายไปและเพราะเหตุใด ส่ง tail เพื่อรับเฉพาะรายการล่าสุด บนเซิร์ฟเวอร์ ZenML 0.97 ขึ้นไป ระบบจะ แบ่งหน้าอ่านจากที่เก็บบันทึก ส่วนเวอร์ชัน 0.96 จะใช้ Endpoint แบบคำขอเดียวรุ่นเก่า

ใช้ ZENML_MCP_PROFILE=legacy เมื่อไคลเอ็นต์เดิมยังต้องพึ่งพาชื่อเฉพาะของเอนทิตีแบบเก่า เช่น list_pipeline_runs ซึ่งจะคงชั้นความเข้ากันได้ของชื่อเครื่องมือและสคีมาที่มีการกำหนดลักษณะไว้สำหรับ ZenML 0.97.0 แต่ไม่ได้เพิ่มการรองรับเซิร์ฟเวอร์ ZenML เวอร์ชันเก่ากว่านั้น ใช้ตัวเลือกนี้เฉพาะระหว่าง การย้ายข้อมูลเท่านั้น รูปแบบการตอบกลับแบบเดิมอาจเปิดเผยข้อมูลเมตาด้านการปฏิบัติงานมากกว่า เครื่องมือแบบกระชับ แม้เซิร์ฟเวอร์จะละเว้นการกำหนดค่าที่มีข้อมูลรับรองและ ฟิลด์อ่อนไหวอื่น ๆ จากทั้งสองโปรไฟล์ก็ตาม

การลงทะเบียนเครื่องมือและสิทธิ์เขียนข้อมูลเป็นคนละส่วนกัน:

โปรไฟล์	นโยบาย	เครื่องมือที่แสดง
compact	read_write	16
compact	read_only	11
legacy	read_write	57
legacy	read_only	52

ตั้งค่า ZENML_MCP_WRITE_POLICY=read_only เพื่อเอาเครื่องมือเปลี่ยนแปลงทั่วไปทั้งสี่รายการ และ trigger_pipeline ออกจากการค้นหาและการเรียกใช้ผ่าน MCP การค้นหาทรัพยากรจะ ไม่แสดงสคีมาสำหรับการสร้าง อัปเดต ลบ และดำเนินการด้วย การตั้งค่าเดิม ZENML_MCP_READ_ONLY=true ยังคงใช้ได้ หากค่านโยบายไม่ถูกต้อง ระบบจะปิดการเขียนข้อมูลและใช้โหมดอ่านอย่างเดียว หากค่า ZENML_MCP_PROFILE ไม่ถูกต้อง ระบบจะหยุดการเริ่มทำงานพร้อมข้อผิดพลาดในการกำหนดค่า

เวอร์ชัน 2.0.0 ต้องใช้ MCP Python SDK 2.2.0 และ ZenML 0.96.4 โปรไฟล์แบบกระชับเป็นค่าเริ่มต้นใหม่ และเป็นการเปลี่ยนแปลงที่ไม่เข้ากันในด้านการค้นพบเครื่องมือสำหรับไคลเอ็นต์ที่ เรียกใช้ชื่อเครื่องมือเฉพาะของเอนทิตี ตั้งค่า ZENML_MCP_PROFILE=legacy ระหว่างการย้ายข้อมูล ไคลเอ็นต์เหล่านั้น จากนั้นเปลี่ยนการเรียกแต่ละครั้งไปใช้เครื่องมือทรัพยากรทั่วไป

ผลลัพธ์การเปลี่ยนแปลงจะแยกสถานะ completed, accepted, และ unknown ออกจากกัน เซิร์ฟเวอร์จะไม่ลองทำการเปลี่ยนแปลงซ้ำหลังจากที่คำขออาจไปถึง ZenML แล้ว สำหรับผลลัพธ์ที่ยอมรับแล้วหรือไม่ทราบสถานะ ให้ทำตามคำแนะนำในการตรวจสอบสถานะในคำตอบก่อนตัดสินใจเรียกซ้ำ ใช้การอ่านข้อมูลที่ระบุชื่อไว้เมื่อมี การสร้าง webhook และการหมุนเวียน secret อาจส่งคืน signing secret ใหม่ได้เพียงครั้งเดียว การอ่านครั้งถัดไปจะไม่แสดง secret นั้น สคีมาการลบจะระบุว่าการดำเนินการนั้นเก็บข้อมูลเมตาเข้าคลัง ลบข้อมูลเมตา ยกเลิกการจัดเตรียมทรัพยากรที่กำลังทำงาน หรือลบข้อมูลอาร์ติแฟกต์ที่จัดเก็บไว้ได้หรือไม่

รุ่น 2.0 รุ่นแรกครอบคลุมการดำเนินการทั่วไปสำหรับ projects, stacks และ components, flavors, services, pipelines และ runs, snapshots และ templates, deployments, artifacts และ versions, models และ versions, tags, connectors, code repositories, webhooks, triggers, wait conditions และ hook invocations ส่วน users, schedules, service connector types, secrets และ resource requests รองรับเฉพาะการอ่านตามที่แสดงใน zenml_describe_resources โดยไม่ครอบคลุมการดูแลระบบ ZenML Cloud control plane, การดูแลระบบ Resource Manager, การดูแลผู้ใช้และข้อมูลรับรอง, การจัดการค่า secret แบบ CRUD, การเข้าสู่ระบบและการตรวจสอบ connector, raw webhook events หรือเครื่องมือดีบักและตรวจสอบ lineage แบบรวม

เริ่มเวิร์กโฟลว์ทั่วไปด้วยการค้นหาสคีมาที่แน่นอน แล้วจึงเรียกใช้:

zenml_describe_resources(resource_type="pipeline_run", operation="list")
zenml_list_resources(
    resource_type="pipeline_run",
    filters={"status": "completed", "sort_by": "desc:created"},
    page=1,
    size=10,
)

Prompts และ resources ยังคงใช้งานได้ในทั้งสองโปรไฟล์ analysis prompts, Endpoint ของสคีมาทรัพยากรที่มีขอบเขต และ most_recent_runs เป็น MCP prompts หรือ resources ไม่ใช่ tools

ความเข้ากันได้ของเทมเพลตการเรียกใช้

ZenML 0.97.0 ยังคงมี API CRUD สำหรับ run-template โดยแนะนำให้ใช้ Snapshots สำหรับเวิร์กโฟลว์ใหม่ การสร้างไปป์ไลน์แบบสะดวกและพารามิเตอร์ทริกเกอร์ที่ใช้เทมเพลตเลิกแนะนำแล้ว ในโปรไฟล์เดิม get_run_template และ list_run_templates ยังคงใช้งานได้สำหรับไคลเอ็นต์ที่มีอยู่

อินพุตเดิม tag ยังคงอยู่ใน list_run_templates เพื่อให้สคีมาเข้ากันได้ แต่ ZenML 0.97.0 ไม่มีตัวกรองฝั่งเซิร์ฟเวอร์ที่เทียบเท่ากัน หากค่าไม่ใช่ null ระบบจะปฏิเสธก่อนเรียกใช้ SDK การกรองแท็กของ Snapshot ยังคงใช้งานได้

การย้ายข้อมูล: Run Templates → Snapshots

ทำไมจึงเปลี่ยน? Snapshots เข้ามาแทนที่ run templates ในฐานะอาร์ติแฟกต์ไปป์ไลน์ที่เรียกใช้ได้ ซึ่ง ZenML แนะนำให้ใช้ SDK 0.97.0 ยังคงรองรับ CRUD สำหรับ run-template แต่โค้ดใหม่ควรใช้ snapshots

คู่มือการย้ายข้อมูลฉบับย่อ

รูปแบบเดิม (Templates)	รูปแบบแบบกระชับ (Snapshots)
list_run_templates()	zenml_list_resources(resource_type="snapshot", filters={"runnable": true, "named_only": true})
get_run_template(name)	zenml_get_resource(resource_type="snapshot", resource_id=id)
trigger_pipeline(template_id=...)	trigger_pipeline(snapshot_name_or_id=...)

ตัวอย่างเวิร์กโฟลว์ (เริ่มจาก Snapshot)

1. Discover project context:
   → get_active_project()

2. Find runnable snapshots:
   → zenml_list_resources(resource_type="snapshot", filters={"runnable": true, "named_only": true})

3. Trigger a run:
   → trigger_pipeline(snapshot_name_or_id="my-snapshot")

4. Check deployments:
   → zenml_list_resources(resource_type="deployment", filters={"status": "running"})
   → get_deployment_logs(name_id_or_prefix="my-deployment", tail=100)

หากต้องการแทนที่พารามิเตอร์เมื่อทริกเกอร์ snapshot ที่เรียกใช้ได้ ให้ส่งการกำหนดค่า run ของ ZenML (ตัว snapshot เองจะไม่เปลี่ยนแปลง):

trigger_pipeline(
    snapshot_name_or_id="my-snapshot",
    run_configuration={
        "steps": {"train": {"parameters": {"learning_rate": 0.01}}},
        "enable_cache": False,
    },
)

สำหรับ snapshots แบบคงที่ ให้แทนที่พารามิเตอร์ของขั้นตอนตามตัวอย่างด้านบน การแทนที่ระดับบนสุดด้วย run_configuration={"parameters": {...}} จะใช้กับพารามิเตอร์ของฟังก์ชันไปป์ไลน์ และรองรับเฉพาะ snapshots แบบไดนามิกเท่านั้น ZenML จะปฏิเสธการใช้กับ snapshots แบบคงที่

หมายเหตุ: get_deployment_logs ส่งคืนผลลัพธ์ที่มีขอบเขต (ค่าเริ่มต้น 100 บรรทัด สูงสุด 1000 บรรทัด จำกัดที่ 100KB) และต้องติดตั้งการผสานการทำงานของ deployer ที่เหมาะสม

ตั้งค่าอย่างรวดเร็วผ่าน Dashboard (แนะนำ)

วิธีที่ง่ายที่สุดในการตั้งค่า ZenML MCP Server คือผ่าน หน้า MCP Settings ใน ZenML dashboard ของคุณ

ไปที่ Settings → MCP ใน ZenML dashboard เพื่อรับ:

• ตัวอย่างการกำหนดค่าที่ตั้งค่าไว้ล่วงหน้า สำหรับ URL เซิร์ฟเวอร์และข้อมูลรับรองของคุณ
• ติดตั้งด้วยคลิกเดียว ผ่าน deep links สำหรับ IDE ที่รองรับ
• การกำหนดค่าที่คัดลอกและวางได้ สำหรับ VS Code, Claude Desktop, Cursor, Claude Code, OpenAI Codex และอื่น ๆ
• ตัวเลือก Docker และ uv ตามความต้องการของคุณ

ผู้ใช้ ZenML Pro

หน้า MCP Settings ช่วยให้คุณสร้าง Personal Access Token (PAT) ได้ด้วยคลิกเดียว โดยระบบจะใส่โทเค็นนี้ ลงในตัวอย่างการกำหนดค่าที่สร้างขึ้นทั้งหมดโดยอัตโนมัติ

ผู้ใช้ ZenML OSS

1. สร้างโทเค็นบัญชีบริการผ่าน Settings → Service Accounts ก่อน
2. วางโทเค็นลงในหน้า MCP Settings
3. คัดลอกการกำหนดค่าที่สร้างขึ้นสำหรับ IDE ของคุณ

---

ต้องการตั้งค่าด้วยตนเองหรือไม่? ดูคำแนะนำโดยละเอียดด้านล่าง

MCP Apps (ทดลอง)

MCP Apps คืออะไร? MCP Apps คือ UI แบบ HTML ที่โต้ตอบได้ ซึ่ง MCP servers สามารถ แสดงผลโดยตรงในไคลเอ็นต์ AI โดยจะแสดงผลใน iframe แบบ sandbox และเรียกใช้ เครื่องมือของเซิร์ฟเวอร์ได้ทั้งสองทิศทาง ดูรายละเอียดทั้งหมดได้ใน ประกาศอย่างเป็นทางการ

เซิร์ฟเวอร์นี้มี MCP Apps รุ่นทดลองสองรายการ:

App	เครื่องมือ	คำอธิบาย
แดชบอร์ด Pipeline Runs	open_pipeline_run_dashboard	ตารางแบบโต้ตอบของ pipeline runs ล่าสุด พร้อมสถานะ รายละเอียดขั้นตอน และบันทึก
แผนภูมิกิจกรรมการเรียกใช้	open_run_activity_chart	แผนภูมิแท่งแสดงกิจกรรม pipeline runs ในช่วง 30 วันที่ผ่านมา พร้อมแจกแจงตามสถานะ

แอปเหล่านี้เป็นตัวอย่างพิสูจน์แนวคิด เรายินดีรับความคิดเห็นและการมีส่วนร่วมเพื่อสร้าง MCP Apps เพิ่มเติม ฟีเจอร์ใหม่นี้ยังอยู่ในช่วงเริ่มต้น จึงต้องติดตามกันต่อไปว่าจะพัฒนาไปในทิศทางใด เราคาดว่าจะรองรับฟีเจอร์นี้ได้เต็มรูปแบบยิ่งขึ้นในอนาคต

ไคลเอ็นต์ที่รองรับ

MCP Apps ต้องใช้การขนส่งแบบ Streamable HTTP (ไม่ใช่ stdio) ไคลเอ็นต์ต่อไปนี้ รองรับ MCP Apps ในขณะนี้:

• ✅ VS Code (Insiders Edition)
• ✅ Goose
• ✅ ChatGPT (กำลังจะเปิดให้ใช้งาน)
• ⚠️ Claude Desktop -- ณ ปลายเดือนมกราคม 2026 ยังไม่สามารถแสดงผล Apps ได้
• ⚠️ Claude.ai (เว็บ) — ณ ปลายเดือนมกราคม 2026 ยังไม่สามารถแสดงผล Apps ได้

หมายเหตุ: ขณะเขียนเอกสารนี้ เรายังทดสอบ Claude Desktop หรือ Claude.ai ได้ไม่ทั่วถึง หากพบปัญหา โปรด รายงานให้เราทราบ

เรียกใช้ MCP Apps ด้วย Docker

MCP Apps ใช้ Streamable HTTP ให้ผูกพอร์ตของคอนเทนเนอร์ไว้กับ loopback และวาง reverse proxy ที่มีการยืนยันตัวตน หรือบริการควบคุมการเข้าถึงที่รับรู้ตัวตน ไว้ด้านหน้า ก่อนอนุญาตให้เข้าถึงจากระยะไกล การตรวจสอบ Host และ Origin ช่วยป้องกัน DNS rebinding แต่ไม่ได้ใช้ยืนยันตัวตนผู้เรียก

1. สร้างและเรียกใช้ Docker container:

docker build -t mcp-zenml:apps .

docker run --rm -d --name mcp-zenml-apps -p 127.0.0.1:8001:8001 \
  -e ZENML_STORE_URL="https://your-zenml-server.example.com" \
  -e ZENML_STORE_API_KEY="your-api-key" \
  -e ZENML_MCP_PROFILE="compact" \
  -e ZENML_MCP_WRITE_POLICY="read_write" \
  -e ZENML_ACTIVE_PROJECT_ID="your-project-id" \
  mcp-zenml:apps --transport streamable-http --host 0.0.0.0 --port 8001 \
  --disable-dns-rebinding-protection

2. กำหนดค่าการเข้าถึงระยะไกลที่ผ่านการยืนยันตัวตน:

สร้าง Cloudflare Tunnel ที่ตั้งชื่อไว้, Tailscale Funnel ที่มีการควบคุมการเข้าถึง หรือ reverse proxy ที่เทียบเท่าซึ่งผ่านการยืนยันตัวตน กำหนด origin ส่วนตัวให้ชี้ไปที่ http://127.0.0.1:8001 กำหนดให้ต้องใช้ข้อมูลประจำตัวหรือข้อมูลรับรองของบริการสำหรับ hostname สาธารณะ และส่งต่อเฉพาะคำขอที่ผ่านการยืนยันตัวตนแล้วไปยัง origin กำหนดค่า MCP client ให้ใช้ OAuth flow หรือ authorization headers ที่ผู้ให้บริการรองรับ

ก่อนเพิ่มข้อมูลรับรอง ZenML ลงใน container ให้ตรวจสอบว่าคำขอที่ไม่ผ่านการยืนยันตัวตนไม่สามารถเข้าถึง MCP ได้:

curl -i https://mcp.example.com/mcp

การตอบกลับต้องเป็น 401, 403 ของผู้ให้บริการควบคุมการเข้าถึง หรือการเปลี่ยนเส้นทางไปยังหน้าเข้าสู่ระบบ การตอบกลับแบบ JSON-RPC หรือ MCP หมายความว่าขอบเขตการป้องกันเปิดอยู่ และต้องแก้ไขก่อน

3. เชื่อมต่อ client ที่ผ่านการยืนยันตัวตนแล้ว:

{
	"servers": {
		"ZenML": {
			"url": "https://mcp.example.com/mcp",
			"type": "http"
		}
	},
	"inputs": []
}

• ขอให้ AI "เปิดแดชบอร์ดการรัน pipeline" หรือ "แสดงแผนภูมิกิจกรรมการรัน"

หมายเหตุสำคัญ:

• ต้องมี ZENML_ACTIVE_PROJECT_ID — หากไม่มี เครื่องมือ pipeline run จะล้มเหลวด้วยข้อความ "No project is currently set as active"
• --disable-dns-rebinding-protection เหมาะสำหรับใช้เฉพาะเมื่อ proxy ที่ผ่านการยืนยันตัวตนตรวจสอบ public host และพอร์ตของ container ยังคงจำกัดให้ใช้ได้เฉพาะ loopback
• จำกัดสิทธิ์ของ ZenML API key ให้เท่าที่ MCP client ต้องใช้ สำหรับ client ที่ใช้ตรวจสอบอย่างเดียว ให้ใช้ ZENML_MCP_WRITE_POLICY=read_only

การทดสอบและการประกันคุณภาพ

โปรเจกต์นี้มีการทดสอบอัตโนมัติเพื่อให้แน่ใจว่า MCP server ยังคงทำงานได้:

• 🔄 การทดสอบ Smoke Test อัตโนมัติ: GitHub Actions จะเรียกใช้ smoke test แบบครอบคลุมทุก 3 วัน
• 🚨 การสร้าง Issue: การทดสอบที่ล้มเหลวจะสร้าง GitHub issue พร้อมข้อมูลการดีบักโดยละเอียดโดยอัตโนมัติ
• ⚡ CI ที่รวดเร็ว: ใช้ UV พร้อมแคชเพื่อให้ติดตั้ง dependency และทดสอบได้อย่างรวดเร็ว
• 🧪 การทดสอบด้วยตนเอง: คุณสามารถเรียกใช้ smoke test ในเครื่องได้โดยใช้ uv run scripts/test_mcp_server.py server/zenml_server.py

การทดสอบอัตโนมัติจะตรวจสอบ:

• การเชื่อมต่อและ handshake ของ MCP protocol
• การเริ่มต้น server และการค้นหาเครื่องมือ
• ฟังก์ชันพื้นฐานของเครื่องมือ (เมื่อเข้าถึง ZenML server ได้)
• การแจกแจง resource และ prompt
• diagnose_zenml_setup ส่งคืนข้อมูลวินิจฉัยแบบมีโครงสร้าง แม้ในสภาพแวดล้อมที่มีข้อจำกัด

CI ที่ไม่ต้องใช้ข้อมูลรับรองครอบคลุม adapter ทุกตัวผ่าน MCP protocol ส่วน PR และ release CI จะเริ่ม ZenML 0.97.0 OSS server ใหม่บน loopback address และเรียกใช้ใบรับรองการดำเนินการ CRUD แบบบันทึกสถานะและการแยกโปรเจกต์ที่ใช้ชื่อเดียวกัน Server ใช้การกำหนดค่าและฐานข้อมูลชั่วคราว ซึ่งจะถูกลบเมื่อ job สิ้นสุด ไม่จำเป็นต้องใช้ environment ของ repository, self-hosted runner หรือข้อมูลรับรอง ZenML

OSS server ในเครื่องของ ZenML ปิดการยืนยันตัวตน และ SQL store ไม่รองรับการเล่น pipeline ซ้ำหรือโครงสร้างพื้นฐานสำหรับ deployment ภายนอก ดังนั้นใบรับรองการเข้าถึงแบบจำกัดและการทดสอบ trigger, replay, deployment, wait-condition และ resource-request ที่เปิดใช้ฟีเจอร์จึงยังคงเป็น gate แบบเลือกเปิดแยกต่างหาก โดยต้องใช้ ZENML_MCP_RESTRICTED_INTEGRATION=1 พร้อมกับ ZENML_MCP_RESTRICTED_API_KEY หรือ ZENML_MCP_ACTION_INTEGRATION=1 พร้อม UUID ของ fixture ชั่วคราวที่ตรงกันทุกประการใน ZENML_MCP_ACTION_FIXTURE ตามลำดับ การข้ามการทดสอบเนื่องจาก gate ไม่ได้เปิดใช้ ไม่ได้เป็นหลักฐานว่าความสามารถเหล่านั้นผ่านการทดสอบ ผู้ปฏิบัติงานสามารถตั้งค่า ZENML_MCP_REQUIRE_COMPLETE_INTEGRATION=1 เพื่อให้ gate ที่ไม่ได้เปิดใช้ทำให้การทดสอบล้มเหลวได้ การจัดเตรียมโครงสร้างพื้นฐานคลาวด์จะไม่เป็นส่วนหนึ่งของการทดสอบเริ่มต้น

การดีบักด้วย MCP Inspector

สำหรับการดีบักแบบโต้ตอบ ให้ใช้ MCP Inspector — เครื่องมือบนเว็บที่ให้คุณทดสอบเครื่องมือ MCP ได้แบบเรียลไทม์:

# Using .env.local (recommended for development)
cp .env.local.example .env.local  # Then edit with your credentials
source .env.local && npx @modelcontextprotocol/inspector \
  -e ZENML_STORE_URL=$ZENML_STORE_URL \
  -e ZENML_STORE_API_KEY=$ZENML_STORE_API_KEY \
  -- uv run server/zenml_server.py

การดำเนินการนี้จะเปิด UI บนเว็บที่กรอกข้อมูลรับรองของคุณไว้ล่วงหน้าแล้ว — เพียงคลิก Connect แล้วใช้แท็บ Tools เพื่อทดสอบเครื่องมือใดก็ได้แบบโต้ตอบ

ดู CLAUDE.md สำหรับคำแนะนำการดีบักโดยละเอียดเพิ่มเติม

ความเป็นส่วนตัวและการวิเคราะห์การใช้งาน

ZenML MCP Server เก็บรวบรวมข้อมูลวิเคราะห์การใช้งานแบบไม่ระบุตัวตนเพื่อช่วยให้เราปรับปรุงผลิตภัณฑ์

ข้อมูลที่เราติดตาม:

• มีการใช้เครื่องมือใดบ้างและบ่อยเพียงใด
• อัตราและประเภทของข้อผิดพลาด (เก็บเฉพาะประเภทข้อผิดพลาด ไม่เก็บข้อความ)
• ข้อมูลสภาพแวดล้อมพื้นฐาน (OS, Python version และทำงานใน Docker/CI หรือไม่)
• ระยะเวลาเซสชันและรูปแบบการใช้เครื่องมือ

ข้อมูลที่เราไม่เก็บ:

• URL หรือ API key ของ ZenML server ของคุณ
• ชื่อ pipeline, ชื่อโมเดล หรือข้อมูลทางธุรกิจใด ๆ
• ข้อความแสดงข้อผิดพลาดหรือ stack trace
• ข้อมูลใด ๆ ที่ระบุตัวบุคคลได้

วิธีปิดการวิเคราะห์การใช้งาน:

# Option 1
export ZENML_MCP_ANALYTICS_ENABLED=false

# Option 2
export ZENML_MCP_DISABLE_ANALYTICS=true

สำหรับการดีบัก/ทดสอบ (บันทึก event ลง stderr แทนการส่ง):

export ZENML_MCP_ANALYTICS_DEV=true

สำหรับผู้ใช้ Docker: คุณสามารถตั้งค่า ZENML_MCP_ANALYTICS_ID (ต้องเป็น UUID ที่ถูกต้อง) เพื่อคง ID แบบไม่ระบุตัวตนให้สม่ำเสมอระหว่างการรีสตาร์ต container หากไม่ได้ตั้งค่าและระบบไฟล์ของ container ไม่สามารถเก็บไฟล์ ID สำหรับการวิเคราะห์การใช้งานไว้ได้ server จะใช้ UUID แบบไม่ระบุตัวตนที่กำหนดแน่นอน ซึ่งได้มาจาก hash ของ ZENML_STORE_URL แทน (URL เองจะไม่ถูกส่งเป็น property ของ event)

ตัวเลือกการวิเคราะห์การใช้งานเพิ่มเติม:

• ZENML_MCP_ANALYTICS_SHUTDOWN_TIMEOUT_S — เวลาสูงสุด (วินาที) สำหรับส่งข้อมูลวิเคราะห์การใช้งานแบบ synchronous ระหว่างปิดระบบ (ค่าเริ่มต้น: 1.0)

หมายเหตุเกี่ยวกับการติดตามการปิดระบบ: Event การปิดระบบจะถูกส่งแบบ synchronous โดยมี timeout ที่จำกัดไว้เพื่อให้ส่งได้อย่างน่าเชื่อถือที่สุด อย่างไรก็ตาม หาก container ถูกหยุดด้วย SIGKILL (เช่น docker kill) ตัวจัดการการปิดระบบจะไม่สามารถทำงานได้ — นี่เป็นข้อจำกัดของ Docker/OS ไม่ใช่ข้อบกพร่อง

การตรวจสอบเมื่อเริ่มต้น

คุณสามารถเปิดใช้การตรวจวินิจฉัยเมื่อเริ่มต้นแบบเบาได้:

# Print warnings but start normally
uv run server/zenml_server.py --startup-validation warn

# Exit non-zero if required setup is missing (useful in Docker/CI)
uv run server/zenml_server.py --startup-validation strict

คุณยังสามารถตั้งค่านี้ผ่าน environment variable ได้: ZENML_MCP_STARTUP_VALIDATION=warn

เครื่องมือ diagnose_zenml_setup ยังมีให้ใช้เป็น MCP tool สำหรับการแก้ไขปัญหาระหว่างรันไทม์ด้วย — ใช้งานได้แม้ไม่ได้ติดตั้ง ZenML SDK หรือไม่มี environment variable

การตั้งค่าด้วยตนเอง

ข้อกำหนดเบื้องต้น

คุณต้องมีสิทธิ์เข้าถึง ZenML server ที่ deploy แล้ว หากยังไม่มี คุณสามารถสมัครทดลองใช้ฟรีที่ ZenML Pro แล้วเราจะจัดการ deployment ให้คุณ

เคล็ดลับ: เมื่อมี ZenML server แล้ว ให้ดู หน้า MCP Settings ในแดชบอร์ดเพื่อการตั้งค่าที่ง่ายที่สุด

ความเข้ากันได้: เวอร์ชันปัจจุบันทดสอบกับ ZenML 0.97.0 หากคุณใช้ ZenML เวอร์ชันเก่ากว่า โปรดใช้ รุ่นก่อนหน้า ของ MCP server นี้

นอกจากนี้ คุณอาจต้องติดตั้ง uv ในเครื่อง สำหรับข้อมูลเพิ่มเติม โปรดดู เอกสาร uv เราแนะนำให้ติดตั้งผ่านสคริปต์ติดตั้งของเครื่องมือนั้น หรือผ่าน brew หากใช้ Mac (ในทางเทคนิคแล้วไม่จำเป็นต้องใช้ แต่ช่วยให้ติดตั้งและตั้งค่าได้ง่าย)

คุณจะต้อง clone repository นี้ไว้ในตำแหน่งใดตำแหน่งหนึ่งในเครื่องด้วย:

git clone https://github.com/zenml-io/mcp-zenml.git

ไฟล์กำหนดค่า MCP ของคุณ

ไฟล์กำหนดค่า MCP เป็นไฟล์ JSON ที่บอก MCP client ว่าจะเชื่อมต่อกับ MCP server ของคุณอย่างไร MCP client แต่ละตัวอาจใช้หรือระบุไฟล์นี้แตกต่างกัน MCP client ที่นิยมใช้กันสองตัวคือ Claude Desktop และ Cursor ซึ่งเรามีคำแนะนำการติดตั้งไว้ด้านล่าง

คุณจะต้องระบุ MCP server ของ ZenML ในรูปแบบต่อไปนี้:

{
    "mcpServers": {
        "zenml": {
            "command": "/usr/local/bin/uv",
            "args": ["run", "path/to/server/zenml_server.py"],
            "env": {
                "LOGLEVEL": "WARNING",
                "NO_COLOR": "1",
                "ZENML_LOGGING_COLORS_DISABLED": "true",
                "ZENML_LOGGING_VERBOSITY": "WARN",
                "ZENML_ENABLE_RICH_TRACEBACK": "false",
                "ZENML_MCP_PROFILE": "compact",
                "ZENML_MCP_WRITE_POLICY": "read_write",
                "PYTHONUNBUFFERED": "1",
                "PYTHONIOENCODING": "UTF-8",
                "ZENML_STORE_URL": "https://your-zenml-server-goes-here.com",
                "ZENML_STORE_API_KEY": "your-api-key-here"
            }
        }
    }
}

เมื่อระบุ ZENML_STORE_API_KEY แล้ว MCP server จะเก็บข้อมูลรับรอง ZenML ไว้ในหน่วยความจำ และจะไม่อ่านหรืออัปเดตข้อมูลรับรองที่บันทึกไว้โดย zenml login ซึ่งมีผลกับการเรียกใช้ Python โดยตรง, MCPB extension และ Docker การเชื่อมต่อที่ไม่มี API key ยังคงใช้การเข้าสู่ระบบผ่าน terminal ที่บันทึกไว้ได้ ให้รีสตาร์ต MCP server หลังเปลี่ยน API key เพราะการเริ่มแชตใหม่เพียงอย่างเดียวอาจยังใช้โปรเซส server ที่กำลังทำงานอยู่

มีค่าตัวอย่างสี่ค่าที่คุณต้องแทนที่:

• path ไปยัง uv ที่ติดตั้งไว้ในเครื่อง (path ที่ระบุไว้ด้านบนคือตำแหน่งบน Mac หากติดตั้งผ่าน brew)
• path ไปยังไฟล์ zenml_server.py (ไฟล์นี้จะถูกรันเมื่อคุณเชื่อมต่อกับ MCP server) ไฟล์นี้อยู่ที่ root ของ repository นี้ คุณต้องระบุ full path ที่แน่นอนของไฟล์
• URL ของ ZenML server (URL ของ ZenML server ของคุณ ดูได้ใน ZenML Cloud UI) โดยจะมีลักษณะคล้าย https://d534d987a-zenml.cloudinfra.zenml.io
• API key ของ ZenML server (API key สำหรับ ZenML server ของคุณ ดูได้ใน ZenML Cloud UI หรือ https://docs.zenml.io/how-to/manage-zenml-server/connecting-to-zenml/connect-with-a-service-account เพื่อดูวิธีสร้าง สำหรับการใช้งาน ZenML MCP server เราแนะนำให้ใช้ service account)

คุณสามารถเปลี่ยนวิธีเรียกใช้ไฟล์ Python ของ MCP server ได้ แต่การใช้ uv น่าจะเป็นตัวเลือกที่ง่ายที่สุด เพราะจัดการ environment และการติดตั้ง dependency ให้คุณ

การติดตั้งเพื่อใช้งานกับ Claude Desktop

ทางเลือกด่วน: ใช้หน้า MCP Settings ในแดชบอร์ด ZenML (Settings → MCP) เพื่อรับคำแนะนำการติดตั้งที่กำหนดค่าไว้ล่วงหน้าและ deep link สำหรับ Claude Desktop

คุณต้องติดตั้ง Claude Desktop เวอร์ชันล่าสุด

คุณสามารถเปิดเมนู Settings แล้วลากไฟล์ mcp-zenml.mcpb จาก root ของ repository นี้ไปวางบนเมนูได้เลย ระบบจะแนะนำขั้นตอนการติดตั้งและตั้งค่าให้ คุณจะต้องเพิ่ม URL และ API key ของ ZenML server

หมายเหตุ: MCP bundle (.mcpb) มาแทนรูปแบบ Desktop Extensions (.dxt) รุ่นเก่า แต่ไฟล์ .dxt ที่มีอยู่ยังใช้งานได้ใน Claude Desktop

ตัวเลือกเสริม: ปรับปรุงการแสดงผลลัพธ์ของเครื่องมือ ZenML

เพื่อให้ใช้งานผลลัพธ์จากเครื่องมือ ZenML ได้ดียิ่งขึ้น คุณสามารถกำหนดค่า Claude ให้แสดงการตอบกลับ JSON ในรูปแบบที่อ่านง่ายขึ้นได้ ใน Claude Desktop ให้ไปที่ Settings → Profile แล้วเพิ่มข้อความลักษณะต่อไปนี้ (หรือใช้ข้อความนี้ตามตัวอักษร!) ในส่วน "What personal preferences should Claude consider in responses?":

When using zenml tools which return JSON strings and you're asked a question, you might want to consider using markdown tables to summarize the results or make them easier to view!

วิธีนี้จะช่วยให้ Claude จัดรูปแบบผลลัพธ์จากเครื่องมือ ZenML เป็นตาราง markdown ทำให้อ่านและทำความเข้าใจข้อมูลได้ง่ายขึ้นมาก

การติดตั้งเพื่อใช้งานกับ Cursor

ทางเลือกด่วน: หน้า MCP Settings ในแดชบอร์ด ZenML (Settings → MCP) สามารถสร้างเนื้อหา mcp.json ที่ถูกต้องพร้อมกรอกข้อมูลรับรองของคุณไว้ล่วงหน้าได้

คุณต้องติดตั้ง Cursor

Cursor ทำงานแตกต่างจาก Claude Desktop เล็กน้อย โดยคุณจะระบุไฟล์กำหนดค่าแยกตาม repository ซึ่งหมายความว่าหากต้องการใช้ ZenML MCP server ในหลาย repository คุณจะต้องระบุไฟล์กำหนดค่าในแต่ละ repository

หากต้องการตั้งค่าสำหรับ repository เดียว ให้ทำดังนี้:

• สร้างโฟลเดอร์ .cursor ที่ root ของ repository
• สร้างไฟล์ mcp.json ภายในโฟลเดอร์นั้น โดยใส่เนื้อหาตามด้านบน
• ไปที่การตั้งค่า Cursor แล้วคลิก server ของ ZenML เพื่อ 'enable'

จากประสบการณ์ของเรา บางครั้งอาจแสดงสัญลักษณ์ข้อผิดพลาดสีแดงทั้งที่ยังทำงานได้ คุณสามารถลองใช้งานได้โดยแชตในหน้าต่าง Cursor chat ระบบจะแจ้งให้ทราบว่าสามารถเข้าถึงเครื่องมือ ZenML ได้หรือไม่

Docker Image

คุณสามารถเรียกใช้ server เป็น Docker container ได้ โปรเซสจะสื่อสารผ่าน stdio และรอการเชื่อมต่อจาก MCP client ส่งข้อมูลรับรอง ZenML ผ่าน environment variable

Image ที่สร้างไว้ล่วงหน้า (Docker Hub)

ดึง image แบบ multi-arch ล่าสุด:

docker pull zenmldocker/mcp-zenml:latest

รุ่นที่มีการกำหนดเวอร์ชันจะติดแท็กเป็น X.Y.Z:

docker pull zenmldocker/mcp-zenml:2.0.0

เรียกใช้พร้อมข้อมูลรับรอง ZenML ของคุณ (โหมด stdio):

docker run -i --rm \
  -e ZENML_STORE_URL="https://your-zenml-server.example.com" \
  -e ZENML_STORE_API_KEY="your-api-key" \
  zenmldocker/mcp-zenml:latest

การกำหนดค่า MCP มาตรฐานโดยใช้ Docker

{
  "mcpServers": {
    "zenml": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ZENML_STORE_URL=https://...",
        "-e", "ZENML_STORE_API_KEY=ZENKEY_...",
        "-e", "ZENML_ACTIVE_PROJECT_ID=...",
        "-e", "ZENML_MCP_PROFILE=compact",
        "-e", "ZENML_MCP_WRITE_POLICY=read_write",
        "-e", "LOGLEVEL=WARNING",
        "-e", "NO_COLOR=1",
        "-e", "ZENML_LOGGING_COLORS_DISABLED=true",
        "-e", "ZENML_LOGGING_VERBOSITY=WARN",
        "-e", "ZENML_ENABLE_RICH_TRACEBACK=false",
        "-e", "PYTHONUNBUFFERED=1",
        "-e", "PYTHONIOENCODING=UTF-8",
        "zenmldocker/mcp-zenml:latest"
      ]
    }
  }
}

สร้างในเครื่อง

จาก root ของ repository:

docker build -t zenmldocker/mcp-zenml:local .

เรียกใช้ image ที่สร้างในเครื่อง:

docker run -i --rm \
  -e ZENML_STORE_URL="https://your-zenml-server.example.com" \
  -e ZENML_STORE_API_KEY="your-api-key" \
  zenmldocker/mcp-zenml:local

MCP Bundles (.mcpb)

โปรเจกต์นี้ใช้ MCP Bundles (.mcpb) ซึ่งเป็นรุ่นต่อจาก Desktop Extensions (DXT) ของ Anthropic MCP Bundle จะรวม MCP server ทั้งชุด (รวมถึง dependency) ไว้ในไฟล์เดียว พร้อมการกำหนดค่าที่ใช้งานง่าย

หมายเหตุเกี่ยวกับการเปลี่ยนชื่อ: MCP Bundle มาแทนรูปแบบ .dxt รุ่นเก่า Claude Desktop ยังคงรองรับไฟล์ .dxt ที่มีอยู่ย้อนหลังได้ แต่ตอนนี้เราเผยแพร่ mcp-zenml.mcpb และแนะนำให้ใช้รูปแบบนี้ต่อไป

ไฟล์ mcp-zenml.mcpb ที่ root ของ repository ใช้ MCPB 0.4 UV runtime Host จะติดตั้ง Python dependency ที่ตรึงเวอร์ชันไว้สำหรับระบบปฏิบัติการปัจจุบัน ดังนั้น bundle เดียวกันจึงใช้ได้บน macOS, Windows และ Linux โดยไม่ต้องฝัง native extension ที่จำเพาะกับแพลตฟอร์ม การติดตั้งต้องเชื่อมต่อเครือข่ายในครั้งแรกที่ UV แก้ไข dependency ของ environment ที่รวมมาให้ การสร้าง bundle จะนำ mcpb-uv.lock ที่ commit ไว้กลับมาใช้ และแก้ไขกราฟ dependency ของ Python ในโหมดออฟไลน์ รายการ dependency ของ bundle มาจาก [project].dependencies ใน pyproject.toml หลังจากเปลี่ยนรายการดังกล่าว ให้ตั้งค่า MCPB_REFRESH_LOCK=1 เพื่อแก้ไข dependency ใหม่แบบออนไลน์ โดยคง pin ทุกตัวที่ยังใช้ได้ไว้ ส่วน MCPB_REFRESH_LOCK=upgrade จะอัปเดต pin ทุกตัวเป็นเวอร์ชันล่าสุด

เมื่อคุณลากและวางไฟล์ .mcpb ลงในการตั้งค่าของ Claude Desktop ระบบจะจัดการสิ่งต่อไปนี้โดยอัตโนมัติ:

• การติดตั้ง dependency ขณะรัน
• การจัดการการกำหนดค่าอย่างปลอดภัย
• ความเข้ากันได้ข้ามแพลตฟอร์ม
• ขั้นตอนการตั้งค่าที่ใช้งานง่าย

ดูข้อมูลเพิ่มเติมได้จากประกาศของ Anthropic เกี่ยวกับ Desktop Extensions (DXT) และคำแนะนำที่เกี่ยวข้องเกี่ยวกับการจัดแพ็กเกจ MCP bundle ในเอกสารประกอบ: https://www.anthropic.com/engineering/desktop-extensions

เผยแพร่บน Anthropic MCP Registry

MCP server นี้เผยแพร่บน Anthropic MCP Registry อย่างเป็นทางการ และโฮสต์ที่เข้ากันได้สามารถค้นพบได้ ในแต่ละ tagged release CI ของเราจะอัปเดตรายการใน registry ผ่าน CLI mcp-publisher ของ registry โดยใช้ GitHub OIDC เพื่อให้คุณติดตั้งหรือค้นพบ ZenML MCP Server ได้โดยตรงจากทุกที่ที่รองรับ registry (เช่น แค็ตตาล็อก Extensions ของ Claude Desktop)

• อัปเดตอยู่เสมอ: รายการใน registry จะได้รับการปรับปรุงทุกครั้งที่มี release โดยใช้ manifest.json และ server.json จาก commit ที่ติดแท็ก
• ช่องทางติดตั้งอื่น: คุณยังติดตั้งในเครื่องผ่าน bundle .mcpb ที่จัดแพ็กเกจไว้ได้ (ดูด้านบน) หรือเรียกใช้ Docker image

ดูข้อมูลเพิ่มเติมเกี่ยวกับ registry ได้ที่:

• Anthropic MCP Registry (community repo): https://github.com/modelcontextprotocol/registry