MCP-Slicerは、モデルコンテキストプロトコル（MCP）を介して3D SlicerをClaude DesktopやClineなどのモデルクライアントに接続し、3D Slicerとの直接的な対話と制御を可能にします。この統合により、医用画像処理、シーン作成、そして自然言語を用いた操作が可能になります。
list_nodes: スライサーMRMLノードを一覧表示およびフィルタリングし、そのプロパティを表示します。
execute_python_code: スライサー環境でPythonコードを実行する
Related MCP server: QGIS MCP
3Dスライサー5.8以降
Python 3.13以降
UVパッケージマネージャー
Macをお使いの場合は、uvをインストールしてください。
brew install uvWindowsの場合
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"その後
set Path=C:\Users\nntra\.local\bin;%Path%それ以外の場合、インストール手順はウェブサイトに掲載されています: Install uv
⚠️まずUVをインストールしてください
Claude > 設定 > 開発者 > 構成の編集 > claude_desktop_config.json に移動して、以下を追加します。
{
"mcpServers": {
"slicer": {
"command": "uvx",
"args": ["mcp-slicer"]
}
}
}{
"mcpServers": {
"slicer": {
"command": "uvx",
"args": ["mcp-slicer"]
}
}
}スライサーウェブサーバーモジュールを開き、
必要なインターフェースがチェックされていることを確認する
サーバーを起動します
スライサーシーンに現在存在するマークアップノードの名前、長さ（線の場合）、角度（角度の場合）をリストします。
スライサー シーンで 8 cm の半透明の緑色の立方体を描画し、その頂点をマークしてから、その中に内接する赤い球体を描画します。
既存のSlicer Web Serverインターフェースを活用します。技術的な詳細については、 Slicer Web Serverユーザーガイドをご覧ください。
execute_python_codeツールを使用すると、3D Slicer で任意の Python コードを実行できます。これは強力ですが、潜在的に危険です。
⚠️ 本番環境での使用は推奨されません。
複雑な操作は、小さなステップに分割する必要がある場合があります。
貢献を歓迎します！お気軽にプルリクエストを送信してください。
これはサードパーティの統合プロジェクトであり、3D Slicer チームによって開発されたものではありません。
Capture a screenshot from 3D Slicer's views.
This tool provides real-time visual feedback of the current state of Slicer, enabling AI to observe the GUI and make informed decisions in a complete REACT loop.
Parameters: view_type (str): Type of screenshot to capture. Options: - "application" (default): Full application window including all panels and views - "slice": A specific slice view (Red/Yellow/Green) - "3d": The 3D rendering view
view_name (str): For slice views, specify which view to capture. Options: "red", "yellow", "green" Only used when view_type="slice"
slice_offset (float): For slice views, offset in mm relative to slice origin. Only used when view_type="slice"
slice_orientation (str): For slice views, specify orientation. Options: "axial", "sagittal", "coronal" Only used when view_type="slice"
camera_axis (str): For 3D views, specify camera view direction. Options: "L" (Left), "R" (Right), "A" (Anterior), "P" (Posterior), "I" (Inferior), "S" (Superior) Only used when view_type="3d"
image_size (int): Pixel size of output image (for slice and 3D views). Only used when view_type="slice" or view_type="3d"
Returns: A list containing text and/or image content. The image is returned in MCP's standard format for proper display in AI clients.
Examples:
Capture full application: {"tool": "capture_screenshot", "arguments": {"view_type": "application"}}
Capture Red slice view: {"tool": "capture_screenshot", "arguments": {"view_type": "slice", "view_name": "red"}}
Capture 3D view from anterior: {"tool": "capture_screenshot", "arguments": {"view_type": "3d", "camera_axis": "A"}}
Capture axial slice: {"tool": "capture_screenshot", "arguments": {"view_type": "slice", "view_name": "red", "slice_orientation": "axial"}}
| Name | Required | Description | Default |
|---|---|---|---|
| view_type | No | application | |
| view_name | No | ||
| slice_offset | No | ||
| slice_orientation | No | ||
| camera_axis | No | ||
| image_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a read-only operation (capturing screenshots implies no mutation), provides real-time visual feedback, and returns content in MCP's standard format for display. It doesn't mention rate limits, authentication needs, or error conditions, but covers the core functionality well given the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, parameters, returns, examples). It's appropriately sized for a tool with 6 parameters, though some sentences like 'enabling AI to observe the GUI...' could be more concise. Overall, it's front-loaded with the core purpose and efficiently documents parameters without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, no output schema, no annotations), the description is quite complete. It covers purpose, detailed parameter usage, return format, and includes practical examples. The main gap is the lack of output schema, but the description compensates by specifying the return format. It could benefit from more behavioral context like error handling, but it's largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It does this excellently by providing detailed parameter semantics: it explains each parameter's purpose, lists all valid options with clear enums (e.g., 'application', 'slice', '3d' for view_type), specifies dependencies (e.g., 'Only used when view_type="slice"'), and includes default values. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Capture a screenshot from 3D Slicer's views.' It specifies the resource (3D Slicer's views) and verb (capture), but doesn't explicitly differentiate from sibling tools like 'execute_python_code' or 'list_nodes', which have completely different functions. The description is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the phrase 'enabling AI to observe the GUI and make informed decisions in a complete REACT loop,' suggesting this is for visual feedback during AI interaction. However, it doesn't provide explicit guidance on when to use this tool versus alternatives (none of which are screenshot-related), nor does it mention any prerequisites or exclusions. Usage is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute Python code in 3D Slicer.
Parameters: code (str): The Python code to execute.
The code parameter is a string containing the Python code to be executed in 3D Slicer's Python environment.
The code should be executable by Python's exec() function. To get return values, the code should assign the result to a variable named __execResult.
Examples:
Create a sphere model: {"tool": "execute_python_code", "arguments": {"code": "sphere = slicer.vtkMRMLModelNode(); slicer.mrmlScene.AddNode(sphere); sphere.SetName('MySphere'); __execResult = sphere.GetID()"}}
Get the number of nodes in the current scene: {"tool": "execute_python_code", "arguments": {"code": "__execResult = len(slicer.mrmlScene.GetNodes())"}}
Calculate 1+1: {"tool": "execute_python_code", "arguments": {"code": "__execResult = 1 + 1"}}
Returns: dict: A dictionary containing the execution result.
If the code execution is successful, the dictionary will contain the following key-value pairs:
- "success": True
- "message": The result of the code execution. If the code assigns the result to `__execResult`, the value of `__execResult` is returned, otherwise it returns empty.
If the code execution fails, the dictionary will contain the following key-value pairs:
- "success": False
- "message": A string containing an error message indicating the cause of the failure. The error message may come from the Slicer Web Server or the Python interpreter.Examples:
Successful execution: {"success": True, "message": 2} # Assuming the result of 1+1 is 2
Successful execution: {"success": True, "message": "vtkMRMLScene1"} # Assuming the created sphere id is vtkMRMLScene1
Python execution error: {"success": False, "message": "Server error: name 'slicer' is not defined"}
Connection error: {"success": False, "message": "Connection error: ..."}
HTTP error: {"success": False, "message": "HTTP Error 404: Not Found"}
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers substantial behavioral information. It explains the execution environment (3D Slicer's Python environment), the execution mechanism (Python's exec() function), how to capture return values (assign to __execResult), and detailed success/failure response patterns including specific error types. The only gap is lack of information about permissions, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Parameters, Examples, Returns) but could be more front-loaded. The initial statement is clear, but some redundancy exists (e.g., explaining the code parameter twice). Most sentences earn their place by providing essential information, though minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (arbitrary code execution), lack of annotations, and no output schema, the description provides comprehensive context. It covers execution mechanics, return value handling, success/failure scenarios with concrete examples, and error types. For a powerful tool with zero structured metadata, this description provides nearly everything an agent needs to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the single parameter, the description fully compensates by providing rich semantic context. It explains that 'code' is executable Python code, specifies it should work with exec(), provides concrete examples showing proper formatting, and explains the special __execResult variable for return values. This goes far beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute Python code') and the target environment ('in 3D Slicer'), distinguishing it from siblings like capture_screenshot and list_nodes. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through examples (creating models, getting node counts, calculations) but doesn't explicitly state when to use this tool versus alternatives. There's no guidance on prerequisites, limitations, or comparison with sibling tools, leaving the agent to infer appropriate use cases from the examples provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List MRML nodes via the Slicer Web Server API.
The filter_type parameter specifies the type of node information to retrieve. Possible values include "names" (node names), "ids" (node IDs), and "properties" (node properties). The default value is "names".
The class_name, name, and id parameters are optional and can be used to further filter nodes. The class_name parameter allows filtering nodes by class name. The name parameter allows filtering nodes by name. The id parameter allows filtering nodes by ID.
Examples:
List the names of all nodes: {"tool": "list_nodes", "arguments": {"filter_type": "names"}}
List the IDs of nodes of a specific class: {"tool": "list_nodes", "arguments": {"filter_type": "ids", "class_name": "vtkMRMLModelNode"}}
List the properties of nodes with a specific name: {"tool": "list_nodes", "arguments": {"filter_type": "properties", "name": "MyModel"}}
List nodes with a specific ID: {"tool": "list_nodes", "arguments": {"filter_type": "ids", "id": "vtkMRMLModelNode123"}}
Returns a dictionary containing node information. If filter_type is "names" or "ids", the returned dictionary contains a "nodes" key, whose value is a list containing node names or IDs. Example: {"nodes": ["node1", "node2", ...]} or {"nodes": ["id1", "id2", ...]} If filter_type is "properties", the returned dictionary contains a "nodes" key, whose value is a dictionary containing node properties. Example: {"nodes": {"node1": {"property1": "value1", "property2": "value2"}, ...}} If an error occurs, a dictionary containing an "error" key is returned, whose value is a string describing the error.
| Name | Required | Description | Default |
|---|---|---|---|
| filter_type | No | names | |
| class_name | No | ||
| name | No | ||
| id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses behavioral traits: it describes the return format for different filter_type values, error handling, and default behavior. However, it lacks details on rate limits, authentication needs, or side effects, which would be beneficial for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but not optimally structured. It front-loads the purpose, but includes extensive parameter explanations and examples that could be more concise. Every sentence adds value, but some redundancy exists (e.g., repeating filter_type details).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description provides good completeness. It explains parameters, return values, and error handling. However, it lacks context on prerequisites (e.g., API setup) or performance considerations, which would enhance completeness for a tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the schema: it explains filter_type values ('names', 'ids', 'properties'), default behavior, and how optional parameters (class_name, name, id) filter nodes. Examples further clarify usage, fully covering all 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List MRML nodes via the Slicer Web Server API.' It specifies the verb ('List') and resource ('MRML nodes'), but does not differentiate from sibling tools like 'capture_screenshot' or 'execute_python_code', which are unrelated. The purpose is specific but lacks sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It explains parameters and examples but does not mention any sibling tools or contexts where this tool is preferred. Usage is implied through examples, but explicit guidelines are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0capture_screenshotexecute_python_codelist_nodesScored across 3 tools
Each tool serves a distinct, non-overlapping purpose: capture_screenshot provides visual feedback, execute_python_code runs arbitrary code, and list_nodes retrieves node information. Their descriptions clearly differentiate their functions, eliminating any confusion about which tool to use for a given task.
The tools follow a consistent verb_noun pattern (capture_screenshot, execute_python_code, list_nodes), making them predictable and readable. The minor deviation is that 'execute_python_code' uses a verb-object structure instead of a simple verb like 'run', but this is still clear and fits the overall naming style.
With only 3 tools, the set feels thin for interacting with a complex application like 3D Slicer. While the tools cover core functionalities (visualization, code execution, and data listing), essential operations like creating, updating, or deleting nodes are missing, limiting the server's scope and utility.
The toolset is severely incomplete for the domain of 3D Slicer interaction. It lacks basic CRUD operations for nodes (e.g., create_node, update_node, delete_node) and other common actions like loading/saving data or manipulating views. This will cause significant agent failures when trying to perform typical workflows in the application.
Connect AI agents to Replynodes over the Model Context Protocol.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Connect AI clients to biomedical data and tools.
