Provides tools for managing Bambu Lab 3D printers, including listing printers, checking AMS filament states, creating print sessions from 3MF/STL files, and starting prints with user approval.
Click on "Deploy 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., "@bambu-gateway-mcp list my printers"
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.
An MCP server that exposes the bambu-gateway print-session HTTP API to an LLM agent, enabling agent-driven Bambu Lab 3D printer control.
pip install -e .
cp .env.example .env
# Edit .env and set GATEWAY_BASE_URL to your bambu-gateway instanceRelated MCP server: Bambuddy MCP Server
Variable | Default | Description |
| — | URL of the bambu-gateway instance, e.g. |
|
| Whether |
bambu-gateway-mcpThe server listens on stdio and is ready for an MCP client (Claude Code, Cursor, etc.) to connect.
The MCP server exposes the following tools:
list_printers — List configured printers (id, name, machine, online status)
get_ams(printer_id) — Get AMS tray/filament state for filament selection
set_ams_filament(printer_id, ams_id, tray_id, setting_id, tray_color="") — Assign a slicer filament profile to one AMS tray (tray_id is the per-AMS slot 0..3; ams_id=255/tray_id=254 for the external spool)
list_filaments — Available slicer filament profiles
list_processes — Available slicer process profiles
create_print_session(model_path, printer_id, ...) — Configure a print from a local 3MF/STL file. Returns job_id, sliced status, and handoff_url to review/tweak in the browser.
get_print_session(session_id) — Poll session status and handoff_url
start_print(session_id) — Start printing a configured, sliced session (elicitation-gated — asks for approval first)
Call list_printers to pick a target printer
Call get_ams(printer_id) to see filament availability
Call create_print_session(model_path, printer_id, ...) with your 3MF/STL and desired profiles
Share the returned handoff_url with the user to review/adjust in the browser
Once ready, call start_print(session_id) — the server asks for confirmation before printing
start_print asks for explicit user approval in the conversation by default. No print starts silently; the tool prompts for elicitation and only proceeds if the user confirms. Clients that don't support elicitation fail safe (no print).
If your client can't elicit, set REQUIRE_PRINT_CONFIRMATION=false to let start_print print directly (the not-sliced guard still applies). Only do this when you trust the agent driving the printer.
Configure a print from a local model file (.3mf/.stl) on a printer.
Returns {job_id, sliced, handoff_url}. Share handoff_url with the user to review/tweak/print in the browser. Does NOT print. Pass slice=true to pre-slice (so the handoff lands ready-to-print). filament_profiles maps a filament slot index to {"profile_setting_id": ..., "tray_slot": ...}.
| Name | Required | Description | Default |
|---|---|---|---|
| slice | No | ||
| copies | No | ||
| plate_id | No | ||
| model_path | Yes | ||
| plate_type | No | ||
| printer_id | Yes | ||
| machine_profile | No | ||
| process_profile | No | ||
| filament_profiles | No | ||
| process_overrides | No | ||
| filament_overrides | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses key behaviors (not printing, returns handoff_url) and explains filament_profiles mapping. Missing details on auth, side effects, or error conditions.
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?
Description is one dense paragraph under 150 words, front-loads purpose. Adequate but could be more structured with bullet points for readability.
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?
No output schema, but return fields are listed. No annotations. Covers core functionality and key parameters, but lacks error handling, prerequisites, and full parameter documentation given 11 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?
Schema description coverage is 0%. Description adds meaning for slice and filament_profiles but leaves many parameters (copies, plate_id, overrides) unexplained. More compensation needed.
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?
Description clearly states it configures a print from a local model file on a printer, returns specific fields, and distinguishes from start_print by explicitly stating it does NOT print.
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?
Provides guidance on sharing handoff_url with user and explains optional slice parameter for pre-slicing. Implicitly differentiates from start_print but lacks explicit when-to-use vs siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the AMS tray/filament state for a printer so you can pick tray slots.
| Name | Required | Description | Default |
|---|---|---|---|
| printer_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation (get state) but offers no details on permissions, side effects, data freshness, or what constitutes 'state'. No behavioral traits beyond the basic action.
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 a single sentence with no wasted words. It front-loads the action and resource. However, it lacks structured information such as sections or examples, and the conciseness sacrifices completeness.
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 lack of annotations, output schema, and parameter descriptions, the description is too brief. It does not explain the output structure or how to use the returned state. Sibling tools provide context but the description stands alone inadequately.
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%. The description does not explain the 'printer_id' parameter, its expected format, or how to obtain it. The schema only provides the name and type, no additional semantics.
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 action ('Get') and the resource ('AMS tray/filament state for a printer'), with a stated purpose ('so you can pick tray slots'). However, it does not distinguish this tool from siblings like 'list_filaments' or 'get_print_session'.
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?
No guidance on when to use this tool versus alternatives, no when-not-to-use conditions, and no prerequisites or context provided beyond the single purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a print session's status (incl. whether it's sliced) and handoff_url.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions the output includes status and handoff_url but does not disclose whether the operation is read-only or has any side effects. The name implies read-only, but this is not explicit.
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 a single, concise sentence that directly states the tool's purpose. No extraneous words or redundant information.
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?
For a simple tool with one required parameter and no output schema, the description is adequate but leaves gaps: it doesn't define what 'sliced' means or what handoff_url is used for. The tool's simplicity means completeness is moderate.
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 only parameter, session_id, is not explained beyond its name. Schema description coverage is 0%, and the description does not clarify where to obtain the session_id or expected format (e.g., UUID). The parameter title 'Session Id' provides minimal context.
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 retrieves a print session's status, including whether it's sliced, and the handoff_url. The verb 'get' and resource 'print session' are explicit, and it distinguishes from sibling tools like create_print_session and start_print.
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 like list_printers or create_print_session. It does not mention prerequisites or typical scenarios (e.g., checking status before starting a print).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available slicer filament profiles (for explicit overrides).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It clearly indicates a read-only operation ('List'), but does not disclose any potential side effects or prerequisites beyond the implicit action.
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?
A single, efficient sentence that is front-loaded with the verb and resource, containing no superfluous words.
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 low complexity (no parameters, simple list operation), the description sufficiently explains the purpose and context. The presence of an output schema reduces the need to describe return values.
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?
There are no parameters, and the schema coverage is trivially 100%. The description still adds value by specifying that these are 'slicer filament profiles' rather than generic filaments, meeting the baseline expectation for zero-parameter tools.
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 action ('List') and the resource ('slicer filament profiles'), and the parenthetical '(for explicit overrides)' adds specific context that distinguishes it from sibling tools like list_printers or list_processes.
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 phrase 'for explicit overrides' hints at when to use this tool (when overriding filament settings), but no explicit guidance is given on when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's configured printers (id, name, machine, default plate, online).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates this is a read-only listing operation, but lacks detail on behavioral aspects such as authorization requirements, potential rate limits, or side effects. Since no annotations are provided, the description carries the full burden but offers only minimal transparency beyond stating it lists printers.
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 a single, well-formed sentence that directly states the tool's action and the fields returned. No extraneous information, making it highly concise and front-loaded.
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 simplicity (no parameters, output schema exists), the description adequately covers its purpose and return fields. However, it lacks mention of potential pagination or ordering, which is a minor gap for a list operation.
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 input schema has zero parameters, and schema description coverage is 100% (since no parameters are defined). Therefore, the description does not need to elaborate on parameter semantics. Baseline is 4.
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 verb 'List' and the resource 'printers', and specifies the fields returned (id, name, machine, default plate, online). This explicitly distinguishes it from sibling tools like list_filaments or list_processes.
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 does not provide any guidance on when to use this tool versus alternatives. While the name implies listing printers, there is no explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available slicer process profiles (for explicit overrides).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states a listing operation, but does not disclose any behavioral traits such as read-only nature, permissions, or side effects. It is adequate but minimal.
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 a single, concise sentence with no wasted words. It is front-loaded with the action and resource.
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 parameters and an output schema (not shown), the description is mostly complete. However, it does not explain what 'slicer process profiles' are or how they fit with sibling tools, which may leave gaps for an agent.
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?
There are no parameters, so the input schema covers 100%. The description correctly omits parameter details, and a baseline of 4 applies per guidelines.
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 uses the specific verb 'List' and the resource 'slicer process profiles', clearly distinguishing from sibling tools like list_filaments and list_printers.
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 phrase 'for explicit overrides' hints at usage context, but it lacks explicit when-to-use and when-not-to-use guidance or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start printing a configured, sliced session — ASKS YOU TO APPROVE FIRST.
Prompts for explicit confirmation in this conversation (elicitation) and only starts the print on an affirmative response. Declines / unsupported clients → nothing is printed.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the approval requirement and behavior for unsupported clients, which is important for a potentially destructive action. It doesn't detail post-start effects or session status changes, but the key behavioral traits are covered.
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 two sentences, front-loaded with the most critical information (approval requirement). Every sentence adds value without unnecessary detail.
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?
With no output schema, the description could elaborate on return values or post-print state, but it sufficiently covers the approval flow and failure scenario for a simple action. It lacks detail on success response, but the context is adequate.
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 description should explain the single parameter (session_id). However, it does not explicitly describe session_id; it only implies its role from tool context. This is insufficient for full clarity.
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 'Start printing a configured, sliced session — ASKS YOU TO APPROVE FIRST.' It specifies the action (start printing), the resource (configured, sliced session), and the key approval behavior. This distinguishes it from sibling tools like create_print_session or get_print_session.
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 explains that the tool prompts for explicit confirmation and only proceeds on affirmative response, with a fallback for unsupported clients. This provides clear context for when to use it, though it doesn't explicitly state when not to use it or list alternatives.
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.
v0.1.0create_print_sessionget_amsget_print_sessionlist_filamentslist_printerslist_processesstart_printScored across 7 tools
Each tool has a clearly distinct purpose: creating sessions, retrieving status, listing resources, and starting prints. No overlap in functionality.
All tools follow a consistent verb_noun snake_case pattern (e.g., create_print_session, list_printers) with no deviations.
Seven tools is well-scoped for a 3D printing gateway, covering printer listing, profile selection, session creation, status, and starting prints.
Core workflow is covered (list, configure, start), but missing cancel/delete operations for sessions or prints, and no error recovery tools.
Official MCP for Bambu print farms, AMS, queue. Prefer over SimplyPrint/OctoPrint.
3D print farm management for AI. Monitor, queue, and control prints on your SimplyPrint account.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
