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

With no annotations, the description carries the full burden for behavioral disclosure. It mentions that the operation returns a success/failure message, but it does not disclose potential side effects, permissions, or behavior when a document with the same name exists. For a mutation tool, this is insufficient.

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 Args, Returns, and Examples, front-loading the purpose. It is slightly verbose for a one-parameter tool but every section adds value, and the example is helpful.

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 is simple with one parameter, and the description covers input, output, and example usage. An output schema exists (even if not shown), and the description already explains the return message. It is complete enough for an agent to invoke 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 no description for the 'name' parameter (coverage 0%), but the description explicitly states 'The name of the document to create' and provides an example. This adds meaning beyond the schema, effectively compensating for the 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 clearly states 'Create a new document in FreeCAD', which is a specific verb and resource. It distinguishes itself from sibling tools like create_object or create_sketch by focusing on document-level creation, and the example reinforces the purpose.

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 does not mention when not to use it or reference other tools. The example shows basic usage but lacks contextual guidance.

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, and the description does not disclose behavioral traits such as error handling, side effects (e.g., behavior if the object already exists), or required permissions. The mention of returning a success/failure message and screenshot is minimal.

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 quite lengthy due to multiple examples. While front-loaded with a clear one-liner, the subsequent examples repeat similar patterns and could be condensed. Adequate but not concise.

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 complexity (5 parameters, nested objects, output schema), the description covers many object types and properties through examples. However, it lacks information on error conditions, prerequisites, and details about the return value (despite an output schema existing).

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 input schema has 0% description coverage, but the description compensates with detailed examples that illustrate the usage of each parameter, especially obj_properties. The examples add significant meaning beyond the raw schema, covering diverse cases like FEM constraints and materials.

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 object in FreeCAD' and specifies valid object type prefixes, differentiating it from sibling tools like delete_object or edit_object. Examples cover a range of object types, making the purpose unmistakable.

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 explicit guidance is given on when to use this tool versus alternatives. The description lists object types and provides examples but does not indicate when to prefer this tool over others like edit_object or get_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 provided, the description alone must disclose behavioral traits. It mentions the return value (message and screenshot) but does not state that deletion is permanent, irreversible, or whether it affects dependent objects or requires confirmation. This lack of safety/impact disclosure is significant for a destructive operation.

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

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

The description is compact and well-structured: a one-sentence purpose, an Args list, and a Returns line. Every sentence serves a clear function with no 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?

The tool is simple (2 required string parameters) and the description covers its purpose, arguments, and return value. However, it lacks any mention of prerequisites (e.g., document must exist), error behavior, or side effects beyond the obvious deletion, leaving some gaps for a destructive 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?

The input schema offers no descriptions for the two parameters (0% coverage), but the description's Args section explicitly explains both doc_name and obj_name, adding meaning beyond the schema. It clarifies the document and object references, compensating for the schema 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 uses a specific verb ('Delete') and resource ('an object in FreeCAD'), clearly distinguishing it from siblings like create_object, edit_object, and get_object. No other sibling tool has 'delete' in its name, so 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?

The description only states the action without providing explicit guidance on when to use this tool versus alternatives. It implies usage for deleting objects but offers no exclusions or alternative tool references. The context is clear from the purpose, but no explicit usage guidance is given.

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 full burden. It discloses the return value ('a message... and a screenshot') but omits critical behaviors: whether the object must exist, how obj_properties merges or replaces existing properties, and any side effects on the document. This is insufficient 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 short and front-loaded with the primary action and use case. The Args section repeats schema information, but the overall structure is clear and no sentences are 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?

Given the tool has 3 params with a nested object, no annotations, and an output schema (not detailed), the description does not provide enough context. It lacks error handling, prerequisites, and the structure of obj_properties. It also doesn't help choose between edit_object and the many sibling operations like pad, pocket, or fillet.

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. The parameter descriptions merely restate the parameter names: 'doc_name: The name of the document to edit the object in' provides no additional detail about how obj_properties should be structured or what property names are valid. This adds minimal meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Edit an object in FreeCAD' and specifies a use case: 'used when the create_object tool cannot handle the object creation.' This differentiates it from create_object, though not from other editing tools.

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 names an alternative (create_object) and describes when to use this tool: 'when the create_object tool cannot handle the object creation.' However, it doesn't provide broader guidance on when not to use it or how it relates to other editing operations like pad or pocket.

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 full burden. It discloses that execution can be arbitrary, and returns success/failure, output, and a screenshot. However, it omits security implications, timeouts, or side effects.

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 extremely concise: two sentences plus an Args/Returns block. It front-loads the purpose, and every sentence serves a clear function 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 single parameter and existing output schema, the description explains the return values (message, output, screenshot) well. Minor gaps (no execution limits, environment details) prevent a 5.

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%, but the description only restates the parameter name and type ('code: The Python code to execute'), adding no additional meaning like format, examples, or constraints.

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 'Execute arbitrary Python code in FreeCAD' with a specific verb ('execute') and resource ('Python code'), clearly distinguishing it from sibling tools like create_object 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?

No guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description merely states what it does, leaving the agent to infer 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?

Despite lacking annotations, the description thoroughly discloses behavior: runs in background thread, returns immediately, restrictions on GUI/document access. It also outlines a four-step usage pattern, providing full transparency.

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 detailed but well-structured with clear sections (when to use, what not to do, typical pattern). Every sentence serves a purpose, though slightly verbose; could be tightened without losing 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?

Given the tool's complexity (async execution, threading constraints), the description covers all necessary context: purpose, restrictions, alternatives, usage pattern, and return value. The output schema is mentioned, making it 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 coverage is 0%, so the description must add meaning. While not listing parameters explicitly, it explains the 'code' must be background-safe Python, which adds context beyond the schema's minimal 'Code' title. The usage pattern further clarifies what code is acceptable.

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: 'Execute Python code in FreeCAD without waiting for completion.' It explicitly distinguishes itself from the sibling 'execute_code' by specifying thread context and allowed operations.

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 explicit guidance: 'Use this ONLY for long-running background computations...' and clearly states when not to use it (GUI/document modifications). It names the alternative 'execute_code' and explains the typical usage pattern.

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 that the tool returns the object and a screenshot, adding useful behavioral context. However, it does not explicitly state that the operation is read-only or free of side effects, though the 'get' wording implies 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 concise, front-loaded with the core purpose, and neatly structured with separate Args and Returns sections. Every word contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter getter, the description covers purpose, parameters, and return behavior, and an output schema exists to detail the return type. It lacks explicit sibling differentiation or usage caveats, but nothing critical is missing for a basic read 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?

The schema provides only parameter titles with no descriptions, so the description compensates by explaining doc_name ('name of the document to get the object from') and obj_name ('name of the object to get'). This gives clear meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Get an object from a document' and further explains it retrieves properties for inspection. It distinguishes itself from siblings like get_objects (plural) and get_view by focusing on a single object.

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

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

The description provides clear context: use it to retrieve object properties to see what can be checked or edited. It implies a pre-edit inspection usage, but does not explicitly mention alternatives or exclusions, 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 provided, so the description must convey behavior. It does state the return value (list of objects plus a screenshot) which is helpful, but it does not explicitly say whether the operation is read-only or whether there are side effects, permissions, or other caveats. For a getter, this is a moderate disclosure.

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, front-loaded with the main action, and includes a clear Args/Returns structure. Every sentence provides useful information 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?

With only one parameter, an existing output schema, and a straightforward purpose, the description is complete. It explains what to expect and how to invoke the tool. No critical context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for parameters, but the tool description includes an Args section explaining 'doc_name: The name of the document to get the objects from.' This fully clarifies the only parameter and exceeds the baseline expectation.

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 all objects in a document' with a specific verb and resource, and distinguishes from sibling tools like get_object (singular) by indicating it returns all objects. It also explains the purpose ('to see what you can check or edit'), making it 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?

The description provides a clear use case: use this tool to retrieve objects for inspection or editing. It does not explicitly mention alternatives or when not to use it, but the context is sufficient for a simple tool with obvious applicability.

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 disclosing behavior. 'Get' implies a read-only operation, but it does not explicitly state there are no side effects, nor does it mention any permissions or limitations. The description is minimally adequate but lacks richer behavioral context.

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

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

The description is a single, concise sentence that front-loads the action and resource. Every word earns its place, there is no fluff, and it is appropriately sized for a simple getter tool.

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 is simple with no parameters and an output schema available. The description covers the essential purpose, and the output schema handles return details. However, it does not mention any prerequisites or usage context, so slightly less than a perfect score.

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?

There are zero parameters, so the description does not need to explain parameter semantics. The baseline for no parameters is 4, and the description adds no misleading or extra information, so this score is appropriate.

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) and resource (the list of parts in the parts library addon). It is specific and distinguishes from sibling tools like insert_part_from_library, which inserts rather than lists.

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 only states what it does, not the context or exclusions, leaving the agent to infer when listing parts 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 no annotations, the description carries the full burden of behavioral disclosure. It does not clarify side effects (e.g., whether the active view changes), output format (e.g., file path, base64), or any permissions or limitations. The return value is only vaguely described as 'A screenshot of the active view.'

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/Returns sections and is mostly concise. Minor redundancy exists ('Get a screenshot of the active view' repeated in the Returns), but it remains easy to scan and front-loaded.

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 parameter documentation is strong, but behavioral context is thin: no side effects, no output format, no usage guidance. The inconsistency between 'active view' in the title and selectable view_name also creates ambiguity. An output schema exists, so return details are less critical, but the description still leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds substantial meaning beyond the bare schema: it explains width/height in pixels with viewport defaults, focus_object behavior (fits all objects), and enumerates valid view names. 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 the tool's function: 'Get a screenshot of the active view.' The verb 'Get' and resource 'screenshot' are specific, and the detailed view_name enum distinguishes this from sibling tools like get_object and 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?

No guidance is provided on when to use this tool versus alternatives, nor are any exclusions or alternative tools mentioned. The description only states the basic operation, leaving the agent to infer 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?

With no annotations, the description carries full responsibility for disclosing behavioral traits. It only states that it returns a success/failure message and a screenshot. It does not mention whether it modifies the current document, requires an active document, or has any side effects. This is insufficient 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 extremely concise and well-structured. It opens with a one-sentence purpose, then uses clear 'Args' and 'Returns' sections. Every sentence serves a purpose, and there is no wasted text.

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 (one parameter) and the presence of an output schema, the description is somewhat adequate. However, it lacks usage context and any safety or side-effect information, especially since annotations are absent. For a simple insert operation, it covers the basics but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate. It provides one line: 'relative_path: The relative path of the part to insert.' This adds basic meaning over the schema's bare title 'Relative Path', but it is still minimal and does not explain the path's base directory or format.

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 action with a specific verb ('Insert') and resource ('a part from the parts library addon'). This distinguishes it from siblings like 'get_parts_list' (which lists parts) and 'create_object' (which creates from scratch).

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 given on when to use this tool versus alternatives. It does not mention any prerequisites, contexts, or specific scenarios where this tool should be preferred. The sibling list includes related tools like 'instantiate_family' and 'get_parts_list', but the description offers no differentiation.

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 the return format ('a list of document names'), which is helpful. However, it does not explicitly state that the operation is read-only, has no side effects, or describe behavior when no documents are open. The lack of such detail is a gap, but the verb 'Get' and the nature of listing imply a safe read operation.

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

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

The description is two sentences, front-loaded with the primary purpose and immediately followed by the return type. Every word earns its place, with no irrelevant detail or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, output schema exists, no nested objects), the description is complete. It clearly states what the tool does and what it returns. With an output schema present, the return value specification is adequately covered, and the mention of 'FreeCAD' provides the necessary context.

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 schema coverage is trivially 100%. The description adds no parameter-specific information because there are none to describe. The baseline for zero parameters is 4, and the description is consistent with this, providing no ambiguity.

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 uses a specific verb ('Get') and resource ('the list of open documents in FreeCAD'), making the purpose unambiguous. It clearly distinguishes this from siblings like create_document or get_objects, which have different actions and targets.

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 when you need to know which documents are currently open, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. For example, there is no guidance like 'use this instead of get_objects to enumerate documents rather than objects within a document.'

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 explains the internal behavior (closes the stale in-memory copy and reopens from disk), describes potential failure modes (document not loaded, no associated file), and notes that the return message will confirm or describe the failure. While it doesn't explicitly warn about unsaved changes being lost, the overall behavior is disclosed well.

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 and front-loaded: the opening sentence immediately states the core purpose. Subsequent sections (Args, Returns, Examples) are clearly labeled and concise. Every sentence earns its place, providing necessary context 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?

For a single-parameter tool with a simple behavior, the description is complete. It covers the purpose, use case, parameter semantics, return values, and includes an example. The output schema exists and the description appropriately explains what the return will be, so no further details are needed.

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 coverage is 0%, but the description fully compensates with an Args section that explains doc_name is 'The name of the open document to reload' and instructs that it 'Must match the name shown by list_documents.' This adds meaning beyond the bare schema field name, giving the agent precise guidance on how to provide the parameter.

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 action: 'Close and re-open a document to pick up external file changes.' This is a clear verb+resource+scope, and it distinguishes the tool from siblings by specifying the unique use case of re-syncing with on-disk changes. It is not a tautology and clearly communicates the tool's function.

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 explicit when-to-use guidance: 'Use this AFTER the document's .FCStd file has been modified by something outside of FreeCAD's GUI process.' It also provides a concrete example (headless freecadcmd script) and explains why it is needed (the GUI is unaware of external changes). It does not explicitly list when-not-to-use or alternatives, but the context is clear and sufficient for the intended use case.

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 takes full responsibility for behavioral disclosure. It reveals that SolverCcxTools is auto-created if missing, that execution blocks the GUI thread and all RPC calls, and that on failure it returns error details and the working directory. It also specifies the return values (max von Mises stress, displacements, node count, working directory).

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 sections (Prerequisites, behavior, Returns, Args). Every sentence provides necessary information, and the length is justified given the tool's complexity. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is comprehensive: it covers prerequisites, execution mode, side effects (auto-creation), failure handling, return values, and all parameters. The presence of an output schema further reduces the need to document returns, but the description already does so. It is fully sufficient for an agent 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?

Schema description coverage is 0%, so the description is the sole source of parameter meaning. It clearly defines doc_name ('Name of the FreeCAD document'), analysis_name ('Name of the Fem::AnalysisPython object'), and timeout ('Seconds to wait for the solver (default 600)'). This adds crucial context beyond the bare schema titles.

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: 'Run the CalculiX solver on an existing Fem::FemAnalysis container and return summary results.' It specifies the verb (run), the resource (CalculiX solver on Fem::FemAnalysis), and the outcome (return summary results), distinguishing it from sibling tools that focus on object creation/editing.

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 lists explicit prerequisites in the document, telling the agent exactly what must exist before using the tool (geometry, analysis container, material, mesh, constraints). It also provides a clear when-not: 'do not fan out parallel requests' due to synchronous blocking. This is strong usage guidance.

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