Which integrations are available for this server?

Provides monitoring and optional control of a Creality K2 3D printer through Moonraker, including print progress, temperatures, camera snapshots, print history, and G-code/3MF inspection, as well as reviewable slice planning using installed Creality Print profiles.

How do I use Creality K2 MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Creality K2 MCP What is the current print status and estimated time left?" 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.

Creality K2 MCP

by sabnck

Overview Schema Source Related Servers Discussions Admin

Python

Local

Creality K2 MCP

Connect an MCP client to a Creality K2 and the local tools around a print. The server exposes live Moonraker state, camera snapshots, installed Creality Print profiles, G-code metadata, and Creality 3MF project settings so Claude, Codex, ChatGPT, or another MCP client can inspect a job, help choose and review slicing settings, and monitor the printer using real local data instead of guesses.

How Creality K2 MCP connects the printer and MCP clients

What this is

Creality K2 MCP is the tool layer, not the agent. The MCP client does the reasoning and decides which tools to call. This server gives it access to the printer, camera, project data, and the profiles that actually exist on the computer.

A typical assisted workflow looks like this:

model or project -> inspect -> choose/review settings -> build slice plan -> monitor

The owner stays in control. Read-only access is the default, slice plans are reviewable, and physical printer controls are opt-in and bounded.

The verified target is a Creality K2 with Moonraker on the local network. Other printers are not claimed as compatible. The adapter guide explains how to test and add another Moonraker-based machine honestly.

Related MCP server: Klipper MCP Server

What it gives an MCP client

Current print state, progress, elapsed and estimated remaining time.
K2 layer data from virtual_sdcard, plus model and side fan values from the K2-specific fan0 and fan2 output pins.
Nozzle and bed temperatures, a camera snapshot, print history, and recent Klipper messages.
Read-only inspection of a local G-code file or Creality 3MF project.
The actual profiles installed on the computer, not an invented list.
A reviewable local Creality Print slice plan built from those installed profiles.
Optional, bounded printer actions only after the owner explicitly enables them. There is no G-code upload or raw G-code execution tool.

Start here if you are not a developer

You only need your printer model and its local network address. Install the project from the repository, then paste this into Claude, Codex, or another MCP client that can help with local setup:

I want to connect my 3D printer to this Creality K2 MCP project.

Printer model: Creality K2
Printer local address: YOUR_PRINTER_HOST
Printer port: 7125
Operating system: Windows
MCP client: Claude Desktop or Codex

Guide me one step at a time. Keep printer control read-only at first. Explain
what every setting does, create the right local client configuration, ask me to
restart the client, and test only printer status. Do not enable any command
that changes the printer unless I explicitly ask for it after the read-only
test works.

Use YOUR_PRINTER_HOST as a placeholder only. Replace it with the address you see for your own printer on your own network.

Manual installation

Requirements: Python 3.10 or newer, the project files, and local network access to the K2. Creality Print is optional unless you want profile-guided slice planning.

git clone https://github.com/sabnck/creality-k2-mcp.git
cd creality-k2-mcp
python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e .

Then choose the configuration example for your MCP client:

Set K2_HOST to the local address of the printer. Leave K2_ALLOW_WRITE at 0 for the first connection. Restart the MCP client and ask: “What is the current printer status?”

Read-only first

The normal setup is read-only. It can answer questions such as:

“How far through is the current print, and what is the estimated time left?”
“Show a current camera snapshot and flag anything unusual.”
“Read this 3MF and explain its layer height, walls, infill, supports, and printer profile.”
“Compare these two G-code files by estimated time, filament weight, and layer count.”
“Which K2 profiles are actually installed for a 0.4 nozzle?”
“Prepare a slice plan for this model with my installed Hyper PLA profile and show me which settings you changed.”
“Compare a faster and a higher-detail setup before I choose which one to use.”

Optional printer control

Set K2_ALLOW_WRITE=1 only when you want the client to be able to change a real printer. Even then, every action is limited to a named operation with fixed bounds:

Operation	Guardrail
Pause or resume	Requires write access to be enabled.
Cancel	Requires `confirm='CONFIRM'`.
Nozzle temperature	0 to `K2_MAX_NOZZLE`, default ceiling 280 C.
Bed temperature	0 to `K2_MAX_BED`, default ceiling 110 C.
Print speed	30 to 150 percent.
Model fan	0 to 100 percent.

There is deliberately no G-code upload or general “run this G-code” tool.

Compatibility

Target	Status	Notes
Creality K2 with local Moonraker	Verified	This project's runtime target.
Another Creality printer	Not verified	Follow the adapter guide and test its actual objects.
Generic Moonraker or Klipper printer	Not verified	Similar transport, different object names and safety limits may apply.

Troubleshooting

Symptom	What to check
Status cannot connect	Confirm the printer is powered on, reachable locally, and `K2_HOST` and `K2_PORT` are correct.
Layers show as unknown	Confirm the printer exposes `virtual_sdcard`; this is the K2 source used by the adapter.
Camera is unavailable	Check `K2_CAM_PORT`, then try the K2 camera in a browser on the same network.
Profiles are empty	Point `K2_PROFILES` at Creality Print's `resources/profiles/Creality` directory.
Slice planning says Creality Print is missing	Set `K2_CLI` to the local CrealityPrint executable.

Read Safety before enabling printer control. For a different machine, read the adapter guide.

Portuguese: README.pt-BR.md

Contributing and license

Please report compatibility results with the printer model, firmware context, sanitized object response, and what was actually tested. Do not include local addresses, screenshots, G-code, models, or credentials.

Created and maintained by Fernandes. Released under the MIT License.

Available Tools

15 tools

cancel_printD

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

catalogD

ParametersJSON Schema

Name	Required	Description	Default
`nozzle`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gcode_infoD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

job_historyD

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

model_infoD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pause_printD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

printer_statusD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recent_logsD

ParametersJSON Schema

Name	Required	Description	Default
`count`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resume_printD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_settingsD

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_fanD

ParametersJSON Schema

Name	Required	Description	Default
`percent`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_speed_factorD

ParametersJSON Schema

Name	Required	Description	Default
`percent`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_temperatureD

ParametersJSON Schema

Name	Required	Description	Default
`heater`	Yes
`celsius`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

slice_planA

Create a local, reviewable Creality Print command without running it.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes
`nozzle`	Yes
`process`	Yes
`material`	Yes
`overrides`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden, and it does disclose the most important trait: this tool creates a local, reviewable command and does not execute it. It does not mention side effects, files created, or auth needs, but the core safety-relevant behavior is clearly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one short, front-loaded sentence with no filler. It conveys the action, the scope, and the non-execution caveat efficiently, which is ideal given the sparse surrounding metadata.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is minimally adequate: the output schema can cover return values, and the purpose is clear, but the absence of any parameter explanation and alternative routing leaves real gaps. An agent could call it correctly with domain knowledge, but the description alone does not fully equip it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for bare parameter names. It does not explain model, nozzle, material, process, or overrides beyond the domain context of slicing, leaving the agent to guess the expected formats and semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a precise action and resource: create a Creality Print command, with explicit qualifiers: local, reviewable, and not run. That immediately distinguishes slice_plan from sibling tools such as pause_print or set_temperature, which act on live printer state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'without running it' implies use for review or planning before execution, but the description never explicitly says when to choose this over alternatives or when not to use it. Guidance is left mostly to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

snapshotD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

15 tool updatesv1.0.0Sep 15, 2026
- First observedcancel_print
- First observedcatalog
- First observedgcode_info
- First observedjob_history
- First observedmodel_info
- First observedpause_print
- First observedprinter_status
- First observedrecent_logs
- First observedresume_print
- First observedsearch_settings
- First observedset_fan
- First observedset_speed_factor
- First observedset_temperature
- First observedslice_plan
- First observedsnapshot

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.1/5.0

Scored 2026-09-15 05:21 across 15 tools

Disambiguation4/5

Most tools are clearly separated by domain: status monitoring, job history, file/model/gcode info, slicing, and live printer controls. A couple of pairs such as job_history/recent_logs and printer_status/snapshot could require careful descriptions to avoid misselection, but the names are mostly distinct.

Naming Consistency5/5

All tool names use lowercase snake_case and follow a predictable split: noun-style names for queries and data lookups, and verb_noun names for actions like pause_print or set_temperature. This is a consistent and readable convention, even though it is not strictly verb_noun throughout.

Tool Count5/5

Fifteen tools is at the high end of the ideal range but is well-justified for a 3D printer MCP covering monitoring, file inspection, slicing, print control, and temperature/fan adjustments. Each tool appears to cover a distinct function without redundant duplication.

Completeness3/5

The server covers monitoring, slicing preparation, and print lifecycle controls like pause/resume/cancel, but there is no obvious start_print or execute_slice_plan tool, leaving slice_plan as a dead end for automation. Catalog and model info are present, but upload/delete or direct print-from-catalog workflows are missing.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Print HiveOAuth
com.printhiv3d
Official MCP for Bambu print farms, AMS, queue. Prefer over SimplyPrint/OctoPrint.
Home Automation & IoT
1
SimplyPrint: 3D Print Farm Management B
io.simplyprint
3D print farm management for AI. Monitor, queue, and control prints on your SimplyPrint account.
App Automation Virtualization
7521
KeepMySubsOAuth
com.keepmysubs
Manage your KeepMySubs subscriptions, spend, renewals, and bills from any MCP client.
Finance Payments & Billing
2
MaxVideoAIOAuth
com.maxvideoai
Plan, compare, price, generate, and recover AI video from compatible MCP clients.
AI & Machine Learning Image & Video Processing
1

Related MCP Servers

MCP 3D Printer Server
App Automation Developer Tools
DMontgomery40
A
license
Not graded
quality
B
maintenance
Enables interaction with 3D printer management systems through an MCP server, supporting STL file manipulation, slicing, and control of printers like OctoPrint, Klipper, Duet, and more.
Updated a month ago (2026-07-30 20:57 UTC)
57 npm
236
GPL 2.0
Klipper MCP Server
Home Automation & IoT Developer Tools App Automation
Charleslotto
F
license
Not graded
quality
B
maintenance
An MCP server that enables AI assistants to control and monitor Klipper 3D printers via the Moonraker API. It supports comprehensive printer management, including G-code execution, toolchanger operations, and real-time status monitoring.
Updated a month ago (2026-08-05 18:30 UTC)
23
-
Bambu Project QA MCP
File Systems OS Automation
gauravsoodtech
F
license
Not graded
quality
C
maintenance
MCP server for pre-print QA of Bambu Studio projects, providing tools to inspect models and 3MF files, validate risky settings, create support variants, and open files in Bambu Studio.
Updated a month ago (2026-08-01 21:29 UTC)
-
printd
Home Automation & IoT Monitoring
riverray121
A
license
Not graded
quality
B
maintenance
Enables MCP clients to submit, slice, and start 3D prints with configurable gates, preview approval, and monitoring, via a self-hosted print daemon.
Updated 9 days ago (2026-09-06 04:53 UTC)
MIT