Skip to main content
Glama

fusion_mcp_status

Idempotent

Verifies whether the Fusion MCP server is configured, Fusion is running, and the add-in answers on its port, reporting available tools and schemas. Optionally launches Fusion on macOS and waits for the add-in.

Instructions

Check Autodesk Fusion through the configured Fusion MCP server (fusion360-mcp-server, faust-machines or the pinned fork with document binding): whether it is configured, Fusion is running, the Fusion360MCP add-in answers on its port, and the server's tools and schemas. connected is true only when the add-in answers. With launch: true, starts Fusion on macOS when it is not running and waits up to 90 s for the add-in. Configure FUSION_MCP_COMMAND (uvx) and FUSION_MCP_ARGS (["--from","git+https://github.com/DMontgomery40/fusion360-mcp-server@86a3016a5a5b","fusion360-mcp-server","--mode","socket"]), or run fusion_mcp_setup.

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_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
launchNoStart Autodesk Fusion (open -a "Autodesk Fusion") when it is not running, then wait up to 90 s for the add-in.
timeout_msNoConnection and discovery deadline in milliseconds; defaults to FUSION_MCP_TIMEOUT_MS or 180000.

Output Schema

NameRequiredDescriptionDefault
pinNoThe faust-machines/fusion360-mcp-server commit this bridge is set up for.
errorNo
toolsYes
serverNo
launchedNoThis call started Fusion.
connectedYesThe Fusion MCP server started and the add-in answered its ping.
transportNo
configuredYesFUSION_MCP_COMMAND is set.
activeDesignNoWhen connected: whether Fusion has a design open, from the add-in's read-only get_design_type (false is its NO_ACTIVE_DESIGN). The pinned add-in refuses every design command, fusion_mcp_new_design included, without one (faust issue #12). Absent when unknown.
fusionRunningYes
addinReachableYesThe Fusion360MCP add-in answered a ping on FUSION_MCP_HOST:FUSION_MCP_PORT (default localhost:9877) within 2 s. Another program on that port, such as Blender's MCP add-on, does not count.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.77
    • addedOutput schema / properties / activeDesign
      Added value: +{
      +  "description": "When connected: whether Fusion has a design open, from the add-in's read-only get_design_type (false is its NO_ACTIVE_DESIGN). The pinned add-in refuses every design command, fusion_mcp_new_design included, without one (faust issue #12). Absent when unknown.",
      +  "type": "boolean"
      +}
  2. Addedv1.1.51

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true), the description explains why this status check is not read-only — launch: true opens Fusion and blocks up to 90 s waiting for the add-in. It also discloses the configuration prerequisites (FUSION_MCP_COMMAND / FUSION_MCP_ARGS) and the precise semantics of the 'connected' result, which is genuine behavioral context an agent cannot infer from annotations.

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

Conciseness3/5

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

The purpose is front-loaded in the first clause, which is good, but the single dense paragraph then embeds a full environment-variable configuration recipe including a long pinned git URL and JSON argument array. That detail is actionable but bulky and would read better as a short pointer to fusion_mcp_setup.

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?

With an output schema present and full parameter coverage, the description supplies the remaining essentials: prerequisites, the side effect of launch, and the condition under which 'connected' is true. It does not state what happens on timeout or failure (error vs. connected=false), which is the one remaining ambiguity for a diagnostic tool.

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?

Schema description coverage is 100%, with both 'launch' and 'timeout_ms' fully documented including the 90 s wait and the 180000 ms default. The description largely restates the launch semantics already present in the schema and says nothing about timeout_ms, so it adds little beyond the structured fields — baseline 3.

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 specific verb and resource ('Check Autodesk Fusion through the configured Fusion MCP server') and then enumerates exactly what is checked: configuration, whether Fusion is running, whether the Fusion360MCP add-in answers on its port, and the server's tools/schemas. It also defines the meaning of the key result field ('connected is true only when the add-in answers'), which lets an agent distinguish this from siblings like fusion_mcp_call or fusion_mcp_setup.

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

Usage Guidelines4/5

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

It gives clear operating context: use launch: true when Fusion is not running, and 'run fusion_mcp_setup' when configuration is missing, which explicitly routes to a sibling tool. It stops short of stating when *not* to use this tool (e.g., as a pre-flight before fusion_mcp_call) or what to do if the check fails after setup.

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