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

With no annotations, the description carries the full burden and does well: single-transaction semantics, recompute-and-measure checks, rollback on failure, no file save, and supported object types. It stops short of saying how results/failures surface (returned payload vs. thrown error), which matters for a mutation tool.

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 action and constraint, then the behavioral detail grouped sensibly. Dense but every line carries information; minor fragmentation across short lines is the only cost.

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 mutating, no-annotation, no-output-schema tool, the description covers the critical agent questions: transaction scope, validation, rollback, persistence, and supported object types. The remaining gap is what the agent receives on success or check failure.

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 0% for the single plan_id parameter, so the description must compensate. It does add meaning by tying plan_id to a 'fresh' plan and warning against stale/reused ids, but never states the id format or its origin tool.

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 ('Apply a fresh plan') plus the constraint that the plan must be fresh, which separates it from plan/preview tooling. It does not name the sibling tools (plan_alignment, preview_alignment) that produce those plans, so differentiation is implied rather than explicit.

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 concrete when-not conditions: refuses reused/stale plans and does not support App::Link or App::Part containers. It never explicitly routes the agent to preview_alignment or plan_alignment as the prerequisite step, leaving the workflow relationship to inference.

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 so well: it discloses that accepted=true is a request rather than proof of cancellation, that running OCCT calls cannot be interrupted, that cancellation is refused once committing starts, and that rollback semantics apply to running mutations. These are non-obvious operational traits an agent would otherwise get wrong.

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 dense sentences, each carrying distinct information, with the primary action stated first and the caveats after. The line-broken formatting is slightly awkward but nothing is redundant.

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 tool with no annotations and no output schema, the description closes the critical gaps: the accepted-not-cancelled contract, the refusal window, and polling for terminal state. Only the source of job_id and any error shape 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 description coverage is 0% and the single parameter job_id is undocumented in both schema and description. The description implies a job identity that distinguishes queued from running work but never says where a job_id comes from or what form it takes.

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 (cancel) and resource (assembly job) and immediately splits into two modes: discarding queued jobs versus safe-point cancellation with rollback for running mutations. It does not name a sibling tool, so the distinction from get_assembly_job / get_async_status must be inferred rather than read.

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 usable conditions: applies to queued jobs and to running mutations via safe-point cancellation, and is refused once committing begins. It stops short of pointing at the follow-up tool for polling terminal state, leaving the agent to guess among the many get_* siblings.

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 of behavioral disclosure. It clearly states the operation is non-mutating ("without moving it"), reports passed=false on failure, and limits its own scope, though it does not describe success output, synchronous behavior, or plan 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 definition is front-loaded with the core action and key behavioral constraint, followed by a compact scope disclaimer. Both sentences earn their place and there is no redundant 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?

The description covers purpose, non-mutation, failure signaling, and scope limits, which is adequate for a simple one-parameter check tool. It still leaves gaps around how plan_id is sourced and what a successful result contains, with no output schema to compensate.

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 schema has 0% description coverage for the single required parameter, plan_id. The description only refers to "a plan" and does not explain the expected identifier format, where to obtain it, or whether the plan must already exist.

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: measure current geometry against a plan. The phrase "without moving it" distinguishes it from mutating assembly operations such as apply_alignment, though it does not explicitly name any sibling tool.

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 second sentence gives useful scope exclusions, making clear what this tool does not validate. However, it does not explicitly say when to choose check_assembly over siblings like preview_alignment, plan_alignment, or get_assembly_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?

With no annotations, the description carries the load and does reasonably well: it discloses atomicity ('one transaction'), a side effect ('Creates the native joint group'), a hard failure condition ('Refuses parts already inside containers'), and non-persistence ('Does not save files'). It stops short of stating required permissions, what is returned, or what happens to the document on 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?

Four short sentences, front-loaded with the core action and followed by constraints, with no filler. The telegraphic style borders on clipped but every sentence carries information.

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 and no annotations, so the description must cover both behavior and parameters; it covers behavior well but leaves all three parameters undocumented, including format expectations for doc_name and the parts list. Adequate for the mutation semantics, incomplete for invocation details.

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 0% and the description only touches one parameter indirectly by qualifying parts as 'ROOT parts'. The required doc_name and the optional name (default 'Assembly') are left completely unexplained, so an agent has to infer their meaning from the field names alone.

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 ('Create a native FreeCAD Assembly') plus scope ('containing specified ROOT parts, preserving world poses'), which separates it from siblings like create_document or create_fixed_joint. It does not explicitly name a sibling it replaces, but the purpose is unambiguous.

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 precondition/exclusion ('Refuses parts already inside containers') and a scope limit ('Does not save files'), which are genuinely useful usage signals. However, it never says when to prefer this over alternatives such as create_fixed_joint or create_document, so the routing guidance is only implied.

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?

The description states a return message indicating success or failure, which is a behavioral trait. However, it does not disclose potential side effects like whether the document becomes active, what happens if the name already exists, or any permissions required. No annotations are present, so the description carries full burden and only partially meets it.

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 well-structured with clear Args, Returns, and Examples sections. It front-loads the purpose and provides an example without excessive verbosity. The example section is somewhat redundant but adds practical value for the agent.

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 creation tool, the description is adequate but lacks detail on error handling, naming rules, or interaction with other FreeCAD elements. It does not mention uniqueness or whether the document becomes active, which are important for an agent. The absence of output schema makes it sufficient but not complete.

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 description adds a brief explanation of the 'name' parameter and provides a concrete JSON example, which compensates for the lack of schema descriptions. However, it does not specify constraints like uniqueness, allowed characters, or length limits. The example is helpful but limited.

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 'Create a new document in FreeCAD,' which uses a specific verb and resource. This distinguishes it from sibling tools like 'create_object' which creates objects within a document. The purpose is unambiguous and immediately understandable.

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?

No guidance is provided on when to use this tool versus alternatives. The description gives no context about document hierarchy or when one might prefer creating an object instead. The example is illustrative but does not clarify usage conditions or prerequisites.

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 behavioral burden and does so well: it discloses persistence as a native joint, grounding of the fixed part, solver and numeric/collision validation, rollback on failure, and survival across save/reopen. It does not cover permissions or return/error details, but it is unusually behavior-rich for an unannotated mutation tool.

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 action and is composed of four dense sentences with no filler. It is concise and structured, though the domain jargon makes it slightly harder to parse than ideal.

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 complex mutation tool with no annotations, no output schema, and 0% schema description coverage, the description covers prerequisites and transactional behavior but omits parameter meanings and does not state what a successful call returns. It is adequate but leaves clear gaps for an agent trying to invoke it correctly.

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 0%, and the description does not explain plan_id, assembly_name, or the joint_name default. It only alludes to a 'plan' and an 'Assembly' conceptually, which does not compensate for the undocumented parameters.

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: persist a verified mounting pose as a native Fixed Joint, grounding the fixed part. It also distinguishes the tool from a general constraint-network editor, though it does not name the sibling alignment or assembly tools it depends on.

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 clearly states prerequisites: an applied, still-valid plan and both owners inside an existing native Assembly with no prior joints. It also gives an exclusion (not a general constraint editor), but it does not explicitly name which sibling produces the required plan or compare itself with preview/apply alignment tools.

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 discloses important behavior: it returns success/failure plus a screenshot, include_screenshot defaults to True but can be disabled to save tokens, and Draft factories may return a different object_name than requested. It does not mention permission requirements or detailed failure modes.

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 long, but it is front-loaded with the core purpose and constraints, and the many examples add real value for a tool with a complex, loosely typed obj_properties parameter. Some example material could be trimmed, but most of it earns its place.

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 high-complexity creation tool with nested objects, 0% schema description coverage, and no output schema, the description is substantially complete: it covers the type system, supported factories, returns, screenshots, and many examples. The main gaps are the undocumented analysis_name parameter and missing prerequisite details such as whether the document must already exist.

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 0%, so the description must compensate. Its Args section documents doc_name, obj_type, obj_name, obj_properties, include_screenshot, and view_name, and examples richly illustrate obj_properties; however, analysis_name is only shown in examples and is not documented in Args.

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 begins with a precise verb and resource: 'Create a new object in FreeCAD.' It also explains the type constraints and explicitly distinguishes supported C++/Python-factory object types from unsupported Python types that must use execute_code.

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 boundaries: which obj_type values are supported, which Python types require execute_code, and how to create dependent objects like Part::Cut after creating Base and Tool. It does not explicitly state document-existence prerequisites or when to prefer edit_object over create_object.

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 one explicit behavioral claim is 'No document changes,' which correctly signals a non-mutating operation, plus the disclosure that hole order carries correspondence semantics including symmetric patterns. It does not explain what the tool produces or where the interface is stored, leaving the agent unsure of the result of a successful call.

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 definition before constraints and the owner default; every sentence carries information. The terseness borders on cryptic jargon ('full inner cylinders') but nothing is wasted.

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, unannotated, no-output-schema geometry tool, the description covers the correctness-critical geometry and ordering rules but omits two parameters entirely and says nothing about what the call yields. An agent can probably construct a valid call but cannot predict the outcome.

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 0%, so the description must compensate and it partially does: plane_face is the planar mating face, hole_faces is the ordered cylinder list with order-defined correspondence, and owner has a default plus a Body-name rule. doc_name and part are never mentioned, and no format hints (face reference syntax) are given for the string parameters.

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 ('Define') and resource ('mounting interface') and describes exactly what constitutes the definition: a planar mating face plus two or more ordered full inner cylinders. It is clearly distinct from the sibling tools (assembly/job/object tools), though it never says what the definition is used for downstream.

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?

Provides preconditions rather than routing: cylinders must open onto the plane and be perpendicular, and the 'owner defaults to part' rule with the PartDesign Body case is useful context. It never says when an agent should call this versus other part/assembly tools, but no obvious sibling alternative exists.

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?

The description mentions that it returns a message and screenshot, and that include_screenshot can be set to False for cost savings. It does not disclose whether the deletion is permanent, irreversible, or if there are any side effects (e.g., cascading deletions) beyond the declared return. With no annotations provided, the description carries the full burden, and while it adds some transparency (screenshot behavior), it lacks details on deletion semantics.

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 compact and well-structured: a one-line purpose, clear parameter explanations, and a return statement. Every sentence adds value: explaining the screenshot flag and view orientation selection. No redundancy or fluff.

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's complexity (4 params, no output schema, no annotations), the description provides adequate coverage: it explains all parameters, gives guidance on usage (screenshot for intermediate steps), and states the return. It lacks explicit mention of error conditions or effects of deletion, but for a simple mutation tool, this is reasonably complete. No output schema means description must convey return, which it does.

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 0%, so the description must compensate. It explains doc_name and obj_name (identifying the target), and explains include_screenshot and view_name with their defaults and purpose. However, it doesn't provide additional syntax constraints or examples beyond what the schema already shows (defaults, enums). It does add meaningful context (screenshot token saving logic), which is helpful, but not exhaustive.

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 'Delete an object in FreeCAD' with specific verb (delete) and resource (object in a document). It distinguishes from siblings like edit_object or create_object. However, it could be more explicit that it deletes from a specific document and that deletion is permanent, but the core purpose is clear.

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 context on when to use include_screenshot (e.g., for intermediate steps) and when to set it to False to save tokens. It doesn't explicitly exclude alternatives or mention when not to use, but it implies usage context. No direct comparison to sibling tools like edit_object or get_object, but it does give practical guidance on one parameter.

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 burden. It discloses that it returns a message and screenshot, and gives parameter-specific behavior (including token-saving advice for include_screenshot). However, it does not mention any side effects, reversibility, or required permissions for editing an object, which are important for a mutation tool.

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 structured with a purpose statement, usage note, Args list, and Returns section. It is concise yet detailed, with no filler. The token-saving tip adds operational value without unnecessary length.

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's complexity (5 params, nested obj_properties, enum for view_name, no output schema), the description provides adequate context: all parameters are explained, return type is specified, and usage notes are included. It lacks detailed structure for obj_properties, but that is domain-specific.

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 description explains all five parameters in plain language, including defaults and usage guidance (e.g., 'Pick the view that best shows the change being made'). This fully compensates for the 0% schema description coverage.

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 'Edit an object in FreeCAD' with a specific verb and resource. It also contrasts with create_object, but the phrase 'cannot handle the object creation' makes the relationship between editing and creating somewhat ambiguous, slightly diminishing sibling differentiation.

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 explicitly states 'This tool is used when the create_object tool cannot handle the object creation' and provides guidance for include_screenshot (set False for intermediate steps to save tokens). No other alternatives are mentioned, but this is sufficient.

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 discloses meaningful behavior: 90-second default budgets, a 1800-second cap, timeout-result loss while the task continues, GUI-thread execution constraints, and the default screenshot behavior. It does not explicitly state that arbitrary code can mutate or destroy document state, which is an important safety caveat for this tool.

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 purpose, then structured into Args and Returns. The extra detail on timeout and screenshots is directly actionable, and no sentence is wasteful.

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?

The description covers all parameters and explains the return value despite there being no output schema, making it largely complete for invocation. However, for a tool that executes arbitrary code, it omits explicit warnings about side effects, permissions, or the distinction from execute_code_headless.

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 0%, so the description must compensate, and it documents all four parameters. It explains code, include_screenshot default and token-saving usage, view_name purpose, and timeout semantics including default, cap, budgets, and failure behavior.

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: executing arbitrary Python code inside FreeCAD. It also implicitly differentiates the tool from execute_code_async by recommending that sibling for heavy pure-geometry work, giving an agent enough to distinguish core execution behavior.

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 concrete usage guidance: set include_screenshot to False for token savings, pick the view that best shows the change, raise timeout for slow GUI-thread work, and prefer execute_code_async for heavy pure-geometry work. It does not explicitly compare against execute_code_headless, which is the main gap.

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 provided, the description carries the full behavioral burden and does so thoroughly: it explains the background-thread model, thread-safety hazards, the commit() bridge, shared namespace, RuntimeError behavior, and what happens if the GUI thread is wedged. This is exactly the context an agent needs before invoking a dangerous async tool.

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 long, but the length is justified by the tool's danger and complexity. It is front-loaded with the core behavior and constraints, then provides examples and a typical usage pattern without 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?

It thoroughly covers execution semantics, constraints, and the commit() workflow, including the returned job_id. However, it does not mention the sibling get_async_status for polling the started job, nor does it distinguish from execute_code_headless, leaving a small workflow gap for an otherwise complex async 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?

Although schema description coverage is 0% for the single code parameter, the description compensates fully by defining what code is allowed to do, what it must not do, and how document/view writes must use commit(). It also clarifies the return value as a job_id message.

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—execute Python code in FreeCAD—and immediately clarifies the async/background behavior. It explicitly distinguishes this from the safe default execute_code, so an agent can tell the two apart without inspecting schemas.

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 explicit when-to-use and when-not-to-use rules: ONLY for long-running background computations that do not touch the GUI or mutate the document tree. It names execute_code as the alternative for normal automation and describes the narrow condition where execute_code_async is appropriate.

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 zero annotations, the description carries the full burden and does it well: crash isolation ('only kills the helper process; the GUI and its open documents survive'), process independence from --host, no GUI, no execute_code namespace, mandatory manual imports, stdout capture, and partial-output preservation on timeout. These are exactly the behavioral facts an agent cannot infer from the schema.

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?

It is front-loaded with the core definition and then uses a tight Args/Returns block, so structure is strong. It runs slightly long and repeats the isolation idea in two places, but no sentence is 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?

There is no output schema, and the description supplies the return contract (exit status, crash/timeout diagnosis, printed output). Together with the isolation model, import requirements, and the reload_document handoff, an agent has everything needed to invoke it correctly.

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 0%, so the description must compensate, and it does: `code` is specified as a 'complete Python script for freecadcmd' (i.e., stateless, self-contained), and `timeout` is constrained to 'positive finite seconds,' given a default of 600, and its failure mode (partial output preserved) is described.

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 first sentence states a specific verb, resource, and execution context: run a FreeCAD Python script in a separate headless `freecadcmd` process. It also implicitly separates this from the in-process `execute_code` sibling by noting that 'Nothing from the execute_code namespace is available,' so an agent can tell which tool it is looking at.

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?

'Use this for OCCT work that can crash or block FreeCAD' followed by concrete triggers (helical threads, lofts/sweeps, large booleans, long rebuilds) gives the selection criterion directly. It also supplies a required follow-up action: 'After the script saved a .FCStd that is open in the GUI, call reload_document(doc_name).'

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, no output schema, and no parameter documentation, the description carries the full behavioral burden and does not meet it. 'Check' weakly implies a read-only operation, but nothing is said about what is returned, whether it can fail, or whether the result should be cached or re-fetched per session.

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?

One short sentence with the action front-loaded and the timing hint trailing it; nothing is redundant. It is arguably too terse rather than too long, but structurally it is clean.

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-param discovery tool with no output schema and no annotations, the description should at minimum characterize the returned capability information so an agent knows how to act on it. It establishes the pre-flight intent but leaves the payoff undefined.

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 schema baseline is 4 and there is nothing further for the description to disambiguate. No parameter-level gaps exist.

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 verb/resource pair ('Check' + 'assembly capabilities') indicates a discovery call that returns protocol and operation support, but 'native addon protocol' is jargon and the description never says what a capability report actually contains. It also does not distinguish this from nearby lookalikes such as check_assembly or get_rpc_status.

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?

'before working' implies a call-first sequencing hint, which is genuinely useful for a gating/discovery tool. However, there are no explicit conditions, no statement of when it can be skipped, and no named alternatives among the many assembly siblings.

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 and does a good job: it discloses the outcome_unknown token and its meaning (GUI exceeded dispatch budget, job may still finish), an idempotency/safety rule (do not re-issue the mutation), and a result-retention policy (until history eviction at 32 completed jobs or FreeCAD exit). It stops short of saying whether the poll itself has side effects or cost, and it never mentions include_result.

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, front-loaded segments with no filler: the core action first, then the outcome_unknown caveat, then the retention note. The sentence fragments ('Poll without waiting for the GUI') are slightly clipped but each line earns its place.

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?

There is no output schema, so the description must cover return semantics, and it partly does (durable outcome, PNGs, outcome_unknown). But for a 2-parameter poll tool it leaves include_result entirely unexplained and does not describe the shape of a non-final response, which is the thing an agent will most often receive.

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 0% and the description never names job_id or include_result. The phrase 'Includes durable outcome and native PNGs when done' hints at what the result payload contains, but it does not tell the agent that include_result toggles that payload, nor what job_id format/lifetime is expected. Two undocumented parameters at 0% coverage with no compensating text is a clear gap.

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 the action ('Poll without waiting for the GUI') and what the tool yields ('durable outcome and native PNGs when done'), which makes it readable as a job-status poll for an assembly job. It does not explicitly name the resource (job) or distinguish itself from siblings like get_rpc_status or get_async_status, so a 4 rather than a 5.

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 a concrete usage rule for the ambiguous case: on outcome_unknown, 'continue polling; do not duplicate the mutation.' That is exactly the guidance an agent needs and it is stated explicitly. It does not, however, contrast this tool with alternative status tools (get_async_status, get_rpc_status), so the alternative-selection dimension is left implicit.

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 full burden and does it well: it discloses that the call bypasses the FreeCAD GUI thread and answers while a job runs, that history lives only in memory until FreeCAD exits, and that failures return an error plus traceback.

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?

It is front-loaded: the purpose and the thread-safety guarantee come first, then Args and Returns. The structure is clean, though the Args/Returns scaffolding is slightly heavier than this one-parameter tool needs.

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 read with no output schema, it covers state values (running/done/failed), error/traceback on failure, and history lifetime, which is nearly everything needed. It leaves open how to retrieve a completed job's actual output or result, which is the one gap.

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 0%, so the description must compensate, and it does: job_id is defined as the id returned by execute_code_async, and the empty-string default is explained in terms of what is listed rather than just repeating the type.

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 ('Report the state of background jobs') and anchors it to the originating tool (execute_code_async), so an agent can distinguish it from get_rpc_status and get_assembly_job 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?

The description makes clear this follows execute_code_async and that an empty job_id lists all running plus up to 20 recently completed jobs, which is a concrete usage rule. It does not explicitly exclude cases or name a sibling alternative, keeping it just below a 5.

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 provided, the description carries the full behavioral burden and does so well: it explicitly states that the tool only reads, never saves or recomputes, and explains subtle dirty-flag behavior including the null case meaning the flag could not be read rather than assumed clean. It also discloses the App.save()/saveAs() caveat about the GUI modified flag.

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 core read-only purpose and then explains parameter behavior and return-field semantics compactly. Every sentence earns its place, especially given the absence of an output schema and annotations.

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?

There are no annotations and no output schema, so the description must explain both behavior and return-field meaning. It does this thoroughly by defining modified, saved_once, needs_recompute, needs_save, file_path, and file_exists, including the important null semantics for needs_save.

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 0%, so the description must compensate for the lone doc_name parameter. It does so by explaining that an empty string lists all documents and a named value inspects that document, which is the key semantic needed to invoke the tool correctly.

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: read document status for open documents, explicitly without saving or recomputing. It is clear enough to distinguish from mutation tools like create_document or reload_document, though it does not name a sibling alternative such as list_documents.

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 clearly explains the usage split: an empty doc_name lists all documents, while a non-empty value inspects one named document. It does not compare directly against sibling list or inspect tools, but the operational guidance for this tool is clear.

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 provided, the description carries the burden and does disclose helpful behavioral details: it returns both the object and a screenshot, and explains that include_screenshot=False saves tokens. It does not explicitly say the operation is read-only, but the retrieval semantics and return wording make that a safe inference.

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 compact and well-organized: a clear one-sentence purpose, a practical use statement, an Args section, and a Returns line. There is no unnecessary fluff or repeated schema enums.

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 retrieval tool with no output schema and no annotations, the description covers required parameters, optional parameters/defaults, and return shape. It is mostly complete, though it could mention behavior when include_screenshot is false and how the returned object data is structured.

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 schema gives 0% parameter descriptions, so the Args section compensates by explaining all four parameters: doc_name, obj_name, include_screenshot, and view_name. It adds useful meaning such as token-saving behavior for include_screenshot and return-screenshot orientation for view_name.

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?

Description clearly states it gets an object from a document and clarifies that this is for inspecting its properties before checking or editing them. This aligns with the sibling set but does not explicitly distinguish it from get_objects or get_view.

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 a clear intended use case: get the properties of an object to see what can be checked or edited. It does not mention exclusions or compare with alternatives, but the context is specific enough to guide basic selection.

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 burden. It discloses that include_screenshot defaults to True and can be set to False to save tokens, and that view_name controls the screenshot orientation. However, it doesn't mention any side effects, permissions, or performance implications beyond token usage. It's a read operation implied by 'get', but not explicitly stated as non-destructive.

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 concise and well-structured with an Args/Returns section. It front-loads the purpose and provides practical usage tips. No wasted words, though the Returns section is minimal.

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's moderate complexity (3 params, 1 required, no output schema), the description covers the basics but lacks detail on return structure, error cases, or how the screenshot relates to the object list. It's adequate for a simple read tool but could be more complete.

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 0%, so the description must compensate. It explains doc_name, include_screenshot (with token-saving tip), and view_name (orientation). However, it doesn't detail the enum values for view_name beyond the schema, and the return format is only briefly mentioned. The description adds some value but not comprehensive parameter guidance.

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 tool's purpose: 'Get all objects in a document' and explains its use case ('to see what you can check or edit'). It distinguishes from sibling tools like get_object (singular) and get_view, though it doesn't explicitly name alternatives. The verb 'get' and resource 'objects in a document' are specific.

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 implies usage: use this to get objects for checking or editing. It doesn't explicitly state when not to use it or mention alternatives like get_object for a single object. The context is clear but lacks exclusions or comparisons to siblings.

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 burden of behavioral disclosure. It only says 'get the list' but doesn't clarify whether this is a read-only operation, what the response format is, or any other behavioral nuances. For a simple list tool this is a notable 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?

The description is a single sentence that directly states the tool's purpose. It is front-loaded and contains no unnecessary filler, making it easy for an agent to quickly parse.

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 zero-parameter nature and simple purpose, the description is minimally viable. However, with no output schema and no annotations, it lacks additional context such as the structure of the returned list or how it relates to sibling tools like insert_part_from_library.

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 has zero parameters, so the description cannot be expected to explain parameter semantics. The baseline for 0-parameter tools is 4, and the description sufficiently identifies what the list pertains to.

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 ('Get the list') and the resource ('parts in the parts library addon'), making the tool's basic purpose obvious. It does not explicitly distinguish it from siblings like insert_part_from_library, but the distinction is fairly apparent from the descriptions themselves.

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 no guidance on when to use this tool versus alternatives. It doesn't mention that it might be a prerequisite for insert_part_from_library or any other usage context.

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, and it does real work: it discloses the non-GUI-thread execution model, the survival-after-timeout property, and the meaning of the 'stuck' state (an operation still running, restart may be needed). It does not explicitly confirm the call is side-effect free or describe the response beyond two fields.

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 paragraphs, front-loaded with the purpose, then the availability guarantee, then the two return-state semantics. Every sentence adds information an agent would otherwise lack; none is 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 zero-parameter, read-only diagnostic with no output schema, the description covers the essentials: execution model, availability, and the meaning of key status values. It leaves the rest of the response shape undocumented, which is a minor gap given there is no output schema to lean on.

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 for the description to disambiguate. Baseline 4 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: 'Get RPC and FreeCAD GUI-dispatch health.' It is clearly a diagnostic/status tool, distinguishable from action siblings like create_object or run_fem_analysis. It stops short of naming the nearest alternatives (get_async_status, get_document_status), so an agent must infer 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?

Provides a concrete usage condition: 'This tool does not use FreeCAD's GUI thread, so it remains available after a GUI operation times out.' That tells an agent exactly when to reach for it. It never names an alternative tool or states when not to use it, so it falls short of a 5.

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 present, so the description carries the full burden. It only states that a screenshot is returned and does not disclose whether the operation is read-only, whether a document must be loaded, what format the screenshot takes, or any side effects or error conditions.

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 well organized with Args and Returns sections and is appropriately concise. The view list is redundant with the schema enum and the final 'Returns' line largely restates the first sentence, but the overall structure is clear and scannable.

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?

The tool has four parameters, no annotations, and no output schema, so the description must carry more weight. It explains parameter defaults well and gives a basic return statement, but it omits the exact output format, prerequisites, and any caveats about view state or object focus behavior.

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?

Although schema description coverage is 0%, the description adds meaningful semantics for all four parameters: view_name lists the valid values, width/height explain default viewport fallback, and focus_object explains the fit-all-objects default. This goes well beyond the raw schema defaults.

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 'Get a screenshot of the active view' and enumerates the available standard views, making it distinguishable from sibling get_* tools that return object data. Some ambiguity remains because 'active view' could imply the current viewport while view_name explicitly selects one of the listed views.

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?

There is no explicit guidance on when to use get_view versus alternatives such as get_object or execute_code. The purpose is implied by the verb and parameter descriptions, but no prerequisites, exclusions, or sibling comparisons are provided.

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 discloses the return behavior (message plus screenshot) and the token-saving rationale for include_screenshot=False. However, it does not explicitly state side effects on the current document, failure conditions beyond a generic message, or path-resolution 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 well-structured with a one-sentence purpose, an Args section, and a Returns section. Every sentence adds useful information, and the guidance about saving tokens is valuable without being verbose.

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's low complexity, no annotations, and no output schema, the description covers the essential invocation details: path, screenshot toggle, view selection, and return value. It could be more complete by clarifying what 'insert' modifies and where relative_path resolves, but it is otherwise adequate for an agent to invoke the 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?

Schema description coverage is 0%, so the description must compensate. It explains all three parameters, including defaults and usage guidance for include_screenshot and view_name. The main gap is relative_path: it says 'relative path' but does not specify relative to what directory or library root.

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 opens with a specific verb and resource: 'Insert a part from the parts library addon.' This clearly distinguishes it from siblings like create_object or edit_object, and the tool name reinforces the library-source scope.

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 clear context for the tool's main use and provides practical guidance for include_screenshot and view_name. However, it does not explicitly state when to prefer this tool over alternatives such as create_object, nor does it mention exclusions or prerequisites.

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 traits: it is read-only in effect ("Does not move parts or change the camera"), faces are paginated at 1..500 per type, and face names are temporary references rather than stable IDs. It omits any mention of permissions, error conditions, or what the response actually contains.

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?

Five short sentences, front-loaded with the purpose before the sequencing advice and the pagination caveat. Little waste, though the define_interface aside sits slightly awkwardly between the read-only disclaimer and the pagination detail.

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 tool with no annotations and no output schema, the description covers behavior and paging but not the return shape or the two required identity parameters (doc_name, part). An agent can call it, but must guess at the response structure and at how part is identified.

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 0% across five parameters, so the description must compensate, and it explains pagination and the offset semantics. However, it names the offsets as next_plane_offset/next_cylinder_offset while the schema calls them plane_offset/cylinder_offset, and it says nothing about doc_name, part, or the exact meaning of feature_limit, leaving two required parameters completely unexplained.

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 first sentence names a specific verb (inspect) and the concrete resources returned (valid world-space geometry, planar faces, cylindrical hole candidates), which is far more than a restated name. It does not explicitly differentiate itself from the sibling inspect_region, so the boundary between the two inspection tools is left to inference.

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?

"Start here before assembly work" gives a clear sequencing rule, and naming define_interface as the follow-up for persistent face binding is genuinely useful routing. It also points at feature_counts for full totals, implying the paginated path is for enumeration only, but it never states when inspect_region would be preferred 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?

With no annotations, the description carries the full burden and does disclose key side effects: it temporarily hides other objects and restores camera/visibility, and it caps output at 1..6 views and 256..1536 px. It omits failure modes, latency, and whether the restore happens on error, which keeps it below top marks.

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?

Short, front-loaded with the core capability, and each sentence adds information (defaults, side effects, precondition, size constraint). The telegraphic phrasing ('1..6', 'size is square pixels') is dense but not padded.

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 4-parameter tool with no annotations and no output schema, the description covers what the tool produces (PNG images), how it scopes them (selected parts, chosen views), and the state it disturbs and restores. Only error/permission behavior is left unaddressed.

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 0%, so the description must compensate, and it does: parts (which objects are isolated), views (default Isometric/Top/Right, 1..6 count), size (square pixels 256..1536), and doc_name (must be active in 3D) are all explained. It stops short of enumerating valid view names beyond the three defaults.

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 action (render 1..6 focused views of selected parts) and a concrete output (native MCP PNG images with world-geometry fingerprints). It differentiates itself from check_assembly as a visual supplement, but does not distinguish itself from siblings like inspect_part, get_view, or preview_alignment.

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?

Provides a precondition ('Requested document must be active in 3D') and a use-case link ('supplements check_assembly'), which gives implied guidance. It never says when to prefer this over inspect_part or get_view, or when not to use it, so the agent must infer alternative selection.

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 discloses the default result (document names) and the expanded status fields when include_status is true, but does not explicitly state that the operation is read-only, whether it can fail, or what permissions are required.

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 core purpose and is generally efficient. The 'Returns' section and default clarification are useful, though slightly more compact phrasing could reduce minor 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 simple list tool with one optional parameter and no output schema, the description covers the essential behavior and return shapes. It lacks error or permission context, but that is a minor gap for a read-oriented listing operation.

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 0%, so the description must compensate for the single boolean parameter. It does so effectively by explaining that include_status=true returns labels, file paths, modified flags, needs_save, and needs_recompute, and that the default returns names only.

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 gives a specific verb and resource: 'Get the list of open documents in FreeCAD.' This clearly identifies the tool's scope, though it does not explicitly name or distinguish itself from siblings such as get_document_status or get_objects.

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 explains how the include_status parameter changes the result, but gives no guidance on when to use this tool versus alternatives like get_document_status or get_objects. There are no when-to-use or when-not-to-use statements.

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 and does substantial work: it discloses non-mutation, the sign convention for gap ('positive gap follows the fixed face outward normal'), validation behavior (all hole matches checked, stale geometry and degenerate patterns refused), collision scope during apply, and handle lifetime ('expire after FreeCAD restart/code update'). It still omits what the returned handle looks like and what a refusal surfaces.

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?

Purpose and the mutation disclaimer are front-loaded, and the remaining telegraphic lines each carry a distinct operational fact. The clipped phrasing ('Handles expire after...') is dense but not padded.

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 7-parameter, 0%-schema-coverage tool with no annotations and no output schema, the description covers the workflow and validation rules but leaves the three tolerance parameters and the return/handle semantics undefined. Adequate to start a call, not enough to call it confidently with non-default tolerances.

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 0% across 7 parameters, so the description must compensate and only partly does: it explains gap sign convention and obstacles (named parts plus nearby parts). tolerance_mm, angular_tolerance_deg, collision_tolerance_mm3, and the two interface strings are left entirely unexplained beyond a vague hint about matching holes and mounting faces.

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: plans a rigid placement by matching ordered holes and opposing mounting faces, and declares 'No mutation' to separate it from apply_alignment. Clear enough to identify the operation, though it never distinguishes itself from the closely named sibling preview_alignment.

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?

'Review this plan, then apply_alignment' gives an explicit two-step workflow and tells the agent this is the planning half of a plan/apply pair. It also advises including nearby parts in the collision scope. It does not say when to prefer this over preview_alignment or what to do when the plan is refused.

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 load and does well: it declares read-only semantics ('without changing the document'), an output artifact ('native PNGs'), and a cleanup side effect ('removes all temporary scene-graph overlays afterwards'). It stops short of saying how the PNGs are delivered (paths vs. inline) or what happens on failure mid-cleanup.

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 core promise and no wasted sentences; the no-mutation guarantee is repeated as a closing clause for emphasis. The 'cyan ghost + green/orange axes' fragment is jargon-dense but conveys the visual output efficiently.

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 tool with no annotations, an undocumented 'size' parameter, and no output schema, the description is adequate but not whole. It covers behavior and side effects well yet leaves the agent guessing about image dimensions/resolution semantics and how the produced PNGs come back.

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 0%, so the description must compensate. It hints at plan_id constraints ('fresh and unapplied') but never explains the identifier's origin or format, and the 'size' parameter is never mentioned at all, leaving one of two parameters completely opaque.

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+resource ('See the proposed placement') and immediately bounds the scope ('without changing the document', 'Does not add document objects or move parts'). It implicitly separates itself from a committing sibling, though it never names apply_alignment, so differentiation relies on inference.

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 real precondition: 'The plan must be fresh and unapplied', which tells the agent when this call is valid and implies it precedes an apply step. It does not explicitly name apply_alignment as the alternative or say what to do if the plan has already been applied.

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 well: it discloses that the in-memory copy is closed and replaced ('closes the stale in-memory copy'), and warns about a non-obvious identity side effect — the reopened document is renamed after the file stem and the reply names the new identifier. It does not explicitly say whether unsaved in-memory edits are discarded or whether the operation can be undone, which is the one material behavioral gap for a destructive-ish reload.

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 purpose then precondition, followed by Args/Returns/Examples — a clean structure. The Returns paragraph and the naming parenthetical are somewhat long, though both convey genuinely non-obvious information rather than 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?

No output schema exists, and the description supplies the return semantics itself: a confirmation message or a described failure mode (document not loaded, no associated file), plus the renamed-document caveat. For a single-parameter tool with no annotations, everything an agent needs to call it and interpret the result 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 0%, so the description must compensate, and it does: doc_name 'Must match the name shown by list_documents', tying the argument to a concrete source of truth. It further explains that the name may change after reload ('HandleConcept3D' → 'handle_concept_3d'), which is semantic information no schema field could 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?

Specific verb+resource ('Close and re-open a document') with the immediate purpose (pick up external file changes) stated up front. It is clearly distinguished from sibling reads like list_documents and get_document_status, which merely report state rather than resynchronize 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?

Explicitly conditions use: 'Use this AFTER the document's .FCStd file has been modified by something outside of FreeCAD's GUI process — for example, a headless freecadcmd script.' It also explains the counterfactual (the GUI is unaware of on-disk changes), which implicitly excludes use for in-GUI edits. It routes the agent to list_documents for obtaining doc_name.

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 provided, the description carries the full responsibility and handles it well. It discloses that a SolverCcxTools is auto-created if absent, that execution blocks the GUI thread synchronously, what happens on failure, and what return values are produced. This is substantial behavioral transparency beyond the input schema.

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 well-structured with clear labeled sections: prerequisites, behavior note, return values, and arguments. It is long because the tool is complex, but every sentence provides necessary operational detail without 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?

Given the tool has 5 parameters, no annotations, and no output schema, the description is remarkably complete. It covers prerequisites, side effects, synchronous blocking, failure behavior, output data, and parameter semantics, giving the agent all needed context to invoke the tool correctly.

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 schema has 0% description coverage, but the Args section fully compensates by explaining every parameter beyond raw schema definitions. It adds practical guidance such as 'Set to False to save tokens when only the numeric results are needed' for include_screenshot and clarifies the meaning of timeout and view_name.

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 opens with a specific verb and resource: 'Run the CalculiX solver on an existing Fem::FemAnalysis container and return summary results.' This clearly distinguishes it from sibling tools like create_object, get_object, and edit_object, which manage objects rather than execute an analysis.

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 prerequisites section thoroughly explains the conditions required before using the tool, and the blocking-behavior warning explicitly tells the agent when not to use it in parallel: 'do not fan out parallel requests.' It does not explicitly name alternative tools, but no sibling tool provides equivalent functionality, so the context is clear.

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 well: it discloses idempotency semantics (same request_id + different args fails), retention window tied to addon history, and lifecycle (survives MCP restart but not FreeCAD exit). It does not mention permissions, rate limits, or what happens to a partially completed job on FreeCAD exit, 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.

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

The retry/idempotency guidance and the return-and-poll instruction are front-loaded, and every sentence carries information. The fragmentary, telegraphic style ('No arbitrary Python.', 'Returns job_id; poll get_assembly_job.') is dense but readable.

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 an async submit tool with no output schema, the description covers the return value (job_id), the polling path, and job lifetime, which is what an agent needs to drive the workflow. The remaining hole is the shape of the 'arguments' payload, which neither schema nor description 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 0%, so the description must compensate. It thoroughly explains request_id (idempotency key semantics, mismatch failure) and points to where valid operation values come from, but the required 'arguments' object is left entirely unexplained despite being a free-form nested object whose shape presumably depends on the operation.

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?

Opens with a specific verb+resource: 'Submit a native CAD job immediately'. It also distinguishes itself from the code-execution siblings by stating 'No arbitrary Python', and from synchronous tools by saying to use it for long operations. Slightly indirect in that the primary action is described via its async behavior rather than naming the assembly operation 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?

Gives clear conditions: use for long operations instead of blocking on a tool call, and consult get_assembly_capabilities for the allowed operation set. It sets a real exclusion ('No arbitrary Python'), though it never states when a synchronous sibling would be preferable or what happens if the operation name is invalid.

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