Skip to main content
Glama
Sign In
bambu-studio-mcp

bambu-studio-mcp

by naderfilho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Controlar impressão (pausar/retomar/parar)

bambu_print_control

Pause, resume, or cancel the current print job on a Bambu Lab printer, giving you direct control over ongoing prints.

Instructions

Pausa, retoma ou cancela a impressão atual da impressora Bambu Lab. ATENÇÃO: 'stop' cancela a impressão em andamento de forma irreversível.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "bambu_print_control"
  }
}

Input Schema

NameRequiredDescriptionDefault
ipNoIP da impressora (sobrepõe BAMBU_PRINTER_IP)
actionYesAção: pause, resume ou stop (cancelar)
serialNoNúmero de série (sobrepõe BAMBU_SERIAL)
access_codeNoAccess Code do LAN mode (sobrepõe BAMBU_ACCESS_CODE)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It does disclose the most critical behavior: 'stop' is irreversible. However, it does not explain what happens if there is no active print, whether the pause/resume are idempotent, or any connection/error behavior. Partial transparency.

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?

Two sentences, no fluff, with the purpose stated first and the safety-critical warning immediately after. Every word earns its place.

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

Completeness4/5

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

For a simple control command with 4 schema-covered parameters and no output schema, the description plus schema is nearly sufficient. The main missing context is the condition of an active print or the effects when no job is running, but the core operations and the critical irreversible 'stop' are clearly conveyed.

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

Parameters3/5

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

All four parameters are fully described in the schema (100% coverage) and there is an enum on 'action'. The description adds the irreversible consequence of 'stop', which adds a little semantic clarity to a parameter value, but the rest is already covered by the schema. Baseline of 3 because the schema does not supply heavy value.

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 explicitly names the three actions (pause, resume, cancel) and the specific resource (current print of the Bambu Lab printer), making it clearly distinguishable from sibling tools like bambu_start_print and bambu_status. The verb+resource combination is unambiguous.

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 description explains what the tool does but provides no explicit when-to-use or when-not-to-use guidance, and does not name alternatives. The irreversibility warning is a safety note, not a usage routing guideline. The user must infer that this is for controlling an ongoing print rather than starting one.

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

Deploy Server

Other Tools