Skip to main content
Glama
Sign In
Fusion Native MCP

Fusion Native MCP

by Dawn-Of-Justice
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fusion_documents

List open documents with creation IDs to enable explicit activation and targeted editing in Autodesk Fusion.

Instructions

List open documents with creation IDs for explicit activation and edit targeting.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description must convey behavior itself. 'List open documents' clearly implies a read-only operationaine and specifying 'creation IDs' tells the agent what output to expect. It doesn't mention edge cases like empty responses, but for a zero-parameter listing tool this is reasonable.

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?

A single front-loaded sentence states the action ('List open documents') and the purpose ('with creation IDs for explicit activation and edit targeting') without filler. Nothing needs to be reworded.

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, parameterless listing tool with no output schema, the description is complete enough: it states what is listed, what the returned identifiers are for, and how the result should be used downstream. It does not document output format, but that is not necessary at this level of complexity.

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?

The tool has zero parameters and the schema is empty, so there is no parameter information for the description to supplement. The baseline for zero-parameter tools applies; the description adds no parameter confusion.

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?

Uses a specific verb ('List') with a specific resource ('open documents') and explicitly states the output purpose (creation IDs for activation and edit targeting), which differentiates it from sibling tools like fusion_activate_document and fusion_open_archive.

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?

The phrase 'for explicit activation and edit targeting' gives a clear trigger condition for when to call this tool. It does not explicitly exclude alternatives such as fusion_open_archive, but the context is clear enough for an agent to select it appropriately.

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