The MCP-Slicer server enables interaction with 3D Slicer for medical image processing and scene manipulation via the Model Context Protocol.
List and Filter MRML Nodes: Retrieve node names, IDs, or properties based on filters like class name, node name, or ID.
Execute Python Code: Run Python scripts directly in the 3D Slicer environment to manipulate scenes, create models, and perform operations.
Provides integration with the Python Package Index for installation of the MCP-Slicer package
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP-Slicer show me all the segmentation nodes in the current scene"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP-Slicer connects 3D Slicer with model clients like Claude Desktop or Cline through the Model Context Protocol (MCP), enabling direct interaction and control of 3D Slicer. This integration allows for medical image processing, scene creation, and manipulation using natural language.
list_nodes: List and filter Slicer MRML nodes and view their properties
execute_python_code: Execute Python code in the Slicer environment
capture_screenshot: Capture real-time screenshots of Slicer views
Full application window (including module panels)
Individual slice views (Red/Yellow/Green)
3D rendering view
Enables complete REACT loop with visual feedback
Related MCP server: QGIS MCP
3D Slicer 5.8 or newer
Python 3.13 or newer
uv package manager
If you're on Mac, please install uv as
brew install uvOn Windows
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"and then
set Path=C:\Users\nntra\.local\bin;%Path%Otherwise installation instructions are on their website: Install uv
⚠️ Please install UV first
Go to Claude > Settings > Developer > Edit Config > claude_desktop_config.json to include the following:
{
"mcpServers": {
"slicer": {
"command": "uvx",
"args": ["mcp-slicer"]
}
}
}{
"mcpServers": {
"slicer": {
"command": "uvx",
"args": ["mcp-slicer"]
}
}
}Open the Slicer Web Server module,
ensure the required interfaces are checked,
then start the server
What Markups nodes are in the Slicer scene now, list their names, what is their length if it is a line, and what is its angle if it is an angle
Draw a translucent green cube of 8 cm in the Slicer scene, mark its vertices, and then draw a red sphere inscribed in it.
Capture the current state of Slicer to provide visual feedback to AI
Usage examples:
capture_screenshot() - Capture full application window
capture_screenshot(view_type="slice", view_name="red") - Capture Red slice view
capture_screenshot(view_type="3d", camera_axis="A") - Capture 3D view from anterior
This enables a complete REACT loop where AI can:
Reason about what to do
Act using execute_python_code
Observe the result using capture_screenshot
Utilizes existing Slicer Web Server interfaces. For technical details, please see Slicer web server user guide
The execute_python_code tool allows running arbitrary Python code in 3D Slicer, which is powerful but potentially dangerous.
⚠️ Not recommended for production use.
Complex operations may need to be broken down into smaller steps.
Contributions are welcome! Feel free to submit Pull Requests.
This is a third-party integration project, not developed by the 3D Slicer team.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhaoyouj/mcp-slicer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
