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

With no annotations, the description carries the full behavioral burden. It correctly signals a mutation ('Creates') and clarifies that the value is numeric with a default unit of mm, but says nothing about permission/auth requirements, what happens if the name already exists, or what the call returns. Adequate but with real gaps for a write operation.

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?

Three short sentences: purpose first, then usage routing, then a parameter note. No filler and nothing important buried.

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?

Covers purpose, the when-to-use condition, and the key parameter traits for a 4-param schema with no output schema. However, for an unannotated mutating tool it omits failure semantics (duplicate name, invalid unit) and side effects on the active design, so it is only minimally sufficient.

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 100%, including an enum for unit and a documented default of 'mm', so the baseline is 3. The description's note that the value is numeric and the unit defaults to mm restates what the schema already declares and adds no new parameter meaning.

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?

States a specific verb and resource ('Creates a named user parameter in the active Fusion 360 design') and scopes it to the active design. It explicitly contrasts with the sibling f360_set_parameter, so an agent can pick the right tool without opening either schema.

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?

Gives a clear usage condition ('before f360_set_parameter when a design does not already define the parameter'), which is genuine when-to-use guidance against a named alternative. It stops short of telling the agent how to determine whether the parameter already exists (e.g., via f360_list_parameters) or what to do on a name collision.

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

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

With no annotations, the description does real work: it discloses that this is a state-creating operation tied to the active design, that it is a hard prerequisite for drawing, and how each plane maps to a view orientation. It does not cover failure/edge behavior (e.g. no active design, what happens if a sketch is already open, or whether the sketch must later be closed), which keeps it below 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.

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

Three compact sentences, front-loaded with the action and the mandatory ordering constraint, then the plane semantics. No filler or restated field names.

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?

For a single-parameter, no-output-schema tool this covers purpose, prerequisites, and plane choice well. Minor gaps remain around preconditions (an active design must exist) and post-conditions (what the call yields, e.g. a sketch reference needed by later operations).

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 coverage is 100%, but the schema's enum description is only "Construction plane for the sketch". The description adds genuine meaning the schema lacks: XY = top view (most common for flat parts), XZ = front view, YZ = right-side view, giving the agent a basis for choosing a plane rather than guessing.

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?

States a specific verb and resource ("Opens a new sketch on a construction plane in the active Fusion 360 design") and explicitly positions itself as a prerequisite to the drawing tools. An agent can distinguish it from siblings like f360_extrude or f360_draw_rectangle without opening any schema.

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?

"MUST be called before any 2D drawing operation (draw_rectangle, draw_circle)" gives an explicit ordering rule and names the dependent siblings. It also routes plane selection with concrete guidance ("XY = top view (most common for flat parts)"), so there is nothing left to infer about when and how to use it.

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

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

With no annotations, the description carries the full burden; it does disclose the non-obvious constraint that the circle is always at the origin (no position parameters exist) and that a sketch must pre-exist. It does not say what happens on failure (no active sketch, invalid diameter), whether the operation is undoable, or what is returned.

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?

Three short sentences, front-loaded with the operation and its scope, followed by the prerequisite and use cases. The trailing 'Diameter in millimeters' sentence slightly duplicates the schema but is cheap.

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?

For a one-parameter creation tool with no output schema and no annotations, the description covers the essential call preconditions (active sketch, units) and geometry. Only error behavior and return value are unaddressed, which is a minor gap at this complexity.

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 coverage is 100% and the single parameter is fully documented in the schema. The description's 'Diameter in millimeters' merely restates the schema's unit, adding no new semantics such as valid ranges or how diameter relates to the fixed origin center.

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?

States a specific verb (Draws) and resource (a circle) with the key geometric constraint that it is centered at the origin in the active sketch. This distinguishes it cleanly from sibling f360_draw_rectangle and from f360_hole.

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?

Gives an explicit prerequisite (f360_create_sketch must be called first) and lists intended use cases (shafts, bosses, through-holes, pads). It stops short of naming alternatives — e.g., that f360_hole is preferable for true through-holes — so an agent must infer that routing.

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

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

No annotations are provided, so the description carries the full load, and it does add real context: the mandatory prerequisite tool, the fixed origin, and the unit system. It does not state whether the rectangle is created as a constrained entity, what happens on failure (e.g., no active sketch), or what the call returns, which is the main remaining gap.

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?

Four short sentences, front-loaded with the operation and its anchor, then the prerequisite, then units, then a worked example. Nothing is padded and nothing is repeated verbatim from the schema.

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?

For a two-parameter geometry creation tool with no output schema, the description covers purpose, prerequisite, units, and a worked example. It would be complete with one more clause on what is produced in the sketch or how failures surface, but the essential calling information is present.

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 coverage is 100% and the properties already document X/Y direction and a 0.01 minimum, so the baseline is 3. The description earns a bump by giving a concrete instantiation (50x30 mm maps to width_mm=50, height_mm=30), which removes any ambiguity about which parameter drives which axis and confirms units end-to-end.

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?

States a specific verb and resource ("Draws a 2-point rectangle") plus the geometric anchor point (0, 0) and the target container (active sketch). This is unambiguous and distinguishable from siblings such as f360_draw_circle without opening any schema.

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?

Explicitly gives the prerequisite ordering: "f360_create_sketch must be called first." It also pins the operation to the active sketch, which tells the agent the required context. It does not name an alternative tool or state when to use a different drawing primitive instead, so it stops short of the top score.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether an existing file at the path is overwritten, whether the active design must be saved first, what permissions are needed, or what the tool returns on success or failure.

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?

Two sentences, front-loaded with the action and format, followed by practical usage context and the key path instruction. No wasted wording.

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?

For a one-parameter export tool with no output schema, the description covers purpose, format, and path expectations. However, without annotations it omits important side-effect details such as overwrite behavior and the success/error response, leaving gaps for an agent invoking it.

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 coverage is 100%, so the schema already documents the single filepath parameter and gives an example. The description adds a requirement for an absolute path with filename and .step extension, but this largely repeats what the schema example shows.

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?

States a specific verb (exports), resource (active Fusion 360 design), and output format (.step). The format-specific use cases help distinguish it from generic exports, but the sibling f360_export_stl is never named to clarify the boundary.

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?

Gives clear use contexts — supplier quotes, CNC machining, importing into other CAD tools — which implies when STEP is appropriate. It does not explicitly state when to choose f360_export_stl instead or mention any exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It usefully says it exports the active design and explains mesh_refinement tradeoffs, but it omits file-overwrite behavior, directory creation, error conditions, and active-document prerequisites.

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 three tight sentences, front-loads the core action and output format, and each sentence adds useful information without repetition.

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?

For a simple two-parameter export tool with full schema coverage and no output schema, the description is mostly complete. The main remaining gap is file-handling behavior, but the core action and parameter effects are adequately covered.

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 coverage is already 100%, so the baseline is 3, but the description adds meaningful semantics for mesh_refinement beyond the schema's 'Mesh density' label by mapping low/medium/high to concrete use cases.

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 states a specific verb and resource: exports the active Fusion 360 design as an STL file. It clearly distinguishes STL from other formats through the 3D-printing context, though it does not explicitly contrast with the sibling f360_export_step.

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?

It gives clear usage context by saying STL is the standard format for 3D printing (FDM, SLA, SLS). It does not explicitly state when not to use it or name f360_export_step as the alternative for CAD interchange.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses units, direction convention, and that the result is a new body rather than a subtractive cut. It does not say what happens on failure (no closed profile), whether the feature is added parametrically to the timeline, or whether the model is modified irreversibly.

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?

Three short sentences, front-loaded with the core action, then the prerequisite, then the unit/direction and default-behavior notes. No filler or repetition.

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?

For a one-parameter mutation with no annotations and no output schema, the description covers prerequisite, units, direction, and result type. It stops short of failure modes or confirmation of what the call returns, but nothing essential for invoking it correctly is absent.

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 coverage is 100% and the single parameter is fully documented, so baseline is 3. The description adds a direction convention ('positive = away from sketch plane'), but the schema enforces minimum 0.01, so negative values are impossible and the sign guidance is effectively moot and slightly misleading rather than informative.

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?

States a specific verb (extrudes) and a specific input resource (the most recently created closed sketch profile) producing a specific result (3D solid body). This clearly separates it from f360_revolve, f360_fillet, f360_shell and other model-mutating siblings.

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?

Gives an explicit ordering prerequisite: 'Call after f360_draw_rectangle or f360_draw_circle', which tells the agent exactly which siblings must precede it. It also clarifies the default operation type ('not a cut'), though it never states what to do when no closed profile exists or when a cut/revolve would be preferred.

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

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

With no annotations, the description carries the full burden and does disclose the key behavioral limitation twice: it operates on 'the most recently created solid body' and fillets 'every edge' — an important constraint the agent cannot infer. It omits failure behavior (e.g., what happens when no body exists) and irreversibility/undo details.

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?

Three short sentences, front-loaded with the core action and scope. Slight redundancy between 'all edges' and the closing 'fillets every edge on the latest body', which restates the same limitation.

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?

For a simple one-parameter mutation with no output schema and no annotations, the description covers the action, units, intent, and the all-edges/latest-body scope. Missing only prerequisite and failure-mode notes to be fully self-sufficient.

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?

A single parameter with 100% schema coverage that already documents the radius and its mm unit, so the baseline is high. The description reinforces the millimeter unit and adds the 'constant-radius' qualifier, but adds little beyond the schema.

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?

States a specific verb and resource ('Applies a constant-radius fillet to all edges of the most recently created solid body') with scope made explicit. No sibling tool does filleting, so the agent can route here unambiguously.

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?

Names concrete use cases ('remove sharp edges for DFM or aesthetic purposes'), giving clear context for when to reach for it. It stops short of stating prerequisites (a solid body must already exist) or any when-not conditions, but no sibling competes for the same job.

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

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

Without annotations, the description carries the burden and discloses that this is a mutation, the prerequisite state, the target face, the coordinate origin, enum behavior, and a current limitation. It omits error behavior when no solid body exists and does not describe what is returned or created (e.g., a feature object).

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 front-loaded with the operation, then prerequisites, coordinate system, parameter semantics, use cases, and limitation. Every sentence contributes and there is no redundant filler.

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?

For a mutation tool with no annotations and no output schema, the description covers the essential behavioral and parameter context well. It could be slightly more complete by stating what happens if no solid body exists and how it relates to the hole-pattern sibling.

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 coverage is 100%, so the schema already defines parameters. The description still adds meaning by explaining that position is measured from the body origin, that 'through' passes all the way through, and that 'blind' stops at depth_mm from the top face – useful relationships beyond the schema's field descriptions.

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?

States a specific verb and resource: 'Creates a hole on the top face of the most recently created solid body.' This clearly identifies the operation and its target, but does not explicitly distinguish it from the sibling f360_hole_pattern, which likely handles patterned holes.

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?

Gives a clear precondition: requires an existing solid body and names f360_extrude or f360_revolve as prerequisite calls. Adds use-case context ('mounting holes and clearance holes') and an exclusion ('Threaded holes are not yet supported'), though it does not mention when to use f360_hole_pattern instead.

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

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 a genuinely non-obvious behavior — the operation targets the top face of the most recently created solid body — and that all holes share one diameter/type, but it omits that this is a destructive cut, what happens on failure (pattern larger than face), and any return value.

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?

Four short sentences, front-loaded with the core action and target, no filler. The bolt-circle diameter sentence is largely redundant with the schema, which keeps it from a 5.

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?

For a five-parameter geometry mutation with no annotations and no output schema, the description covers purpose, target body, and the uniform-diameter constraint, and the schema fills in enum/depth rules. What's missing is confirmation that this removes material from an existing body and any failure-mode guidance.

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 100%, so all five parameters are already documented, including the blind/through dependency on depth_mm. The description's note that bolt_circle_dia_mm is the circle on which hole centers sit restates the schema's PCD explanation rather than adding new semantics; baseline 3 applies.

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?

States a specific verb and resource ('Creates multiple equally-spaced holes in a circular bolt-circle pattern') plus a precise target ('top face of the most recently created solid body'). The plural/pattern framing separates it from the sibling f360_hole even without naming it explicitly.

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?

'Used for flanges, covers, and bolt-pattern connections' gives application context but never states when to choose this over f360_hole or how to proceed when a plain single hole is needed. Usage is implied rather than prescribed, with no exclusions.

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

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

With no annotations, the description carries the full burden; 'Returns' implies a safe read and it discloses the return fields (values and units), which is genuinely useful. It says nothing about behavior with no active design, an empty parameter set, or result size, so it is only minimally transparent.

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?

Two short sentences, front-loaded with what is returned and followed by the sequencing instruction. No filler or redundancy.

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?

For a zero-parameter read tool with no annotations and no output schema, the description covers the essential contract by describing what comes back (parameter values and units). It could add one line on empty-design behavior, but nothing critical is missing.

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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly communicates that no input is required beyond having an active design.

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?

States a specific verb (Returns) plus the exact resource (all user parameters in the active Fusion 360 design) and even the payload shape (current values and units). Naming f360_set_parameter makes the read-only listing scope distinguishable from the mutating siblings.

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?

Gives explicit sequencing guidance: 'Call this first ... before calling f360_set_parameter.' That is clear when-to-use context, but there is no mention of what to do when the design has no parameters or when a listing is unnecessary.

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

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

With no annotations present, the description carries the burden and does disclose the key behavior: it is a read-only responsiveness probe and it returns connectivity status, version, and active-design state. It leaves out whether failures surface as errors vs. a status value, and any timeout behavior.

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?

Three short sentences with zero waste. Purpose comes first, return values second, and the routing directive ('use this first') lands last where an agent will act on it.

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?

No output schema exists, so the description must describe return values – and it does, naming status, version, and design-open state. Error or failure-signaling semantics are the one remaining gap for a diagnostic tool.

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?

The tool takes zero parameters, so the baseline is 4. The description appropriately avoids inventing parameter detail and instead spends its space on return semantics, which the empty schema cannot convey.

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?

States a specific verb and resource: 'Checks if the Fusion 360 add-in TCP bridge is running and responsive.' This is clearly distinguishable from every sibling, all of which create geometry, manage parameters, or export files.

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?

Explicitly says 'Use this tool first to diagnose bridge readiness before issuing modeling commands,' which gives a clear precondition for the whole sibling set. It does not state when not to use it (e.g. skipping after a successful check), so it falls short of full when/when-not coverage.

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

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

With no annotations, the description carries the burden and does reasonably well: it discloses prerequisites (a closed profile, situated on one side of the chosen axis) and what is produced (a solid body). It does not cover failure modes (e.g., profile crossing the axis) or whether the source sketch is consumed.

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?

Front-loaded with the operation, then the call-order note, then per-parameter clarifications, then the geometric precondition. Every sentence adds distinct information with no repetition.

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?

For a two-parameter constructive tool with no output schema, this covers what to call it on, how to choose the axis, what the angle means, and the key geometric constraint. Only error/failure behavior and the fate of the source sketch are left unstated.

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 coverage is already 100%, so the description only needs to add value, and it does: it explains that X is lathe-style rotation and most common for symmetric parts, and that angle_deg below 360 produces a partial arc rather than a full solid. The 'profile on one side of the axis' constraint also gives operational meaning the schema lacks.

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?

States a specific verb (revolves) and resource (most recently created sketch profile) plus the result (solid body of revolution) and concrete part examples (shaft, flange, boss, cup). This clearly distinguishes it from f360_extrude, its nearest sibling, without naming it.

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?

Gives explicit sequencing: 'Call after f360_draw_rectangle or any closed sketch profile,' which tells the agent the prerequisite state. It doesn't explicitly contrast with f360_extrude, so the agent must infer which operation to choose when both are possible.

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

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

No annotations exist, so the description carries the behavioral burden and does disclose the key side effect: 'Changing a parameter automatically rebuilds all features that reference it.' It also scopes the effect to the 'active design'. It does not say what happens when the named parameter is missing, whether the change is reversible, or what the call returns.

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?

Four short sentences with the core action front-loaded and zero filler. The closing workflow hint is useful but slightly more tactical than the rest, keeping it just short of ideal tightness.

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?

For a 3-parameter mutation tool with full schema coverage and no output schema, the description covers purpose, precondition, side effects, and intended workflow. The notable remaining gap is error/return behavior, which no other structured field supplies.

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 100%, so name, unit enum, and value are already well documented in the structured data; baseline is 3. The description adds only the constraint that the name must refer to an existing parameter, which is more behavioral than parametric.

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?

States a specific verb and resource ('Updates a named user parameter in the active Fusion 360 design') and explicitly positions itself against siblings f360_create_parameter and f360_list_parameters. An agent can distinguish it from the create/list variants without opening any schema.

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?

Gives an explicit precondition ('must already exist... created manually in Fusion or via f360_create_parameter'), which routes the creation case to the sibling. It also names the intended workflow ('batch variant generation: call once per variant, then export'), so both when-to-use and the alternative are stated.

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

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

With no annotations, the description carries the full disclosure burden. It does explain that the operation removes a face and creates a uniform wall, but it omits how the face is selected and does not explicitly warn that the original solid body is modified destructively.

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 three concise sentences and front-loads the core operation before giving use cases and parameter units. It has little wasted text, though the unit sentence is redundant with the schema.

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?

For a simple one-parameter modeling tool with no annotations or output schema, the description covers the basic effect and use cases. However, it leaves out important context about face selection and the mutating nature of the operation, which an agent may need before invoking it.

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 100%, so the single thickness parameter is already documented in the schema. The description's mention of millimeters adds little beyond what the schema's 'Wall thickness in mm' already provides.

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 states a specific verb and resource: hollows out a solid body by removing one face and creating uniform wall thickness. It is clear what the tool does, though it does not explicitly distinguish itself from sibling modeling tools such as f360_extrude or f360_fillet.

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 gives application examples like enclosures, housings, and injection-molded parts, which implies when to use it. However, it does not state when not to use it or name alternative tools for related modeling operations.

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