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

bambu-printer-mcp

by DMontgomery40
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

fusion_mcp_setup

DestructiveIdempotent

Checks or installs the macOS Fusion MCP bridge requirements: Fusion presence, verified add-in, startup login item, and server .env settings, without starting or quitting Fusion.

Instructions

Check or install what the Fusion bridge needs on macOS: Autodesk Fusion itself (found, never installed), the Fusion360MCP add-in from DMontgomery40/fusion360-mcp-server at 86a3016a5a5b (every file checked against its pinned SHA-256) set to run on startup, a login item that sets FUSION_MCP_PORT for Fusion however it is opened, and this server's FUSION_MCP_* settings. Without install: reports them and changes nothing. With install: true, installs what is missing and adds the missing settings to this server's own .env (after a copy of it), keeping a configured FUSION_MCP_COMMAND and its arguments. Never starts or quits Fusion; check the connection with fusion_mcp_status.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "fusion_mcp_setup"
  }
}

Input Schema

NameRequiredDescriptionDefault
installNoInstall what is missing (default false: check only).

Output Schema

NameRequiredDescriptionDefault
pinYes
portYes
addinYes
readyYesThe add-in is at the pin and runs on startup, the port login item is installed and the bridge is configured. Fusion may still need opening: see fusion_mcp_status.
fusionYes
messageNoWhen not ready: what is missing and what to do, in plain words. Clients show it as it is.
env_fileYesThe .env this server read at start, when there is one.
platformYes
installedNoinstall: what it did.
supportedYesSetup installs on macOS only.
configuredYesFUSION_MCP_COMMAND is set for this server.
port_agentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.77

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description adds substantive context beyond them: it backs up the .env before editing, preserves an existing FUSION_MCP_COMMAND and its arguments, verifies every add-in file against a pinned SHA-256 at commit 86a3016a5a5b, and never installs Fusion. It does not spell out failure/partial-install behavior or permissions needed for the login item, which keeps it from a 5.

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

Conciseness4/5

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

It is one dense paragraph, but the check-vs-install split is front-loaded and each clause carries distinct information (pinned commit, SHA verification, .env backup, no Fusion start/quit). Some clauses are heavy and could be split into bullets for faster scanning, but nothing is padding.

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

Completeness5/5

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

For a setup tool with one boolean parameter and an output schema, the description covers both modes, side effects, safety guarantees (backup, no reinstall of Fusion, preservation of existing command config), and handoff to fusion_mcp_status. Nothing an agent needs in order to call it safely is missing.

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

Parameters4/5

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

Schema coverage is 100% and the single parameter already documents 'default false: check only'. The description adds real meaning beyond that by saying what install=true actually mutates (installs missing components and appends missing settings to this server's own .env after making a copy), which the schema does not convey.

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 opening clause names a specific verb pair and resource: 'Check or install what the Fusion bridge needs on macOS', then enumerates the exact components (Fusion app, the pinned Fusion360MCP add-in, login item for FUSION_MCP_PORT, this server's FUSION_MCP_* settings). It is clearly distinguishable from sibling fusion_mcp_status, which the description explicitly routes connection checks to.

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

Usage Guidelines5/5

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

It states both modes ('Without install: reports them and changes nothing', 'With install: true, installs what is missing') and gives an explicit exclusion ('Never starts or quits Fusion') plus the alternative for connection testing ('check the connection with fusion_mcp_status'). An agent knows exactly when to call this versus its siblings.

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