Server Quality Checklist

Tool Scores

• export_objectsB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries the burden of disclosing side effects. It explains format derivation and the optional objects parameter, but does not mention that exporting writes to a file (potentially overwriting), requires specific permissions, or what the return/result indicates. It also omits the 'document' parameter, leaving behavioral context incomplete.

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

  Conciseness4/5

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

  The description is concise and well-structured with a clear purpose, supported formats list, and an Args section. It earns its place, though the missing 'document' parameter is a minor structural omission. It is not bloated or repetitive.

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

  Completeness2/5

  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 parameters, no annotations, output schema not shown), the description is incomplete. It fails to describe the 'document' parameter, does not state file overwrite behavior or permission needs, and lacks guidance on when to use this versus save_document. The supported formats list is helpful, but significant contextual gaps remain.

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

  Parameters2/5

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

  The description adds meaning for 'path' (destination file path) and 'objects' (names to export, omit for all shaped objects), supplementing the schema which has no descriptions. However, it completely omits the 'document' parameter, which appears in the schema. Since schema coverage is 0%, the description must compensate, and it only partially does so.

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

  Purpose5/5

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

  The description states a specific action: 'Export geometry to a file' with a specific scope (geometry, not document). It distinguishes from siblings by listing supported formats and explaining that the format is derived from the file extension, which clearly delineates it from save_document or capture_view.

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

  Usage Guidelines3/5

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

  The description implies usage: when you need to export geometry to a supported file format. However, it does not explicitly mention when to use alternatives like save_document for native format or capture_view for rendering. There is no explicit 'when not to use' or alternative tool reference.

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

• close_documentB
  3.3/5.0
  Behavior3/5

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

  The description warns 'Unsaved changes are lost,' which is a critical behavioral disclosure for a destructive operation. However, with no annotations, it does not explain what happens when document is null, whether permissions are required, or what the return value indicates. Some behavioral context is added but significant gaps remain.

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

  Conciseness5/5

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

  The description is a single well-structured sentence. It front-loads the core action ('Close a document'), then adds the optional save behavior and the key warning. No unnecessary words.

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

  Completeness2/5

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

  Despite being a low-complexity tool, the description leaves out essential usage details such as how to specify which document to close and the effect of the save boolean. The presence of an output schema reduces the need to describe return values, but the missing parameter semantics and lack of usage guidance make it incomplete for reliable agent invocation.

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

  Parameters2/5

  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 phrase 'optionally saving it first' loosely references the save parameter, but the document parameter is never mentioned or explained. The description adds minimal meaning beyond the raw schema.

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

  Purpose5/5

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

  The description clearly states the verb 'close' and the resource 'document', and explicitly notes the optional save behavior. This distinguishes it from siblings like open_document and save_document.

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

  Usage Guidelines2/5

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

  The description does not say when to use this tool vs alternatives. It does not mention save_document for saving without closing, nor does it clarify how this differs from open_document or list_documents. Usage context is only implied by the name.

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

• delete_objectA
  3.6/5.0
  Behavior3/5

  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 usefully warns that deleting a boolean without recursive leaves its operands behind, highlighting a non-obvious side effect. However, it does not mention whether deletion is permanent, whether related objects are affected beyond the stated case, or any authorization requirements. The partial disclosure earns a mid-range score.

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

  Conciseness5/5

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

  The description is extremely concise and front-loaded: the main purpose is stated in the first sentence, and the only additional detail (recursive behavior) is provided in a clearly labeled Args section. Every word earns its place, with no repetition or filler.

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

  Completeness3/5

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

  Given that this is a mutating tool with no annotations, the description should cover key contextual aspects like side effects, return value, and parameter details. It covers the recursive side effect and implies destructiveness, but it omits any mention of the return type (despite an output schema) and leaves the 'document' parameter unexplained. This is adequate for a simple delete operation but has clear gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, yet the description only explains the 'recursive' parameter in any depth. The 'name' parameter is self-evident from its name, but 'document' is left ambiguous—it is not described at all, and the schema only lists it as a nullable string. Since the description does not compensate for the complete lack of schema descriptions for two of three parameters, a score of 2 is appropriate.

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

  Purpose5/5

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

  The description begins with 'Delete an object,' which clearly identifies the action (delete) and the resource (object), immediately distinguishing it from sibling tools like create_object, edit_object, or move_object. The additional explanation about recursive deletion further clarifies the tool's primary purpose.

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

  Usage Guidelines3/5

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

  The description implies usage when an object needs to be removed, and it provides a specific use case for when the recursive parameter is necessary (e.g., booleans with operands). However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, so usage guidance is only implied rather than fully articulated.

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

• open_documentA
  3.7/5.0
  Behavior2/5

  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 effect 'make it active' but does not mention behavior when the file does not exist, whether it replaces the current document, or any permission requirements.

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

  Conciseness5/5

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

  A single, clear sentence with no redundant information. It is concise and front-loaded with the action and object.

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

  Completeness3/5

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

  For a simple open operation, the description covers the core function but lacks details about document management behavior (e.g., multiple documents open, state changes) and error handling. The output schema exists, so return format is not needed in the description.

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

  Parameters3/5

  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 adds the constraint that the path must point to an existing .FCStd file, which is helpful, but it does not clarify path format (absolute/relative) or other validation details.

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

  Purpose5/5

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

  The description clearly states the verb 'open', the resource '.FCStd file', and the effect 'make it active'. This distinguishes it from siblings like create_document, save_document, and close_document.

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

  Usage Guidelines4/5

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

  The phrase 'existing .FCStd file' implies it is for existing files, not new ones, providing clear context. However, it does not explicitly name alternatives or state when not to use this tool.

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

• save_documentA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the path being required first time but does not disclose key traits such as whether saving overwrites existing files, what 'instead' refers to, or error behavior. This is a significant gap for a mutation operation.

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

  Conciseness5/5

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

  The description is extremely concise, front-loaded with the purpose, and uses a clear args list. Every sentence contributes meaningful information without any redundancy or filler.

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

  Completeness3/5

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

  For a simple two-parameter save operation, the description covers the essential mechanics of specifying document and path. However, it omits behavioral context like overwrite policy or what the 'active' document refers to, leaving some ambiguity. The presence of an output schema mitigates the need to describe return values, but the description still feels incomplete.

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

  Parameters4/5

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

  The description adds substantial meaning beyond the raw schema: it explains that 'document' names the document and defaults to the active one, and that 'path' overrides the destination and is required on first save. The schema lacks per-parameter descriptions, so this compensates well.

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

  Purpose5/5

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

  The description uses the specific verb 'Save' with the resource 'a document', which clearly distinguishes this tool from siblings like create_document, open_document, and close_document. It unambiguously states the action performed.

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

  Usage Guidelines3/5

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

  The description provides usage context for the 'path' parameter, noting it is required on first save, and mentions that 'document' defaults to the active one. However, it does not explicitly state when to use this tool versus alternatives or any exclusions, leaving usage to be inferred from the tool's purpose.

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

• recomputeA
  3.8/5.0
  Behavior3/5

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

  No annotations exist, so the description carries full burden. It discloses that the tool reports error/invalid objects, but does not mention side effects, mutation, or the effect of `force`. The usage hint is more about timing than behavior, leaving transparency gaps.

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

  Conciseness5/5

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

  Two sentences, front-loaded with purpose, second sentence for usage. No fluff.

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

  Completeness3/5

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

  The description covers purpose and usage, and an output schema exists, but it fails to explain the `force` parameter or any prerequisites. Overall adequate but with clear gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain parameters. It implicitly covers `document` but says nothing about `force`. This is a significant gap.

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

  Purpose5/5

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

  The description clearly states the tool recomputes a document and reports error/invalid states, using a specific verb and resource. It is distinct from sibling tools like `run_python` or `edit_object`.

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

  Usage Guidelines4/5

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

  The description explicitly says to use after `run_python` or when geometry looks stale, providing clear context. It does not mention exclusions or alternatives but gives sufficient guidance.

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

• create_objectA
  3.9/5.0
  Behavior2/5

  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 does not mention side effects such as whether the document is modified in place, if recompute is required, whether operations are undoable, or what happens on failure. It only provides a prerequisite for boolean operations ('both must already exist'), which is minimal transparency.

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

  Conciseness4/5

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

  The description is long but well-structured with sections for TypeIds, value formats, and examples. Each section provides essential information without fluff. The use of code blocks and examples improves readability, though it could be slightly trimmed without losing value.

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

  Completeness3/5

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

  For a complex tool with 6 parameters and an output schema, the description covers input semantics thoroughly. However, it lacks behavioral context (side effects, recompute needs, error behavior) and does not explain the purpose of name/label/document parameters, leaving minor gaps. Given the output schema, return values need no explanation, so the description is mostly complete but not fully.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description fully compensates. It details accepted value formats for properties (numbers, vectors, placements, rotations, links, colors), explains view_properties targets, and provides a comprehensive list of TypeIds with their required properties. This adds substantial meaning beyond the schema's bare property names.

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

  Purpose5/5

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

  The description clearly states 'Create an object in a document' with a specific verb and resource. It distinguishes from sibling tools like edit_object, move_object, and delete_object by focusing on creation. The extensive TypeId list further clarifies the scope.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use the tool, including an explicit alternative: for Sketcher::SketchObject it advises 'build these with run_python'. It does not explicitly mention when not to use create_object versus edit/move/delete, but the examples and TypeIds imply the appropriate context.

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

• create_documentA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full responsibility. It does disclose that the document is made active and that FreeCAD may append digits to ensure a unique internal name, which is useful. However, it does not mention that the document exists only in memory until saved, nor does it describe what happens to the previously active document.

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

  Conciseness5/5

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

  The description is two sentences followed by a compact list of arguments. It front-loads the core purpose and each sentence/argument earns its place without redundancy or fluff.

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

  Completeness4/5

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

  For a simple two-parameter tool with an output schema, the description covers creation, activation, naming behavior, and label semantics. The only notable gap is not mentioning that the document must be explicitly saved to persist, which is relevant in the context of sibling save_document, but this is a minor omission.

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

  Parameters5/5

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

  The description adds significant meaning beyond the schema: it clarifies that 'name' is an internal identifier that FreeCAD may modify for uniqueness, and 'label' is an optional display name shown in the tree. With 0% schema description coverage, this fully compensates for the schema's lack of context.

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

  Purpose5/5

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

  The description uses a specific verb ('create') and resource ('document') and adds the key behavioral detail that the new document becomes active. This clearly distinguishes it from siblings like open_document and list_documents.

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

  Usage Guidelines3/5

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

  The description implies use when a new document is needed (as opposed to opening an existing one from siblings), but it does not explicitly state when to use this tool vs alternatives or provide any exclusion criteria. The guidance is only implicit.

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

• get_selectionA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full transparency burden. It conveys a non-destructive read operation via 'Read' and 'currently selected', implying a snapshot of GUI state, but it does not mention edge cases like empty selection or multiple selections. For a simple read tool, this is adequate but not richly detailed.

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

  Conciseness5/5

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

  The description consists of two concise sentences: the first states the core purpose, the second provides a usage example. It is front-loaded, contains no fluff, and every word contributes to understanding.

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

  Completeness4/5

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

  For a zero-parameter read tool with an output schema present, the description sufficiently covers purpose and usage. It does not detail edge-case behavior, but the output schema handles return structure, and the tool's simplicity makes this description near-complete.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description adds context by clarifying that the effective input is the current GUI selection, which is not captured in the empty input schema. No further parameter semantics are needed.

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

  Purpose5/5

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

  The description clearly states the tool reads the current selection in the FreeCAD GUI with a specific verb ('Read') and resource ('what the user currently has selected'). It distinguishes itself from all sibling tools, which focus on documents, objects, or execution, by addressing a unique selection-reading capability.

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

  Usage Guidelines4/5

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

  The description provides a clear usage scenario: when the user refers to 'this part' or 'the selected face'. It does not explicitly mention exclusions or alternatives, but since no sibling tool offers selection reading, the context sufficiently guides when to invoke this tool.

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

• freecad_statusA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses what the tool reports (version, active document, object counts) and implies a read-only status check via the name and 'before anything else' phrasing. However, it does not explicitly state that it has no side effects or requires no permissions, leaving some ambiguity.

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

  Conciseness5/5

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

  The description is three concise sentences with no fluff. It front-loads the main action ('Check the bridge connection...') and each subsequent sentence adds critical usage and output details. Every word earns its place.

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

  Completeness5/5

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

  Given zero parameters and an output schema that likely details the return structure, the description is complete. It explains what the output means (version, active doc, object counts) and when to call it. No additional context is needed for a status tool.

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

  Parameters4/5

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

  The tool has zero parameters and the schema is fully covered. The baseline for 0 params is 4. The description adds no parameter-specific information, but none is needed. It focuses on the tool's purpose and output, which is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Check the bridge connection and list open documents.' It also specifies the exact information reported (FreeCAD version, active document, object counts), making it distinct from sibling tools like list_documents, which likely only list documents.

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

  Usage Guidelines4/5

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

  The description gives explicit when-to-use guidance: 'Call this before anything else.' This is clear context but does not provide when-not-to-use instructions or mention alternatives, which prevents a 5. It strongly implies this is the first step for any session.

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

• edit_objectA
  4.4/5.0
  Behavior4/5

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

  With no annotations to rely on, the description carries the full burden. It discloses that only passed properties are touched (partial update), documents acceptable value formats for complex parameters, and clarifies that view_properties targets ViewObject attributes. It does not mention permissions, reversibility, or potential associated actions like recompute, but covers the main behavioral traits.

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

  Conciseness5/5

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

  The description is front-loaded with the purpose and key behavioral notes, then provides a structured list of value formats. Every sentence contributes useful information without redundancy. Despite being detailed, it remains well-organized and scannable.

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

  Completeness4/5

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

  The tool has 5 parameters and an output schema, so return values are not a concern. The description thoroughly explains the complex parameters, gives a usage precondition, and clarifies the scope of the operation. It omits some peripheral details (e.g., behavior when the object is not found, or whether a recompute is needed), but overall it is sufficiently complete 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.

  Parameters4/5

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

  The schema has 0% description coverage, so the description must compensate. It provides detailed format specifications for 'properties' (numbers, vectors, placement, rotation, links, colours) and 'view_properties' (ShapeColor, Transparency, DisplayMode, Visibility). However, it does not explain the semantics of 'name', 'label', or 'document', which are left to inference.

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

  Purpose5/5

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

  The description opens with 'Change properties of an existing object,' which is a specific verb+resource statement. It clearly distinguishes from siblings like create_object, move_object, and delete_object by focusing on altering properties of an existing object.

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

  Usage Guidelines4/5

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

  It provides a clear context for when to use the tool (changing properties) and gives a useful precondition: 'Call get_object first if you are unsure which properties exist.' However, it does not explicitly contrast with alternative tools (e.g., move_object for position changes), though the purpose statement implicitly differentiates.

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

• get_objectA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of explaining behavior. It adds context beyond the schema: 'set False for a lighter response on complex objects' hints at potential performance concerns, and 'shape volume/area/bounding box' clarifies what geometry measurements are included. It does not cover error behavior or permissions, but for a simple inspection tool, this is adequate.

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

  Conciseness5/5

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

  The description is concise and well-structured: a one-sentence summary followed by a compact Args block. Every sentence adds value, and the front-loaded summary ensures the agent immediately understands the tool's core purpose.

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

  Completeness4/5

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

  Given the output schema exists and the tool is straightforward, the description covers the main elements and optional flags. The missing document parameter explanation is a slight gap, but overall the description is complete enough for an agent to select and invoke the tool correctly.

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

  Parameters4/5

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

  The description explains three of the four parameters with semantics beyond the schema: 'name: object Name or Label' clarifies the input, while include_properties and include_shape include rationales for setting them to False. The document parameter is not mentioned, but it is optional with a default null, making the omission a minor gap.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Inspect one object: all properties, plus shape volume/area/bounding box.' This clearly distinguishes the tool from siblings like list_objects, which lists objects, and get_selection, which returns the current selection.

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

  Usage Guidelines4/5

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

  The description implies when to use the tool by focusing on a single object's detailed inspection and explains how to adjust flags ('set False for a lighter response'). However, it does not explicitly mention alternatives or state when to prefer one of the sibling tools, such as list_objects for overviews or get_selection for the current selection.

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

• list_objectsA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It discloses important behavioral details: document defaults to the active document, and type_filter performs a case-insensitive substring match with examples. This goes beyond a vague 'list' but doesn't describe return format or side effects, which is acceptable for a read-only operation.

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

  Conciseness5/5

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

  The description is concise and front-loaded: a one-sentence purpose followed by clear parameter definitions. Every sentence earns its place, with no fluff or repetition.

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

  Completeness5/5

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

  With an output schema present, return values need not be described. The tool is simple, and the description covers purpose, parameters, and key behavioral traits. It is complete for making an informed invocation decision.

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

  Parameters5/5

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

  The input schema provides only titles with no descriptions, so coverage is 0%. The description fully compensates by explaining the document default and the exact matching semantics of type_filter with illustrative examples. This adds significant meaning beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool lists objects in a document and specifies the fields (name, label, TypeId, state). It distinguishes from siblings like list_documents (lists documents) and get_object (gets a single object) through the explicit object-listing scope.

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

  Usage Guidelines3/5

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

  The description implies use cases via parameters (type_filter for filtering by type), but does not explicitly state when to use this tool vs alternatives like get_object or list_documents. No exclusions or alternative names are provided, leaving the context clear but not fully explicit.

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

• move_objectA
  4.4/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the transparency burden. It usefully discloses that other properties are untouched and that omitting position/rotation preserves current values. It also explains accepted rotation formats. It does not mention side effects like recompute or error behavior if the object is not found, but the provided details go beyond the bare minimum.

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

  Conciseness5/5

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

  The description is compact and well-structured: a one-sentence purpose followed by a clear Args block. Every line adds value, with no redundancy. The most important information is front-loaded.

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

  Completeness4/5

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

  The description covers the core parameters and behavior effectively, and the output schema exists so return values are not needed. However, the 'document' parameter is unexplained, and there is no guidance on when to prefer this over edit_object. These minor gaps prevent a perfect score.

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

  Parameters4/5

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

  The description adds significant meaning beyond the schema: it explains 'name' as object Name or Label, gives position units (mm) and array shape, and details three rotation formats (degrees about Z, axis-angle, Euler). This compensates for the schema's lack of parameter descriptions. However, the 'document' parameter is not mentioned at all, leaving a gap.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Reposition an object without touching its other properties.' It clearly distinguishes from sibling tools like edit_object (general editing) and delete_object. The scope of action (position/rotation only, preserving other properties) is precise.

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

  Usage Guidelines4/5

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

  The description clearly implies the intended use: reposition an object while preserving all other properties. It does not explicitly mention alternatives (e.g., edit_object) or state when not to use it, so it lacks explicit exclusions. However, the context is clear enough for an agent to infer when to select this tool.

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

• run_pythonA
  4.4/5.0
  Behavior5/5

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

  With no annotations, the description fully carries the transparency burden. It discloses preloaded names, global state persistence, REPL-like expression evaluation, the need to assign to `result` in statement mode, document recomputation, and return value structure including traceback 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.

  Conciseness5/5

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

  The description is well-structured and front-loaded with the core purpose. Every sentence adds value, the example is directly useful, and there is no redundant filler. It earns its length.

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

  Completeness4/5

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

  For such a powerful and open-ended tool, the description covers execution semantics, state persistence, return values, and recomputation. The main gaps are the undocumented `document` parameter and lack of safety caveats for arbitrary code execution, but overall it is highly complete.

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

  Parameters3/5

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

  The description thoroughly explains the primary `code` parameter through REPL semantics, the `result` variable, and a detailed example. However, the optional `document` parameter is never mentioned, and with 0% schema coverage this leaves a notable gap in understanding its purpose.

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

  Purpose5/5

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

  The description opens with 'Execute Python inside FreeCAD,' giving a specific verb, resource, and action. It further distinguishes itself as 'the escape hatch for anything the typed tools cannot do,' clearly separating it from sibling typed tools.

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

  Usage Guidelines4/5

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

  It states that this tool is the escape hatch for anything the typed tools cannot do, implying it should be used when typed tools are insufficient. While it doesn't explicitly say 'use typed tools first,' the context is clear enough for an agent to decide.

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

• capture_viewA
  4.5/5.0
  Behavior4/5

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

  Discloses behavior such as returning an image, zoom-to-fit option, and default document handling. With no annotations, the description effectively communicates the read-only nature of a screenshot, though it doesn't explicitly state safety.

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

  Conciseness5/5

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

  The description is brief and front-loaded with the core purpose; the argument list is structured and adds necessary detail without bloat. Every sentence earns its place.

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

  Completeness4/5

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

  The description covers the tool's purpose, parameters, a usage recommendation, and the output type. It doesn't specify the exact image format or return mechanism, but for a screenshot tool this is sufficient.

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

  Parameters5/5

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

  Since the schema has no descriptions, the description fully compensates by enumerating all five parameters, providing allowed values for 'view', explanation for 'fit', defaults for width/height/document, and the purpose of each.

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

  Purpose5/5

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

  The description uses the specific verb 'Screenshot' and clearly identifies the resource as the 3D view, with the return value stated as an image. This distinguishes it from sibling tools and states exactly what the tool does.

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

  Usage Guidelines4/5

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

  Provides explicit guidance to use the tool after building geometry to verify correctness ('Always look at the model...'), which tells the agent when to invoke it. It doesn't mention alternatives or when not to use it, but 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.

• list_documentsA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. 'List' clearly implies a read-only operation, and the description reveals the exact output scope (every open document, with file path and modified state). It does not explicitly state authorization or error behavior, but for a simple list operation these are not critical.

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

  Conciseness5/5

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

  The description is a single, concise sentence with no wasted words. It is front-loaded with the verb 'List' and immediately conveys the object and relevant details.

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

  Completeness5/5

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

  For a zero-parameter list tool, the description is fully complete. It covers what is listed, the scope (every open document), and the returned attributes (file path, modified state). The presence of an output schema further reduces the need to explain return structure.

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

  Parameters4/5

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

  The tool has 0 parameters, and schema coverage is 100% (empty set), so the baseline for parameter semantics is 4. The description correctly focuses on output rather than parameters, needing no additional compensation.

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

  Purpose5/5

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

  The description clearly states the verb 'List' and the resource 'every open FreeCAD document', and specifies the output includes file path and modified state. This distinguishes it from sibling tools like list_objects and open_document.

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

  Usage Guidelines4/5

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

  The purpose is immediately clear: use this to see all open documents. No explicit alternatives or exclusions are mentioned, but the context is straightforward and doesn't require formal guidance. This earns a 4 rather than 5 due to lack of explicit when-not-to-use guidance.

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

• reset_pythonA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosing behavior. It explicitly states that the tool clears variables from previous run_python calls, which is a clear scope. It doesn't mention side effects (e.g., whether the Python environment resets), but the operation is simple and self-explanatory.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that directly states the action and scope. Every word earns its place with no redundancy.

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

  Completeness5/5

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

  Given the tool's simplicity, zero parameters, and presence of an output schema, the description adequately covers what an agent needs to know. The one-sentence explanation is complete for a reset operation.

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

  Parameters4/5

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

  The tool has zero parameters, so per the rubric the baseline is 4. The description adds no parameter details, but none are needed.

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

  Purpose5/5

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

  The description uses a specific verb ('Clear') and resource ('variables accumulated by previous run_python calls'), making the tool's purpose unambiguous. It also naturally differentiates this tool from its sibling run_python, as it is the cleanup counterpart.

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

  Usage Guidelines4/5

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

  The description clearly implies the usage context: call this after run_python calls to clear accumulated variables. However, it does not explicitly state when-not to use it or mention alternative tools, 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.