Fusion360 MCP Server

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

Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation (readOnlyHint=false, idempotentHint=false, destructiveHint=false), which the description doesn't contradict. The description adds useful context about operating 'in the most recent sketch,' implying it modifies the current sketch state, but doesn't detail side effects like sketch activation requirements or error conditions. With annotations covering basic safety, the description adds some value but lacks rich behavioral context.

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 with zero waste: the first states the core action and target, and the second provides essential usage guidance for the key parameter. It's front-loaded with the main purpose and efficiently structured for quick comprehension.

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 has 3 parameters with moderate schema coverage (67%), no output schema, and annotations covering basic operational hints, the description is reasonably complete. It clarifies the spline_type options and sketch context, but could improve by mentioning prerequisites (e.g., requires an active sketch) or output expectations. For a drawing tool with clear parameters, it's mostly adequate but has minor gaps.

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 67% (2 of 3 parameters have descriptions), with the description adding meaning for spline_type by explaining the difference between fit_points and control_points. It doesn't elaborate on points or degree beyond what the schema provides (points as array of coordinates, degree as 3 or 5 for control_points), but the schema coverage is moderate, and the description compensates with clear spline_type guidance, earning a score above baseline.

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 ('Draw a spline') and the target ('in the most recent sketch'), which is specific and unambiguous. It also distinguishes between two spline types (fit_points vs control_points), providing clear differentiation from other drawing tools like draw_line or draw_circle in the sibling list.

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 clear context for when to use each spline_type option ('Use fit_points for a curve through points, or control_points for a control-polygon spline'), which helps the agent choose between them. However, it doesn't explicitly state when to use this tool versus other curve-drawing alternatives like draw_arc or spline-related tools (none listed), nor does it mention prerequisites like needing an active sketch.

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