CADPilot

by LBurny

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.1
Disambiguation4/5
Most tools have clear, distinct purposes, but there is some overlap: `assemble`, `assembly_session`, and `align_shapes` all deal with positioning/joining parts, and `get_topology`, `get_positioning_info`, and `get_anchors` all provide spatial data. The descriptions are detailed enough to differentiate them in most cases, so it's mostly unambiguous.
Naming Consistency4/5
The naming is largely consistent, with a strong pattern of verb_noun (e.g., `create_document`, `get_object`, `measure_geometry`) and a uniform `session_` prefix for session tools. A few oddities like `cad`, `assembly_session`, and `operation_help` break the pattern, but they are still readable and not chaotic.
Tool Count2/5
With 33 tools, the count is clearly above the 25+ threshold for being too many. The session management alone accounts for 10 tools, which could likely be consolidated, and the `cad` catch-all tool adds a layer of complexity. The sheer number will be heavy for an agent to navigate.
Completeness4/5
The tool set covers the core CAD lifecycle well: document creation, modeling via `cad`, geometry measurement, topology inspection, and assembly with persistent joints. However, there is no explicit save/close/delete document tool (only via `session_complete`), and no import/export functionality, which are notable gaps but not fatal for typical modeling workflows.
Average 4.3/5 across 33 of 33 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return behavior (object properties, screenshot only when requested) and the default for with_screenshot. However, it does not mention error handling, side effects (though likely none), or any prerequisites, which is a gap for a tool without annotations.
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 appropriately sized and well-structured with separate Args and Returns sections. Every sentence provides useful information, and the layout is easy to scan.
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 getter with an output schema, the description covers the core functionality (parameters, return value, screenshot behavior). However, it does not address potential error conditions or clarify when to use this tool versus get_objects, which are relevant contextual gaps given the sibling tools present.
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?
Schema description coverage is 0%, so the description must compensate. It explains each parameter clearly (doc_name, obj_name, with_screenshot) and provides the default for with_screenshot. This adds meaning beyond the bare schema and effectively documents all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 with a specific verb ('Get') and resource ('an object from a document'). It does not explicitly differentiate from sibling tools like get_objects (plural), but the singular naming and description imply a single-object retrieval.
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?
No explicit guidance is given on when to use this tool versus alternatives such as get_objects or get_view. The description only states what the tool does, leaving the agent to infer appropriate usage from the parameter names and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool returns a success/failure message and that with_screenshot attaches a screenshot, but it does not mention any requirements like a running session, potential side effects on the FreeCAD environment, or whether the operation is synchronous. This is a significant gap for a tool that creates an object.
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, structured into Args, Returns, and an example. The example is helpful without being verbose. It could omit the Returns line since an output schema exists, but it remains efficient.
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 tool is simple and the output schema covers return structure. However, the description does not integrate with the session context visible in sibling tools (e.g., session_start, list_documents). An agent may not know whether a session must be active before creating a document.
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?
Schema coverage is 0%, but the description compensates by explicitly stating that name is 'the name of the document' and with_screenshot 'attaches a screenshot' with a default of no screenshot. This adds meaning beyond the schema's type-only definitions.
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 'Create a new document in FreeCAD', which is a specific verb+resource+domain statement. It clearly distinguishes this tool from siblings like list_documents or get_objects by focusing on creation of a document.
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 example shows how to use the tool, but there is no explicit guidance on when to use it versus alternatives, nor are any exclusions or prerequisites mentioned. The intended use is implied by the name and description but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It explains the return format (JSON with distance_mm, intersects, common_volume_mm3) which is helpful, but it does not mention side effects, prerequisites, or behavior when objects are missing or invalid. The lack of side-effect disclosure is acceptable for a read-like check, but not fully explicit.
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 opening sentence, a usage sentence, and then structured Arg/Returns sections. The Args section is somewhat redundant with the schema but adds small value. No excessive verbosity, and the key purpose and context are 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 purpose, usage context, arguments, and return values. Given the tool's moderate complexity and the presence of an output schema (return format), it is fairly complete. It could benefit from clarifying edge cases or how object names are resolved, but the essentials are present.
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 'Args:' section provides only trivial one-liners ('Document name.', 'First object name.', 'Second object name.') that barely exceed the schema property names. It does not clarify what types of objects are expected (e.g., part names, bodies) or the expected format, leaving significant ambiguity.
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 checks the spatial relationship between two objects, specifically distance and intersection (common volume). It includes a specific verb ('check') and resource ('spatial relationship'), and distinguishes itself from siblings like measure_geometry by focusing on interference detection.
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 'Use to verify clearance or detect collisions in multi-body configurations,' which provides clear context for when to use the tool. It does not mention exclusions or alternatives by name, but the guidance is specific enough to differentiate from similar measurement tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states the return value (a list of document names) but does not explicitly note that the operation is read-only, has no side effects, or what happens when no documents are open. Some transparency is provided, but it 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two short sentences that front-load the purpose and clearly state the return format. Every word earns its place, with no redundancy or filler.
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-only listing tool, the description is nearly complete. It specifies what is returned and the domain (FreeCAD). Minor omissions like behavior with no open documents or ordering are not critical for such a simple tool, so it slightly misses a 5.
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 input schema is empty (0 parameters), so the baseline for this dimension is 4. The description adds no parameter-specific details, which is fine because there are no parameters to document.
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 action (Get) and resource (list of open documents in FreeCAD), which distinguishes it from sibling tools like create_document and get_objects. It is specific and unambiguous.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or scenarios where another tool would be preferable, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses sorting order, pagination with limit/offset, and return structure (total, returned, list with attributes). However, it omits mention of required parameters doc_name and obj_name, and does not specify vertex-specific return fields, leaving gaps in behavioral transparency. Since no annotations are provided, the description carries the full burden but only partially covers it.
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 with clear sections (purpose, sorting, usage hint, args, returns). Every sentence adds value, no fluff or redundancy. Front-loads the core purpose effectively.
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 the main functionality, sorting, and return format, but it omits required parameters and vertex-specific output details. Given the tool's complexity and the presence of an output schema, the description is adequate but not complete, leaving agents to infer missing critical inputs.
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 Args section explains element, limit, and offset with acceptable detail (enum values, range, default). However, the required parameters doc_name and obj_name are entirely absent from the description. With 0% schema description coverage, the description must compensate, but it fails to document two of the five parameters, leaving 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 lists an object's faces, edges, or vertices with semantic info for selection. It uses a specific verb (List) and resource (topology) and provides context for use in follow-up operations like fillet, boolean, or sketching, distinguishing it from general object listing 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?
The description explicitly says to use the returned index/name in follow-up operations, providing clear usage context. It doesn't name alternatives or exclusions, but the purpose is specific enough to imply when to use this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses important behavior such as the capture being tied to the 'active view' and defaults for width/height to the viewport size and focus_object to fit all objects. However, it does not mention any side effects, permissions, or limitations; the read-only nature is obvious from 'screenshot'.
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 Args and Returns sections. However, the Returns line ('A screenshot of the active view') largely repeats the opening sentence, introducing minor redundancy. Still, every sentence otherwise 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?
For a simple screenshot tool with 4 parameters and an output schema, the description covers purpose, each parameter's meaning and defaults, and the return value. It does not address potential errors or usage alternatives, but the essential context is adequately provided. The lack of annotations is partially offset by the clarity of the screenshot's read-only nature.
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%, and the description fully compensates for all four parameters. It explains view_name as a camera view, width/height as pixels with viewport-size defaults, and focus_object as the target object with a default of fitting all objects. This adds semantic 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 tool's function with a specific verb and resource: 'Get a screenshot of the active view.' This distinguishes it from sibling tools like get_objects or get_object, which likely return data rather than a visual capture.
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 a screenshot is needed, but it does not explicitly state when to choose this tool over alternatives or any exclusions. There is no mention of prerequisites or when not to use it, so 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses persistent joints, the need to call solve after moving parents, and atomic rollback semantics. However, it does not mention potential side effects beyond document state, such as file saving or permission requirements, leaving some behavioral aspects implicit.
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 efficiently structured: a clear one-line definition, a bullet-like workflow, a mate-ref rule, and a pointer for full details. Every sentence adds distinct value 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?
The tool is a complex state machine with 11 parameters and no annotations, but an output schema exists, so return values are covered elsewhere. The description provides the high-level workflow and persistent-joint behavior, yet leaves many operation-specific parameters and edge cases undocumented. It is adequate for orientation but not fully self-contained.
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 coverage is 0% and there are 11 parameters, so the description must compensate. It does explain the mate reference structure ({part plus face/anchor/point}) and names parameters like ground, part, joint_type, trim, and to_step in the workflow, but many parameters (doc_name, name, gap_samples, operation, a, b) remain unexplained. Delegating to operation_help is helpful but not sufficient for standalone parameter understanding.
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 identifies the tool as an 'Independent assembly state machine with PERSISTENT joints (FreeCAD Assembly workbench)' and explicitly contrasts it with the one-shot `assemble` sibling, making its unique role obvious. It also lists the core workflow operations, giving a specific verb+resource model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit step-by-step workflow: start(ground=part) -> add_component(part) -> mate(..., trim?) -> solve -> verify -> complete. It also names the alternative `assemble` for one-shot use, and points to operation_help for full details, effectively telling when and how 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that notes are attached to the session log and not counted as operation steps, and that the recorded note entry is returned. However, with no annotations provided, it does not elaborate on persistence, reversibility, or any side effects beyond the immediate action.
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 with Args and Returns sections. It contains no redundant information and each line serves a 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?
For a simple logging tool, the description covers purpose, parameters, and return value. It does not explain how notes interact with session steps or whether they are editable, but given the tool's simplicity, the information is largely sufficient.
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 provides the allowed values for note_type ('observation', 'assumption', 'limitation', 'correction') which are absent from the input schema. It also clarifies the note parameter as the content, adding meaning beyond the bare schema titles.
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 attaches a human/LLM insight to the session log, explicitly distinguishing it from an operation step. This specifies the verb (attach) and resource (session log) with enough clarity to differentiate from sibling session 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 explains the note types (observation, assumption, limitation, correction) which indicate appropriate use cases, and explicitly states 'not an operation step' to exclude that context. However, it does not name alternative tools or provide explicit when/when-not beyond this single exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the ordering behavior and the exact return fields, which goes beyond just the tool name. It does not mention side effects, but 'List' implies a read-only operation, and the return format is specified.
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 highly concise: two sentences that state the purpose, ordering, and return format. No unnecessary words or redundant information exist.
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, parameterless list tool, the description provides sufficient detail: it names the resource, the return fields, and the ordering. The existence of an output schema (not shown) reduces the need to explain return values further. However, it lacks context on when to use it relative to sibling tools, which is a minor gap.
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 there are no parameter semantics to clarify. Per the rubric, a baseline of 4 is appropriate because the description correctly notes the return structure, which is the only relevant semantic here.
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 action ('List') and the resource ('all persisted sessions'), including ordering ('most recently updated first'). This distinguishes it from sibling tools like session_status or session_get_steps, which operate on individual sessions.
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: if you need a list of all persisted sessions, use this tool. However, it does not explicitly mention when not to use it or suggest alternatives for session-specific operations, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses key behavior (persisted to disk, resumable) and return type, but does not explain what happens to the in-memory state, prerequisites (e.g., an active session must exist), or error handling. This leaves notable 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?
The description is two sentences: the first states the action and key behavioral consequence, the second states the return value. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool with an output schema, the description covers purpose, persistence, and return. It does not address edge cases like missing active session or error conditions, but these are minor given the tool's simplicity.
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 description does not need to add parameter information. The baseline score of 4 applies because the schema already reflects an empty parameter set, which is sufficient.
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 clear verb 'Pause' with a specific resource 'active session', and adds context by noting persistence and the ability to resume later. This distinguishes it from sibling tools like session_resume and session_complete.
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 a use case for temporarily halting a session to resume later. However, it does not explicitly mention alternatives or when not to use this tool. Sibling names provide additional context, but the description itself lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining side effects. It discloses that sessions record cad() mutations as transactional steps, that execute_code steps are non-atomic, and that rollback behavior is affected. This goes beyond a simple 'start session' statement and gives important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, a paragraph explaining side effects, and a concise Args/Returns section. It is front-loaded and every sentence adds value with no 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?
The description covers the main purpose, side effects, and return value (session info). However, the required doc_name parameter is not explained, which is a notable gap. For a tool with moderate complexity, the description is otherwise thorough enough for an agent to invoke it correctly if it can infer doc_name from context (e.g., 'bound to a document').
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 explains 'name' and 'create_document' clearly, but it completely omits 'doc_name', which is the only required parameter. The schema only labels it as 'Doc Name', which is minimal. This is a gap that could confuse an agent since the description does not explicitly bind the session to that document.
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: 'Start a modeling session bound to a document.' This provides a specific verb (start), resource (modeling session), and binding context. It distinguishes itself from sibling session tools like session_pause, session_rollback, and session_complete, which handle different lifecycle operations.
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 explains when to use the tool by mentioning 'enabling session_rollback for trial-and-error modeling.' This implies usage for iterative modeling workflows. It does not explicitly mention alternatives or when not to use it, but the context is clear enough in relation to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 key behavioral traits: session step recording and rollback, unified transaction per mutation, connectivity audit, obj_name semantics for new versus base objects, return values (step number, optional screenshot), and batch behavior with stop_on_error. It does not mention what happens when no session is active or permission requirements, but the disclosed traits are substantial.
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 moderately sized but well-structured: a one-sentence purpose, followed by context, then a clear Args list, and a Returns paragraph. Every sentence adds information (session behavior, transaction/audit, obj_name rule, operation_help pointer). It is not as succinct as a two-sentence description, but complexity justifies the 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?
Given the tool's complexity (9 parameters, 22 operations, no annotations), the description covers the essential contextual pieces: session integration, transaction/audit behavior, the distinction between new-object and base-object naming, and the return format. It wisely points to operation_help for per-operation parameters. It does not explicitly state prerequisites like calling session_start, but implies it by saying 'When a modeling session is active'.
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?
Schema description coverage is 0%, so the description compensates by explaining critical semantics: obj_name is a base object except for sketch/variables/datum_plane/hull where it names a new object; obj_properties holds operation parameters; stop_on_error is for batch; description is a step log note; with_screenshot attaches a screenshot. It also directs to operation_help for full parameter details. Some parameters (obj_type, ops) are not explained in the description, but the most nuanced ones are.
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 'Perform a CAD modeling operation (unified mutation tool)', which clearly states the verb, resource, and scope. Calling it a 'unified mutation tool' distinguishes it from read-only siblings like get_objects and get_view. Although it doesn't enumerate all operations, the enumeration is present in the input schema's operation enum.
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: it is for mutations on a CAD document, with session behavior explained (recording steps, rollback via session_rollback). It also explicitly directs users to operation_help for per-operation parameter references, which is an important alternative source. However, it does not explicitly state when to use this tool versus other mutation-like siblings (e.g., assemble, execute_code) or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return value (a list of objects, and optional screenshot only when requested) and explains the with_screenshot parameter behavior. However, it does not explicitly state whether the operation is read-only or mention any potential side effects, though the verb 'get' implies 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 concise and well-structured. It opens with a one-line summary, then clearly lists Args and Returns. Every sentence provides useful information with no 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?
The description is complete for a simple getter tool: it covers the purpose, parameters, and return value. However, it does not explicitly differentiate from the sibling 'get_object' and does not mention potential limitations or edge cases, which would make it fully complete. The presence of an output schema reduces the need to detail return values further.
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 has 0% description coverage, so the description must compensate. It explains both parameters clearly: doc_name as 'the name of the document' and with_screenshot as 'attach a screenshot' with a default of 'no screenshot'. This fully clarifies the parameters beyond the bare 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 states 'Get all objects in a document' with a specific verb and resource, and the word 'all' clearly distinguishes it from the sibling tool 'get_object'. This is a clear and specific 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 you want all objects in a document) but does not explicitly mention alternatives or exclusions. It does not reference the similar sibling tool 'get_object', which could cause confusion. Usage is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 source of patterns and the return format, but does not explicitly state that the operation is read-only or describe side effects. While 'search' implies read-only, the lack of explicit disclosure of behavioral traits leaves a moderate gap.
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 with clear sections for usage, args, and returns. Every sentence provides valuable information without redundancy, making it highly efficient.
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 search tool, the description covers purpose, usage, parameters, and return format. Minor omissions like behavior when no patterns are found or result size are not critical, but the lack of explicit read-only disclosure keeps it from a perfect 5.
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 schema has 0% coverage, but the description's Args section fully explains both parameters: query with an example, and limit with a default and meaning. This fully compensates for the schema's lack of descriptions, adding clear semantic value.
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 searches pattern memory for workflows/code similar to the task. This distinguishes it from sibling tools like save_pattern (which saves) and CAD tools, making the purpose unambiguous.
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 guidance: 'Use when your own knowledge is insufficient, before falling back to trial-and-error.' It also notes patterns come from save_pattern and completed sessions, providing useful context, but does not name specific 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates a read operation via 'Return' and describes the output structure, but does not explicitly state that it has no side effects, whether authentication is required, or what happens if no session is active. This is adequate for a simple getter but lacks richer context.
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: one sentence states the purpose, and a second lists the return fields. It is front-loaded with the main action and avoids unnecessary wording. 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 the tool's simplicity (no parameters, output schema present), the description covers everything needed: it names the resource ('all recorded steps and notes'), scopes it to the active session, and summarizes the return format. The presence of an output schema means detailed return structures are already handled, so the description is fully 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, and the schema correctly reflects this (no properties, 100% coverage). The description does not need to explain parameters, and per the rubric, a zero-parameter tool gets a baseline of 4. No additional parameter semantics are necessary.
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 'Return' with the resource 'all recorded steps and notes of the active session,' making its purpose immediately clear. It distinguishes itself from siblings like session_status (which likely returns status) and session_add_note (which adds notes) by explicitly targeting the full step/note history.
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 when to use this tool: whenever an agent needs the complete record of steps and notes from the current session. It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent would not confuse it with the status or note-adding siblings. A small deduction for lack of explicit 'use for / use instead' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a JSON summary with a human-readable display_text and surfaces specific risk factors (state drift from GUI edits, non-atomic steps), which is meaningful behavioral context beyond a simple status read. It does not explicitly state that it is read-only, but 'Show' implies no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, only two sentences. The first sentence front-loads the tool's primary content, and the second clarifies the return format. Every word earns its place; there is no redundant or irrelevant information.
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 simple zero-parameter tool with an output schema, the description is complete. It explains what the tool does, what it returns, and even highlights risks that are not visible from the schema or annotations. No significant gaps exist for the intended use case.
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 empty with 100% coverage, so there is nothing to document. The description adds no parameter-level detail because none is needed. The baseline of 4 for zero-parameter tools applies.
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 with a specific verb ('Show') and resource ('active session'), and enumerates the contents: step count, document state, next-step suggestions, and risks. This distinguishes it from sibling tools like session_get_steps, which focus on individual steps, by framing it as a comprehensive status summary.
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: call it when you need a snapshot of the active session's progress and risks. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as session_get_steps for more granular step details. This is a clear but unstated usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the alignment modes, the meaning of offset ('extra distance along target normal'), and notes that offset applies only to 'touch' mode. It also states the return format (JSON with success and Placement). It does not explicitly mention that the operation modifies the document, but this is implicit from 'move'.
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: a one-sentence purpose, a compact mode/offset explanation, an args list, and a return note. It is front-loaded with the main action and uses bullet-like formatting for readability. Every sentence contributes useful information without unnecessary verbosity.
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 tool with 9 parameters, 3 enums, and an output schema, the description covers the core semantics (modes, offset, return format). It does not explain element validity per mode (e.g., axis mode requiring cylindrical faces) or index interpretation, but given the output schema, it is sufficiently complete for most use cases.
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?
Schema description coverage is 0%, so the description must compensate. It explains element/target_element, element_index/target_element_index, mode, and offset semantics. The remaining parameters (doc_name, obj_name, target_obj) are not explicitly described, but their names are self-explanatory. The description adds value by clarifying the mode and offset behavior beyond the schema's enums and defaults.
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 function: 'Move an object so one of its elements aligns with a target element.' It specifies the action (move), the resource (object), and the goal (alignment). The detailed mode list (touch, center, axis) distinguishes it from sibling tools like assemble or measure_geometry.
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 for when to use the tool (aligning shapes) and explains the available modes. It does not explicitly contrast with sibling tools like assemble or set_anchors, but the purpose is specific enough to imply appropriate usage. There is no misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does an excellent job. It discloses that this is a single transaction, that per-mate residuals are measured AFTER the move, that a mate over tolerance fails, and that stop_on_error aborts and rolls back. It also states the return format, giving the agent a clear picture of side effects and behaviors.
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 with clear sections for behavior, arguments, and returns. It is front-loaded with the core purpose, and every sentence adds value. The pointer to operation_help keeps it concise without sacrificing completeness.
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 complexity of the assembly operation and the bare schema, the description is quite complete: it explains the mate format, failure behavior, rollback, and return values. However, it misses the required doc_name parameter and does not elaborate on the differences between center/touch/axis modes, though it defers to operation_help for full semantics.
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 adds significant meaning beyond the schema by detailing the structure of each mate dict, including the mode enum and default offset. However, it entirely omits the required doc_name parameter from the Args list, and since schema coverage is 0%, this is a notable gap that prevents a higher score.
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 assembles parts by snapping named anchors together, with a specific verb and resource. It also distinguishes itself from the sibling tool assembly_session by noting that assembly_session is for PERSISTENT joints, and it emphasizes the ONE transaction behavior.
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 'For PERSISTENT joints use assembly_session', providing a clear alternative. It also points to operation_help for full semantics, but it does not fully elaborate on when to use assemble vs other assembly-related sibling tools like align_shapes or verify_assembly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and covers key behaviors: execution on the GUI thread, pre-imported modules, captured print output, conditional screenshot, and the return structure. It does not mention risks like GUI freezing but still provides substantial 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 well-structured with Args and Returns sections, and every sentence adds value. It is slightly longer than necessary, but the organization and front-loading make it easy to scan.
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 tool's complexity, the description covers the execution environment, output handling, screenshot option, and return format. The presence of an output schema makes return details redundant but harmless. Overall, it is complete enough for an agent to use correctly.
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 must compensate. It explains 'code' as the Python code to execute and 'with_screenshot' as attaching a screenshot after successful execution with a default of no screenshot, matching the schema's type and default.
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 'Execute arbitrary Python code in FreeCAD' with a specific verb and resource. It also specifies the execution context (GUI thread) and distinguishes from the asynchronous sibling by implying synchronous execution with captured output.
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 for when to use the tool: to run Python code in FreeCAD with the full API and capture print output. It does not explicitly mention alternatives or exclusions, but the context is sufficient for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It lists the return fields and notes that obj_name 'must have a Shape', which is a useful prerequisite. It also frames the tool as a verification step (implying read-only). However, it doesn't explicitly state non-destructiveness or error behavior, which would improve certainty.
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 efficiently structured with a purpose sentence, usage note, and clearly labeled Args/Returns sections. No redundant or vague wording.
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 measurement tool with a detailed output specification, the description covers the core aspects: what it measures, when to use it, input requirements, and return format. It lacks explicit error handling or a read-only guarantee, but overall it is contextually complete given the tool's simplicity.
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 provides only parameter names with no descriptions. The description adds 'Document name' for doc_name and 'must have a Shape' for obj_name, giving meaningful context, especially the shape requirement. This compensates for the 0% schema coverage.
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 'Measure an object's Shape' followed by a specific list of measured quantities (volume, area, bounding box, center of mass, element counts, validity). This clearly distinguishes it from sibling tools like get_topology (topology structure) or get_positioning_info (position).
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?
'Use after modeling steps to verify design targets quantitatively' provides clear context for when to call. It doesn't explicitly mention alternatives or exclusions, but the purpose is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses return behavior ('Returns: Session state') and a warning condition ('warns if the bound document is no longer open'). It also implies disk I/O via 'from disk.' This goes beyond a bare description, though it doesn't discuss side effects or prerequisites in detail.
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, front-loaded with the primary verb phrase, then an Args section, and a Returns section. Every sentence serves a purpose; no wasted words.
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 tool's simplicity (one parameter, output schema present), the description adequately covers action, parameter semantics, and a key behavioral caveat. It could clarify whether resuming activates the session or impacts the current environment, but the current level is sufficient.
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?
Schema description coverage is 0%, so the description compensates by explaining that session_id is 'The session to resume (see session_list),' providing a cross-reference to another tool for valid values. This adds meaning beyond the raw schema field type, though it could include more detail on format or constraints.
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?
Description begins with 'Resume a paused/completed session from disk.' This clearly specifies the action (resume) and the resource (a paused/completed session), with 'from disk' adding scope. It differentiates from siblings like session_pause, session_start, and session_complete, which serve different purposes.
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 usage context: you should use this when you have a paused or completed session to resume. It also directs the user to session_list for obtaining valid session IDs, which is helpful. However, it does not explicitly state when not to use it or mention alternatives like session_start or session_rollback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explains key behaviors: anchors persist with the document, follow Placement moves, coord_frame conversion logic, replace semantics, screenshot default, and that it records a modeling-session step. This goes beyond a simple 'what it does' and helps the agent predict side effects. Minor gaps remain, such as not detailing merge behavior when replace=false, but the parameter description covers this adequately.
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: a one-line purpose, followed by key context, then Args and Returns sections. Every sentence adds value, with no fluff or repetition. It front-loads the core function and organizes details logically, making it easy for an agent to parse quickly.
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 tool's complexity (6 params, nested objects, enum, no annotations), the description is fairly complete. It covers purpose, parameter semantics, returns, and important behavioral context, leaving little ambiguity. The only minor omission is explicit guidance on which sibling tools to use in complementary situations, but the description remains sufficient for correct invocation.
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?
Schema description coverage is 0%, so the description must explain parameters. It does so via an Args section that describes the anchors format with pos and dir, the replace flag, coord_frame values with conversion guidance, and the with_screenshot default. It misses doc_name and obj_name, but these are self-explanatory given the tool name and required context. The description adds significant meaning beyond the bare 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's function: 'Define explicit named anchors on an object.' This is a specific verb+resource combination that distinguishes it from sibling tools like get_anchors (retrieve anchors) and align_shapes (geometry alignment). No ambiguity about what this 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?
The description provides clear context on when to use this tool, such as 'use it whenever your source coordinates are global' for coord_frame. It also mentions that anchors persist and follow Placement moves, implying usage in modeling or assembly workflows. However, it does not explicitly state when not to use it or mention alternatives like get_anchors for reading anchors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: read-only, auto-derivation rules, merging of explicit anchors with precedence, and coordinate frame (GLOBAL). It also details the return format with source field, offering comprehensive transparency beyond any structured metadata.
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 with a clear purpose sentence, a concise explanation of behavior, and a separate 'Returns' section. Every sentence adds valuable information 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?
For a two-parameter read-only tool, the description covers the purpose, behavior, derivation logic, coordinate system, precedence rules, and return format. It is self-sufficient and contextually complete even without annotations or an output schema.
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 input schema provides no description for doc_name and obj_name (0% coverage), and the description only indirectly indicates that obj_name refers to an object with a Shape and doc_name is the document. It adds context about anchors being derived from the Shape, but doesn't explicitly define the parameters, leaving some ambiguity.
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 'List an object's assembly anchors in GLOBAL coordinates (read-only)' with a specific verb and resource. It also distinguishes itself from siblings like set_anchors by emphasizing read-only behavior and describing auto-derivation and merging logic.
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 instruction 'Call this BEFORE placing parts and plan mates from the returned numbers — never guess coordinates' provides explicit when-to-use context. It doesn't name alternatives directly, but the read-only label and mention of set_anchors clearly imply when not to use it (e.g., for writing anchors).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It clearly states that coordinates are in GLOBAL space and 'already transformed by the object's Placement,' which is a crucial behavioral detail. It also lists what the tool returns (center, normal, axis, radius, endpoints). However, it does not explicitly mention side effects or error behavior, though 'Get' implies 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 well-organized into a summary, usage note, args, and returns. Every sentence adds value: the global-coordinate note, the alternative tool reference, and the parameter clarification. Nothing is wasteful or redundant.
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 complexity and the presence of an output schema, the description covers all essential aspects: purpose, usage context, distinguishing from get_topology, parameter handling, and return content. It is sufficiently complete for a read-only getter with a well-defined schema.
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 input schema has 0% description coverage, so the description must compensate. It explains the 'element' parameter with its allowed values ('face', 'edge', or 'vertex') and clarifies that 'element_index' is 0-based and should be found via get_topology. The other two parameters (doc_name, obj_name) are not explained, but their names are self-explanatory in context. This is partial compensation, not complete.
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: 'Get detailed global-coordinate spatial info for a specific face, edge, or vertex.' It also distinguishes from a sibling tool by saying 'Use this instead of get_topology when you need precise positioning data for alignment or assembly.' This is clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this instead of get_topology when you need precise positioning data for alignment or assembly.' It also tells users to 'use get_topology to find indices' for the element_index parameter, offering a concrete workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It transparently discloses the possible statuses ('running', 'done', 'error'), how output is captured, and that error tracebacks are included on failure. It does not mention polling semantics or side effects, but for a simple result-fetch 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 structured with Args and Returns sections, uses concise language, and front-loads the purpose. Every sentence adds information without verbosity.
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 simple one-parameter tool with an output schema, the description covers purpose, parameter source, and return shape. It is fully sufficient for an agent to select and invoke this tool correctly, especially given the clear relation to execute_code_async.
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% parameter description coverage, so the description compensates by fully explaining task_id as 'The task ID returned by execute_code_async'. This gives a clear source and meaning, though no additional constraints or formats are provided.
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 function: retrieving status and output of a background task. It names the specific originating tool (execute_code_async) and distinguishes it from siblings by focusing on the async task lifecycle.
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 clearly indicates this tool is for background tasks started by execute_code_async, giving clear context for use. It does not explicitly contrast with execute_code or list exclusions, but the async-task framing makes the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It discloses the tool's behavior: returns a parameter reference for a named operation or a topic list when called with no arguments. It adds useful context about documentation location, though it does not explicitly state side-effect freedom (likely inherent for a help tool).
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, front-loaded with the core purpose, and every clause adds value. It avoids fluff while conveying the parameter usage, documentation strategy, and examples.
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 simple help/lookup tool with one optional parameter and an output schema, the description is complete. It explains the input behavior, the fallback when omitted, and why docs live here rather than in docstrings. No additional return-value detail is needed because an output schema exists.
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 provides only the parameter name and type (string/null, default null), with zero description coverage. The description compensates by explaining the parameter's semantics: pass an operation name to get its reference, or omit it to get the topic list, with examples. It could enumerate all valid operation names, but the fallback to a topic list mitigates this.
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 identifies the tool as a documentation reference for cad() operations and assembly_session, with specific examples like 'sketch' and 'hull'. This distinguishes it from sibling tools that perform operations rather than explain them.
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 explicitly states how to invoke the tool ('Call with an operation name... or none for the topic list') and gives concrete examples. It also implies when not to rely on docstrings ('Detailed docs live here... to keep the tool list small'), but does not name specific alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It clearly tells the agent that the tool stores a pattern, optionally saves the document (with save_path behavior explained as 'saveAs; omit to save in place'), and returns JSON with pattern_id and save result. It doesn't mention whether the session becomes unavailable after completion, which is an implied effect, but overall it provides strong transparency for a state-changing 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 well-structured with a leading purpose sentence followed by a clear Args/Returns layout. It is concise, every sentence earns its place, and it front-loads the primary action before detailing parameters. No unnecessary 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?
The description is quite complete for a finalize-like tool: it covers the main effects, parameter semantics, and return value. It doesn't detail prerequisites (e.g., having an active session) or post-conditions (e.g., session invalidation), but given the tool's simplicity and the presence of an output schema (though not shown), the description provides sufficient context for an agent to use it correctly.
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 meaning for every parameter, which is critical given 0% schema description coverage. It explains 'save' as saving the FreeCAD document (.FCStd), 'save_path' as the target path with 'saveAs' semantics, 'description' as what the workflow builds, and 'tags' as retrieval tags. This goes well beyond the bare schema titles, fully compensating for the schema's lack of descriptions.
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 function: 'Complete the active session: store the whole workflow as a reusable pattern in the pattern store... and optionally save the document to disk.' This uses a specific verb ('complete') and resource ('active session'), and mentions the foundational actions. It distinguishes from siblings like session_pause or save_pattern by focusing on session completion and pattern storage, while also referencing recall_patterns for later retrieval.
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: when completing an active session and optionally saving the document. It explicitly mentions that patterns can be recalled later with recall_patterns, which provides an alternative for retrieval. However, it doesn't explicitly state when not to use it or contrast it with similar tools like save_pattern, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It adds the key behavioral trait that redo is only valid until a new cad() operation, and it describes the return format (JSON with restored step numbers). It does not elaborate on failure behavior when n exceeds available steps, but the core behavior is transparent.
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 well-structured. The first sentence delivers the primary purpose, followed by clear Args and Returns sections. No wasted words, and the layout aids quick comprehension.
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 one-parameter tool with an output schema, the description covers the essential use case, return format, and validity constraint. It lacks explicit error-handling notes or edge cases, but given the tool's simplicity, it is nearly complete.
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 must compensate. The description fully explains the only parameter 'n' as 'Number of steps to restore (default 1)', providing complete semantic meaning beyond the schema's type and default.
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 a specific action with a specific resource: 'Redo n previously rolled-back steps'. It also adds a temporal constraint, 'valid until a new cad() operation', which helps distinguish this from other session operations. It effectively differentiates from sibling tools like session_rollback.
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 contextual usage: redo is for restoring previously rolled-back steps and is only valid until a new cad() operation. It implies when to use it without explicitly naming alternatives or exclusions, but the context is sufficient 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It openly states read-only nature and pure data feedback, and discloses that hidden objects are skipped and counted in skipped_hidden. It does not cover auth or rate limits, but for a read-only audit, the disclosure 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 structured into Reports, Args, and Returns, making it easy to scan. Each sentence provides necessary information without fluff. It is longer than a one-liner but earns its length through comprehensive detail.
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 there is an output schema, the return value description is a bonus but still included. The description covers all four parameters, explains the tool's behavior, and gives usage guidance. Combined with the structured schema, the description is complete enough 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?
Schema description coverage is 0%, so the description must compensate. It provides an Args section explaining checks, float_threshold, and interference_min_volume with default values. However, the 'checks' parameter format is somewhat cryptic (using syntax like {'obj', 'anchor', ...}), and doc_name is only implied, not explicitly described.
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 function: 'Audit the document's spatial sanity' and lists the specific checks it performs (floating, interferences, per-check pass/fail). This specific verb+resource combination distinguishes it from sibling tools like check_interference or measure_geometry.
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 'Call after modeling/assembly steps for a numeric health report instead of eyeballing screenshots,' which provides clear usage context. However, it does not mention any exclusions or explicitly compare to alternative sibling 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.
Behavior4/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 transparently explains the two operating modes, the type of returned data (JSON with properties/members/docstring), and that output is 'compact, capped'. However, it does not explicitly state the tool is read-only or has no side effects, though 'runtime introspection' implies non-mutating behavior.
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: it leads with the core purpose, then details modes and return format. It is concise, with no filler or redundancy; every sentence adds essential information.
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?
The description is complete for the tool's complexity: it covers purpose, usage modes, parameter semantics, and return format. An output schema exists, so return values are already structured. The note about 'compact, capped' output adds valuable context. No significant gaps remain.
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% and the schema provides no descriptions, but the description fully compensates by explaining how each parameter is used: 'pass doc_name + obj_name' for object mode and 'pass dotted_name' for API mode. This gives clear semantics for all three optional parameters.
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 performs 'Runtime introspection of the FreeCAD Python API' with specific verbs and resources. It also distinguishes itself from siblings by explicitly positioning it as a 'last-resort reference' when knowledge and recall_patterns are insufficient, and by describing two concrete modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('last-resort reference when both your knowledge and recall_patterns are insufficient') and names an alternative (recall_patterns). The two modes further define how to invoke it, giving clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 clearly states that the tool stores a pattern and returns a pattern_id, which informs the agent of the persistence side effect. However, it does not disclose whether saving a pattern with an existing name overwrites or errors, nor does it mention any permissions or constraints. This minor gap prevents a perfect score, but the core behavior is transparent.
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 appropriately sized, starting with a one-sentence purpose, then a helpful knowledge hierarchy, and a clear Args/Returns structure. Every sentence contributes value: the knowledge hierarchy explains when to use the tool, and the Args section explains parameters. No fluff or 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?
For a storage tool with four parameters, the description fully covers the operation, return value, and usage context. The knowledge hierarchy and sibling references provide integration context. The output schema is implied by the documented return value (pattern_id), so no additional explanation is needed. The tool is well-specified 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. It does so with a dedicated 'Args:' section explaining each parameter: name (with example), description (purpose), code (optional snippet), tags (retrieval purpose). This adds meaning well beyond the bare schema properties, giving the agent all necessary semantic information.
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+resource: 'Store a reusable modeling pattern (code snippet or workflow) into the pattern memory.' It clearly indicates the action and the target. It also distinguishes itself from siblings by referencing recall_patterns and inspect_freecad in the knowledge hierarchy, making the tool's niche explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Call this after a non-trivial approach worked.' The knowledge hierarchy states when to use alternatives ('recall_patterns when unsure', 'inspect_freecad for API details') and that successful new approaches should be stored back here. This gives the agent clear decision criteria for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 precisely discloses that execution runs on a background thread, enumerates forbidden operations (GUI, selection, document objects, recompute, save), notes that print() is not captured, and instructs to use task_print() and poll via get_task_result. This is thorough and actionable.
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?
Every sentence delivers essential information. The description is front-loaded with purpose, then constraints, alternatives, output handling, and parameters. It is dense but not bloated, with clear paragraph and Args/Returns structure. No wasted words.
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?
The tool's complexity (async execution, thread safety, polling) demands thorough documentation. The description covers the what, when, constraints, output capture, and return polling mechanism. It even names the sibling get_task_result for follow-up, making it fully self-sufficient for an agent to invoke and handle results 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 single parameter 'code' has no schema description (0% coverage). The description's Args section adds only 'Background-safe Python code to execute,' but the broader description elaborates extensively on what background-safe means, including a list of forbidden operations. This compensates for the schema gap, though a slightly more detailed parameter explanation would be ideal.
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: 'Execute Python code in FreeCAD without waiting for completion.' It clearly distinguishes this from its sibling execute_code by emphasizing asynchronous execution and explicitly naming the safe alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage conditions: 'Only for long pure OCCT/CPU computations on already-fetched shapes.' It also states when NOT to use it ('must NOT touch FreeCADGui...') and names the alternative ('use execute_code instead'). This leaves no ambiguity about 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so admirably. It discloses destructive behavior (undoing transactions, truncating step log), the redo buffer lifecycle, the risk of force across non-atomic steps, and the exact return payload including the fingerprint consistency check.
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 with a brief opening sentence, a behavioral summary, and clear Args/Returns sections. Every sentence adds value and there is no repetition or filler. The length is justified by the tool's complexity.
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 disruptive nature and the absence of annotations, the description is complete. It covers purpose, parameter semantics, side effects, caveats, and return value structure. The presence of a return schema does not make the extra return explanation redundant because it adds meaningful context about the consistency check.
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%, but the description fully compensates by explaining both parameters: to_step is defined as keeping steps 1..to_step and undoing everything after with 0 meaning undo all, and force is described as a risky override for non-atomic execute_code steps. This goes far beyond the bare 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 opens with a specific verb+resource statement: 'Roll back the model to a previous step.' It then clearly distinguishes the tool's function by explaining it undoes document transactions, truncates the step log, and interacts with session_redo, separating it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains when rollback is appropriate, how steps moved to the redo buffer relate to session_redo, and that a new cad() operation discards them. It also warns about the risky force option for non-atomic execute_code steps, giving explicit guidance on when extra caution is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cadpilot MCP server](https://glama.ai/mcp/servers/LBurny/cadpilot/badges/card.svg)](https://glama.ai/mcp/servers/LBurny/cadpilot)

Score Badge

Copy to your README.md:

[![cadpilot MCP server](https://glama.ai/mcp/servers/LBurny/cadpilot/badges/score.svg)](https://glama.ai/mcp/servers/LBurny/cadpilot)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LBurny/cadpilot'

If you have feedback or need assistance with the MCP directory API, please join our Discord server