kompas3d

by hymaxo

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
Several tool families overlap in purpose, notably open_model/open_document, create_part/create_document, save_model/save_document, and inspect_model/list_entities. The SDK/API discovery cluster (api_describe_interface, api_describe, api_constants, api_catalog, api_cast, sdk_search, sdk_read) is also very hard to distinguish without reading each description. An agent would frequently need to dig into details before confidently choosing a tool.
Naming Consistency3/5
Most names use snake_case verb_noun form, and subgroups like draw_*, list_*, and create_*/update_*/delete_* are internally consistent. However, conventions are split across api_*, sdk_*, bare verbs like connect/extrude/revolve, and noun-like names such as blueprint_view. api_describe_interface vs api_describe further blurs the otherwise readable pattern.
Tool Count2/5
At 41 tools this is well above the 25-tool threshold for a coherent server, even considering CAD's broad scope. The count is inflated by a large SDK introspection family and parallel API5/API7 document workflows that could be consolidated. It feels heavy rather than curated.
Completeness3/5
Core workflows are covered: part modeling, sketch creation, features, document lifecycle, drawing views, import/export, variables, and materials. However, assembly support stops at insert_component with no typed assembly constraints, and 2D drawing annotations are limited to line/circle/linear dimension/text. The unrestricted api_invoke/api_batch tools can fill gaps, but only by leaving the typed, safe surface.
Average 3.5/5 across 41 of 41 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only discloses the operation type and unit semantics (mm). It does not explain what 'associative' means, whether existing views are affected, whether this is destructive, or what side effects occur on the drawing.
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?
Two short sentences with no filler. The core purpose is front-loaded, and the unit note is a meaningful addition. It is concise, though arguably under-specified for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no annotations, and no output schema, this description is far too minimal. Missing preconditions, return values, projection semantics, and behavioral expectations leave an agent unable to invoke the tool confidently.
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, but it only adds that coordinates/gaps are in mm. Parameter names and the projections enum provide some hints, but drawing_handle, model_path, scale, and orientation are left unexplained in both schema and description.
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 names a specific action ('Create') and a specific resource ('associative engineering views from a native model in a drawing'). It clearly differentiates from drawing primitives like draw_line or create_sketch, though it does not explicitly name alternative tools.
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 when-to-use or when-not-to-use guidance is provided. It does not mention alternatives, prerequisites (e.g., whether the drawing must be open or the model loaded), or exclusions. The phrase 'from a native model in a drawing' gives context but no actionable selection criteria.
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 of behavioral disclosure. It only says 'Create', implying a mutating operation, but does not reveal side effects, prerequisites, how the dimension associates with geometry, or failure behavior. 'Native measured' adds some context, but not enough for a tool with zero annotation support.
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 a single concise sentence with no filler words. It front-loads the core action and resource. However, its brevity borders on under-specification for a tool with nine parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nine parameters, zero schema coverage, no annotations, and no output schema, the description is incomplete. It does not explain orientation behavior, the meaning of view_number, the role of drawing_handle, or expected return values. The description is adequate for a high-level summary but not sufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It hints that x1/y1/x2/y2 are points and text_x/text_y is the text location, but it does not explain critical parameters like drawing_handle, view_number, or orientation. The description adds some meaning beyond the bare schema, but leaves most parameters semantically unexplained.
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 states a specific verb ('Create') and resource ('native measured 2D linear dimension between points'), which clearly identifies what the tool does. The word 'measured' helps distinguish it from plain geometric drawing tools like draw_line or draw_circle, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as draw_line or draw_text. There is no mention of required context like an active drawing, view, or sketch, and no exclusions or conditions are stated.
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?
With no annotations, the description carries the disclosure burden. It discloses that the action mutates entity state and rebuilds, but does not explain side effects, reversibility, permissions required, or the consequences of suppression/restoration beyond the rebuild.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every phrase adds operational information and the format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and 0% schema coverage, yet the description does not cover return values, prerequisites, relationship among parameters, or operational risks. Too sparse to give an agent enough context for a mutating CAD operation.
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%, so the description must compensate. The verbs 'rename', 'hide/show', and 'suppress/restore' loosely map to the name, hidden, and excluded parameters, but the required document_id and entity_id are not explained, and null/default semantics and parameter interactions are undocumented.
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 names specific operations (rename, hide/show, suppress/restore) and a clear resource ('native entity'), followed by the rebuild side effect. It is distinct from siblings like set_variable or set_material, though it does not explicitly contrast itself with update_feature or delete_feature.
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 on when to use this tool versus alternatives such as update_feature, delete_feature, or list_entities. The description lists what it can do but does not state the context, prerequisites, or when-not-to-use conditions.
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?
There are no annotations, so the description carries the full behavioral disclosure burden. It only mentions license/converters availability; it does not disclose that this creates or writes a file, how overwrite behaves, whether failures are likely, or what side effects occur. This is insufficient for a tool with no annotation support.
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 very short and front-loads the primary action and formats. The second sentence about availability is relevant and earns its place, though the brevity comes at the cost of missing important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema description coverage, this one-line description is not enough to safely invoke the tool. It leaves unclear how the format is chosen, what path should look like, whether overwrite must be true to replace files, and what the tool returns or how it signals failure.
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%, and the description does not compensate by explaining document_id, path, or overwrite. The parameter names are somewhat self-explanatory, but no guidance is given about expected path format, file extension conventions, or how the export format is determined.
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 starts with the verb 'Export' and names the resource ('model') plus supported formats (STEP/STL/IGES), so the basic purpose is clear. It does not explicitly distinguish itself from siblings like save_model or save_document, but the format-specific export intent is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a meaningful usage condition: availability depends on installed KOMPAS license/converters. However, it does not say when to prefer this tool over save_model, save_document, or other output-related tools, nor does it mention any exclusions.
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 of behavioral disclosure. It mentions the add/cut operation and the finite-depth nature, but it does not state that this mutates the document, whether an open document is required, or how existing geometry is affected. It largely restates information already implied by the schema's operation enum and required sketch_id.
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 a single sentence with action first and no filler, making it easy to parse. It is concise, though slightly too terse to fully support a tool with a required document_id and a nested spec object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, this sparse one-liner is not complete enough for an agent to invoke the tool correctly. It leaves out the required document_id, expected return values, and behavior of reverse/draft_angle, providing only the sketch prerequisite as context.
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%, and the description only weakly hints at sketch_id ('existing sketch') and depth ('finite-depth'). It does not explain document_id, the nested spec object, reverse, draft_angle, or operation semantics beyond the schema's own constraints, so it fails to compensate for the missing parameter descriptions.
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 uses 'Add or cut' as a specific operation and 'finite-depth extrusion from an existing sketch' as the resource/target. It clearly communicates what the tool does, though it does not explicitly contrast with sibling tools like revolve or create_feature.
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 phrase 'from an existing sketch' implies the prerequisite that a sketch must already exist before calling. There is no explicit when-to-use guidance, no exclusion criteria, and no alternative tool is mentioned, so the agent must infer usage from 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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions read-only and visibility choices but does not state side effects like whether opening a document changes the active session, whether unsaved changes are affected, or what happens with unsupported paths. The description adds some context but is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no filler or redundant wording. However, it is so compact that it sacrifices informative content, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no output schema, and no annotations, this description is incomplete. It does not enumerate the six native formats, explain the opening behavior or consequences, or document the visible/read-only options beyond naming them. An agent would likely need additional information to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate by explaining parameter semantics. It only vaguely alludes to read-only and visibility choices, which are already inferable from parameter names. It gives no explanation of what 'path' should contain, accepted formats, or how defaults behave, 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 states a specific verb ('Open'), a specific resource ('any of the six native document formats'), and explicit behavioral modifiers ('read-only/visibility choices'). This clearly distinguishes it from sibling tools like list_documents or create_document, and the scope is concrete enough to avoid confusion with open_model.
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 given about when to use this tool versus alternatives such as open_model or insert_component. There are no stated conditions, exclusions, or tips for selecting this tool over siblings, leaving the agent to infer usage context from the name and sibling list.
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 of behavioral disclosure. It does reveal that the operation is mutating ('Add or cut') and states a prerequisite, but it does not explain what happens with an invalid sketch, whether the active model is modified, or what the tool returns.
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 a single, front-loaded sentence with no filler: it states the action first and the essential precondition second. It is appropriately concise, though slightly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a nested RevolutionSpec with five fields, no annotations, and no output schema, this one-sentence description is not complete enough. It omits document context, angle/reverse semantics, and guidance distinguishing this rotational feature tool from extrude or other feature-creation siblings.
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%, and the description only indirectly clarifies that sketch_id must reference a sketch with a profile and construction axis, and that operation corresponds to add/cut. It adds no meaning for document_id, angle, reverse, or name, leaving most parameters dependent on raw schema structure.
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 states a clear action ('Add or cut') and a specific resource ('a revolution'), and it adds the key precondition that the sketch must contain a profile and construction axis. This is enough to understand the tool's core purpose, though it does not explicitly contrast it with siblings like extrude.
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 gives an important usage condition: the sketch must contain a profile and a construction axis. However, it does not state when to prefer this tool over sibling alternatives such as extrude, nor does it mention any exclusion cases.
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 behavioral disclosure burden. It does reveal a meaningful side effect ('and rebuild') and the create flag's effect ('enables new user variables'), which go beyond the schema. However, it does not disclose whether existing values are overwritten, how value and expression interact, or what happens when value is null. Partial disclosure, not a contradiction.
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 a compact two-sentence structure with the core operation front-loaded: 'Set one numeric value OR native expression and rebuild.' Every sentence adds useful information, and there is no filler. Slightly more detail could be added without harming conciseness, but as written it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven parameters, no annotations, and no output schema, the description is too thin to fully equip an agent. It does not explain the required document_id/name roles, the purpose of feature_id, or the mutual-exclusivity handling of value vs expression. The agent would likely need to open schemas or guess to invoke correctly in varied scenarios.
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. It adds meaning to value ('numeric'), expression ('native expression'), and create ('enables new user variables'), but says nothing about document_id, name, note, or feature_id. Seven parameters exist, and at least four receive no semantic explanation in the description or schema.
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 names a clear verb ('Set'), a resource ('variable'), and adds scope ('one numeric value OR native expression', 'rebuild'). It is distinguishable from sibling tools like list_variables (read vs write) and create_feature (features vs variables). It loses one point because 'rebuild' is left vague and the description does not explicitly contrast with list_variables.
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?
There is no explicit guidance on when to use this tool instead of a sibling. The phrase 'Explicit create enables new user variables' implies a condition for creating vs updating, but it does not say when to prefer set_variable over list_variables or other mutation tools. No exclusions or alternative-routing are provided.
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 behavioral disclosure burden. It does state that the operation is a read, implying non-mutating behavior, but it gives no detail about output shape, error cases, handle semantics, or any 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 a single front-loaded sentence with no filler or redundant wording. Every word adds meaning and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and one under-documented required parameter, the description is too thin to fully support correct invocation. An agent would still need to infer when to use this tool and what 'handle' should contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a generic 'handle' string with 0% description coverage, so the description must clarify the parameter. It weakly implies that the handle refers to something with generated SDK signatures, but it never explicitly explains what handle values are valid or how to obtain them.
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 uses a specific verb ('Read') and identifies a concrete resource ('generated SDK method signatures and readable/writable properties'), making the core purpose clear. However, it does not differentiate this tool from the sibling api_describe_interface or other SDK-related tools like sdk_read and sdk_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention api_describe_interface, sdk_read, sdk_search, or api_invoke, nor does it state any conditions or exclusions that would help an agent choose correctly.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the circle is 'native editable' and that radius uses mm, but it does not state requirements like an existing drawing_handle, coordinate-system behavior, side effects, or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence conveys the core action and scope with no filler. The useful unit detail earns its place at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, four required, no annotations, and no output schema, this description is too sparse to give an agent a complete calling context. It does not explain what drawing_handle refers to, how style or view_number behave, or in what units x and y are expressed.
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. It adds meaning for radius (mm) and implicitly places x/y in a drawing view, but it leaves drawing_handle, style, view_number, and x/y units undefined.
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 a specific action ('Draw'), a distinct resource ('native editable circle'), and the context ('in a drawing/fragment view'). It could explicitly contrast with sibling drawing tools like draw_line, but the resource is specific enough to tell the tools apart.
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 phrase 'in a drawing/fragment view' implies when the tool applies, but there is no explicit guidance about when to choose it over alternatives or when not to use it. No exclusions or preconditions are stated.
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 behavioral burden. It does disclose three meaningful behavioral traits: matching extension, read-only state, and overwrite policy. However, it does not explain what happens when these are violated, whether overwrite is destructive, or what the response contains.
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 entire description is one compact sentence with no filler. It front-loads the core action and then lists the key policy constraints, earning each word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description does not explain usage context, parameter details, or return behavior. Given the large sibling list, especially save_model, more contextual guidance is needed to avoid mis-selection and misuse.
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 for the bare parameter names. It only hints at the overwrite behavior and says nothing about the meaning or format of 'handle' and 'path'. This is insufficient for an agent to construct valid arguments confidently.
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?
Description uses a specific verb ('Save') and a resource ('native API7 document'), and adds behavioral constraints that clarify what the operation means. It does not explicitly distinguish itself from sibling save_model, but 'native API7 document' hints at a different resource scope.
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 given about when to use this tool versus alternatives like save_model, create_document, or open_document. The description states what it enforces but not the intended invocation context or prerequisites.
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 disclosure burden. It clearly communicates the core mutation (assign material and density) and the response behavior (updated mass in kg), which is useful. However, it does not mention side effects such as whether existing materials are overwritten, whether changes are persistent, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence with no filler. It front-loads the action and efficiently adds unit and output information that is not present in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description is too thin. It lacks preconditions (e.g., whether a model must be open or document_id must reference a part), a return structure beyond mass, and error or edge-case context. It is minimally usable but not complete.
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. It adds meaning for density_g_cm3 by specifying units (g/cm³) and relates the output to mass in kg, but it does not explain what document_id refers to or what values name expects.
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 uses a clear action verb ('Assign') with a specific resource ('part material and physical density') and states the resulting output ('report updated mass in kg'). It is unambiguous about what the tool does, though it does not explicitly differentiate it from sibling tools like update_feature or set_entity_state.
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 when-to-use or when-not-to-use guidance is provided, and no alternatives are mentioned. The description only defines the operation itself; an agent has to infer when this tool is appropriate relative to sibling mutation 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?
Because no annotations are provided, the description carries the full burden of behavioral disclosure. It does disclose two important traits: a known type does not guarantee interface support, and failures are reported as COM errors. It does not mention side effects, the success return value, or whether the operation mutates state, leaving some behavioral ambiguity.
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 compact and front-loaded: the core operation appears in the first sentence, followed by a concrete example and a useful caveat. No sentence is redundant or filler. It could be slightly clearer about prerequisites, but structurally it is well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description must carry almost all operational context. It explains the purpose and failure reporting, but an agent is left without guidance on handle provenance, library selection, return shape, or prerequisites such as an active connection. For a COM-style cast with three undocumented parameters, this is incomplete.
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 for the handle, library, and interface parameters. It only indirectly hints at valid interface names through the example (IPart7, IModelContainer) and does not explain what handle refers to or when to choose kAPI5 versus kAPI7. This is a significant gap for a three-parameter tool.
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 uses a specific verb and resource: 'QueryInterface to an additional installed SDK interface,' and provides a concrete example (IPart7 to IModelContainer). This makes the tool's core action clear and distinguishes it from sibling tools like api_describe_interface, which inspects rather than obtains an interface. It does not explicitly contrast itself with api_invoke, but the intent is unambiguous.
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 the usage scenario: you have a handle to one interface and want to obtain another interface on the same object. It also warns that support is not guaranteed, so the agent can expect failures for unsupported casts. However, it does not explicitly state when to prefer this over alternatives or what prerequisites must hold.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does convey that the line is 'native editable' and uses mm coordinates, but it does not explain side effects, return behavior, error conditions, or whether an existing drawing is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It conveys the core purpose and units efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and no annotations, this one-liner is incomplete. It leaves the role of drawing_handle, view_number, and style unclear, and gives no indication of how to obtain the required handle or what happens if the view is invalid.
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%, and the description only adds meaning to the coordinate parameters by noting mm units. The required drawing_handle and the optional style/view_number parameters remain entirely unexplained, so the description does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Draw'), a specific resource ('native editable line'), and the context ('drawing/fragment view'). This cleanly distinguishes it from sibling tools like draw_circle and draw_text.
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 about when to use draw_line versus alternatives such as draw_circle or draw_text, nor about prerequisites like having an active drawing view or valid drawing handle.
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?
There are no annotations, so the description carries the full behavioral burden. It discloses that the text is 'native editable' and that coordinates are in mm and angles in degrees, but it does not explain coordinate origin, angle reference direction, what drawing_handle refers to, or any side effects of adding text.
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 one compact sentence that front-loads the core purpose and then appends the key unit constraints. Every phrase adds information, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no annotations, and no output schema, the description is incomplete. An agent still lacks information about the required drawing_handle semantics, the meaning of view_number, coordinate reference, expected return value, and any failure conditions.
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. It adds unit semantics for positions and angle, but it does not explain drawing_handle, view_number, or how x and y align with the text anchor. The parameter meanings remain largely implicit from names and 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 uses a specific verb 'Add' and a clear resource: 'native editable text to a drawing/fragment view.' It distinguishes this from sibling tools like draw_line, draw_circle, and draw_linear_dimension by naming the text-specific behavior.
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 given about when to use this tool versus alternatives such as draw_linear_dimension or create_feature. There are no exclusions, prerequisites, or context cues for the agent to decide when this is the right drawing operation.
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?
Since no annotations are provided, the description carries the full burden. It discloses the immediate insertion behavior and the returned placement handle, but it does not mention side effects on the assembly, auth requirements, reversibility, or how the 'linked' option affects 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 two short, meaningful sentences with no filler or redundant restatement of the tool name. The main operation is front-loaded and the return value is stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, zero schema description coverage, no annotations, and no output schema, the description is too thin. It says what the tool does and returns, but omits the semantics of all parameters, the effect of 'linked', and any prerequisites or side effects an agent would need to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no meaning for assembly_handle, path, or linked. The 'path' parameter is particularly ambiguous, and the description does nothing to clarify its format or purpose.
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 action ('Insert'), the target resource ('native part/subassembly occurrence'), and the context ('in an explicit assembly'), plus the return value ('placement handle'). It does not explicitly name or distinguish alternatives, but the verb and resource make the tool's purpose specific enough to tell apart from obvious siblings like create_part or create_feature.
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 wording implies this tool is used when you need to place a part or subassembly occurrence into an explicit assembly, but it does not provide explicit when-to-use or when-not-to-use guidance. There is no mention of alternatives or prerequisites such as requiring an already-open assembly.
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 behavioral disclosure burden. It adds the useful context that no prior object is required, but it doesn't state that the operation is read-only, describe the return format, or mention error conditions for unknown interface names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and includes a key differentiator. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too sparse. An agent lacks information about how the schema is returned, what library values imply, and what happens if the interface is not found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters, but it only clarifies 'interface' indirectly as 'installed interface'. It does not explain valid interface name formats or how library choices affect behavior, leaving the interface parameter underdocumented.
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 uses a specific verb 'Get' and a specific resource 'schema for any installed interface', clearly identifying the tool's function. It contrasts with sibling api_describe by focusing on interfaces and the no-object-needed advantage, though it does not explicitly name alternatives.
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 when to use it: when you need an interface schema without first having an object. However, it offers no explicit comparison to sibling tools such as api_describe or api_invoke, and no conditions for when not to use it.
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 behavioral burden. It usefully discloses that the operation creates something new and explicitly guarantees it will not replace the user's open documents. However, it does not mention prerequisites, whether the new part becomes active or visible, what happens if no document is open, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence with no filler. It front-loads the core action and resource, then appends the key side-effect guarantee. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description says surprisingly little about the operational context. It does not state whether an active model or connection is required, whether the part is added to a specific document, or how the agent should observe the result. For a tool that performs a mutation, this leaves important invocation and follow-up questions unanswered.
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%, and the description never mentions the 'name' parameter or its optional/default nature. The schema's title 'Name' and default 'Part' provide minimal meaning, but the description adds no parameter-level semantics or guidance on how the name is used.
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: 'Create a new native part.' It then adds a meaningful behavioral qualifier, 'without replacing the user's open documents,' which helps differentiate it from document-level operations such as open_document or create_document. This is specific enough for an agent to identify the tool's purpose without inspecting other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus alternatives. The 'without replacing' clause hints at a distinction, but it does not name sibling tools or state conditions such as 'use create_document when you need a new document' or 'use create_sketch for sketches.' An agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. "Search/paginate" implies a read-only operation, and "discover hidden capabilities" hints at a distinctive behavior: surfacing interfaces that may not be obvious. Still, it does not disclose return format, pagination behavior, or any limitations, so it only partially covers behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Both the core operation and the notable "hidden capabilities" aspect earn their place, making this an efficient and well-structured definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a 0% schema description coverage, the description is the only source of guidance. It covers the tool's purpose and parameter meanings at a high level, but it does not explain what results look like, how "hidden capabilities" manifest, or how to use the returned catalog entries with related tools like api_describe_interface or api_invoke. This is adequate but has clear gaps.
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 for the lack of parameter docs. It does reasonably well: "by name" clarifies the query parameter, "API5/API7" maps to the library enum, and "Search/paginate" implies how limit and offset are used. This adds meaningful semantics beyond the raw schema, though it does not explain default behavior or exact matching rules.
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 states a specific verb and resource: "Search/paginate every installed API5/API7 interface by name." This clearly identifies what the tool does and its scope. However, it does not explicitly differentiate from siblings like sdk_search or api_describe_interface, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a broad catalog search use case, but it gives no explicit guidance on when to prefer api_catalog over sibling tools such as sdk_search, api_describe_interface, or api_invoke. There is no mention of alternatives, exclusions, or prerequisites, leaving the agent to infer selection criteria.
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 of behavioral disclosure. It conveys that the operation renders the current view to a PNG, but it does not disclose whether the PNG is returned directly, saved to disk, or how the output is delivered. It also does not mention side effects, requirements about an open/active document, or how 'current view' relates to camera state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes meaning: the action, the resource, the output format, and the purpose are all present and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the agent can do with the resulting PNG and any prerequisites for calling the tool. It does not clarify whether the function returns binary image data, a file path, or a URL, nor does it specify whether the document must be open or active. This leaves an agent uncertain about how to proceed after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate. It references 'the document' but does not explicitly explain that document_id identifies which document to render. While the schema property title 'Document Id' provides basic clarity, the description adds only minimal context about the parameter's role.
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 ('Render'), a resource ('the document's current view'), and an output format ('PNG image'). The added purpose ('for visual verification') distinguishes it from related tools like export_model or inspect_model by clarifying its role as a preview mechanism.
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 phrase 'for visual verification' implies the intended use case, giving some context for when an agent might choose this tool. However, it does not explicitly state when to use it versus alternatives such as blueprint_view, export_model, or create_standard_views, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses units ('in mm'), the default behavior of second_size ('defaults to equal chamfer legs'), and the source of edge IDs. However, it does not explicitly state that this is a mutating operation, does not mention prerequisites such as an active model or editable selection, and gives no indication of failure modes or reversibility.
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 front-loaded: the core action appears first, followed by the most essential parameter semantics and input sourcing. Every sentence carries useful information with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and several parameters, this description is incomplete. It lacks guidance on tangent behavior, the name field, document_id, return value, prerequisites, and what happens to the model after the operation. The core concept is clear, but too much is left unspecified for an agent to invoke it with full confidence.
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, but it only explains size, second_size, and edges. It does not clarify the kind parameter beyond the verb 'fillet or chamfer,' and it leaves name, tangent, and document_id unexplained. This partial coverage is insufficient for a nested spec with six properties.
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 a specific action ('Fillet or chamfer') on a specific resource ('selected current edges'), making the tool's purpose immediately understandable. It is distinguishable from sibling tools like create_feature or set_entity_state, though it does not explicitly name a sibling alternative.
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 usage context by explaining that edge IDs come from list_entities(o3d_edge), which effectively instructs the agent to prepare inputs via that sibling tool. It does not explicitly state when not to use this tool, but no sibling appears to offer the same fillet/chamfer capability, so the usage guidance is adequate.
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 itself must carry behavioral detail. It discloses two useful traits: the output is an editable native M3D/A3D file and overwrite is off by default. It does not disclose what happens on collision without overwrite, whether directories are created, or any return/error 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?
One compact, front-loaded sentence that packs purpose, format, path constraint, and default overwrite behavior without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter tool with no output schema and no annotations, the core is covered: what, where, format, overwrite default. Missing guidance on choosing this over export_model/save_document and collision/error behavior leaves some ambiguity, but the tool is simple enough that this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies path as absolute and overwrite as defaulting to false, adding real meaning beyond titles. However, document_id is left entirely to its schema title, and no parameter examples or value formats are provided.
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 names a specific action (save), resource (editable native M3D/A3D model), and destination (absolute path), which is clear. It does not explicitly name a sibling to distinguish from, although 'editable native' implies contrast with export_model or save_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording implies use this when an editable native-format save at an explicit filesystem path is needed. It gives no explicit when-to-use vs. alternatives, leaving the agent to infer the boundary against export_model and save_document.
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 behavioral burden, and it does a solid job: it explains that kind is an installed o3d_ enum, what data edges and faces include, and that solid_only defaults to true to exclude sketch and datum geometry. It does not explicitly declare read-only behavior or side effects, but the discovery framing plus the 'Rediscover topology after modifications' guidance conveys the operative behavior well.
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 compact and front-loaded with the core purpose, then efficiently covers kind, returned data, solid_only behavior, and usage context. Every sentence contributes information, though the final two imperatives are a bit terse and could be integrated more cleanly.
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 five-parameter tool with no output schema and no annotations, the description provides useful coverage of entity kinds, data fields, and filtering behavior. It falls short on explaining limit/offset behavior, document_id scope, the precise return shape, and how empty results or invalid kinds are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains kind and solid_only meaningfully, and gives examples for kind. However, limit, offset, and document_id receive no explanation, and pagination semantics are left entirely to the agent to infer from parameter names.
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: 'Discover existing native entities, including imported/reopened models'. It further distinguishes scope with entity kinds like o3d_edge and o3d_face, which helps separate it from document-level or sketch-level sibling tools. It stops short of an explicit contrast with closely related inspection tools, so it is clear but not fully differentiated by name.
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 context: use it to select entities by geometric evidence and to rediscover topology after modifications. It does not explicitly state when to prefer this over sibling tools like inspect_model, sdk_search, or set_entity_state, nor does it give exclusions or alternatives.
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 of behavioral disclosure. It does disclose that the tool reads HTML content as text and includes linked topics for navigation, which is genuinely useful. However, it does not explain how offset and length affect output, what a not-found topic does, or how the linked topics are represented in the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence with no wasted words. It immediately states the action, the resource, the output format, and the notable navigation behavior. It is appropriately sized for the tool's complexity.
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 three-parameter tool with no output schema and no annotations, the description provides a reasonable starting point but leaves key details open: how linked topics appear, whether output is paginated by offset/length, and what happens for invalid topic values. It is adequate for basic invocation but not fully complete for confident agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description only clarifies 'topic' by calling it an 'exact SDK HTML topic.' The length and offset parameters are not mentioned in the description at all, leaving their semantics to inference from names and defaults. The description does not sufficiently compensate for the missing schema documentation on two of three 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 uses a specific verb with a resource: 'Read an exact SDK HTML topic as text.' It also calls out 'exact' and 'including linked topics for navigation,' which differentiates it from sdk_search and the api_describe* siblings. This gives an agent a clear sense of what this tool does and what distinguishes it.
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 word 'exact' implies the agent should already know the specific topic, and the mention of navigation suggests this is for reading a known topic rather than searching for one. However, the description does not explicitly say 'use sdk_search to find a topic first' or otherwise contrast when to use this tool versus alternatives. Usage is implied rather than stated.
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 of behavioral disclosure. It does disclose an important behavioral trait: search is by filename substring, not full-text or semantic search. However, it does not describe what the returned results look like, how limit affects results, case sensitivity, or ordering. It is adequate but 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 a single sentence that is direct and front-loaded. It states the action, target, matching mechanism, and an example with no wasted words. Every part contributes to understanding the tool.
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 relatively simple with only two parameters and no output schema. The description gives enough to start using the query parameter, but it does not explain result format, limit behavior, or how the returned search results feed into other tools like sdk_read. For a search tool with no annotations, this is acceptable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The phrase 'filename substring' adds meaningful semantics to the 'query' parameter, clarifying that it is not a natural-language query. The 'limit' parameter, however, is not explained at all beyond its default value in the schema. The description partially compensates but leaves a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Find'), a clear resource ('installed SDK topics'), and a precise matching criterion ('by interface/member/enum filename substring'). The example 'e.g. fillet' reinforces the intended use. This clearly distinguishes it from related tools like sdk_read, which likely reads a specific topic rather than searching for one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when the agent needs to locate SDK topics by filename substring, but it does not explicitly state when to choose this tool over alternatives such as sdk_read or api_describe. There is no mention of when not to use it. The usage context is clear enough but not fully articulated.
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 behavioral burden. It discloses two meaningful side effects: the model is rebuilt after modification, and partial changes may persist if the operation fails. This is useful mutation transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences deliver the core action, the scope, and the key failure caveat with no filler. The information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is complex with nested FeatureSettings and DefinitionCall structures, but the description provides no orientation for how to construct the settings payload or identify the target feature. There is also no output schema or explanation of what a successful update returns, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It never explains what document_id or entity_id refer to, nor how the settings object maps to the feature definition. The term 'feature definition' hints at the settings parameter but leaves the required identifiers ambiguous.
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 ('Modify'), a specific resource ('existing native feature definition'), and the consequence ('rebuild the model'). This clearly distinguishes the tool from siblings like create_feature and delete_feature by emphasizing 'existing'.
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 word 'existing' implies this tool is for updating already-created features, not for creating new ones, but it never explicitly names alternatives or states when-not-to-use. The 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.
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 so strongly. It discloses unrestricted access, mutation and file-operation side effects, bypassing of typed save/ownership protections, session-handle behavior of returned COM objects, and verbatim false/zero results. This is rich behavioral disclosure for a powerful, risky 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?
Five terse, high-signal sentences with no filler. Risk warnings, usage constraints, and return behavior are all front-loaded or clearly placed, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter, no-annotation COM invocation tool with 0% schema description coverage, the description leaves critical gaps: action semantics, member syntax, arguments/value format, and handle usage are underspecified. The output schema is present, but the description alone is not enough for an agent to construct valid calls confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters, but it only hints at handle and arguments. It does not explain the action enum (call/get/set), how to specify member, the meaning of value, or the exact shape of arguments. The phrase 'Pass COM arguments as {"handle":"..."}' is also cryptic and does not clearly align with the schema's array-typed arguments.
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 identifies the tool as 'advanced unrestricted local COM access, including mutations and file operations,' which conveys a specific capability and resource. It also distinguishes itself from inspection siblings by instructing 'Inspect the interface first,' though it never explicitly says 'invoke a COM member on a handle' in direct terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: inspect the interface first, pass COM arguments via handle, and use only documented SDK members within the user's requested work. It does not name alternative tools or state when not to use this tool, so it stops short of full when/when-not/alternatives 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, the description carries the full behavioral burden. It clearly discloses a key safety-relevant behavior: unsaved changes cause a refusal unless discard_changes is explicitly true. It also limits the action to the current document, but does not describe return values, errors, or post-close state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The critical scope qualifier is front-loaded, and the conditional unsaved-changes behavior is stated immediately, making the description easy to parse and apply.
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 close operation, the description covers the purpose, the scope, and the main safety-relevant edge case (unsaved changes). It could mention error handling or what happens on success, but the essential invocation knowledge is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains discard_changes by linking it to unsaved changes and requiring it to be 'explicitly true', but it does not clarify the handle parameter beyond what the schema's type and title already imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Close') with a clear resource ('this document') and adds a scope qualifier ('only') that distinguishes it from operations like save_document or open_document. An agent immediately knows what action the tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use close_document versus alternatives such as open_document or save_document. The phrase 'this document only' provides scope but not usage context, exclusions, or prerequisites.
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 exist, so the description carries the full disclosure burden. It does disclose the main side effect ('or launch') and the return values, but it omits details such as whether a new instance is always created, how the visible parameter affects launching, and whether the handle is reusable across sibling tools. This is adequate but not thorough.
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?
One compact sentence front-loads the action and includes the key return information with no filler. Every part earns its place.
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 has only one optional parameter, and the description covers the core action and return values. However, with no output schema or annotations, it leaves the agent without important context such as the visible parameter's role, prerequisites (KOMPAS installed/running), and whether connect must precede other tool calls.
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% and the description never mentions the 'visible' parameter, so it does not help an agent understand the meaning of true/false or the default behavior. The property name and default true give only minimal inference; the description should have compensated for the schema's lack of parameter documentation.
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 names the exact action ('Connect to or launch'), the target resource ('local KOMPAS-3D'), and the outcome ('return version and application handle'). This clearly differentiates it from sibling tools like attach_active_model or open_model, which operate on models rather than establishing an application connection.
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 gives clear context: an agent should call this when it needs a connection to the local KOMPAS-3D application and a handle for subsequent operations. It does not enumerate exclusions or name alternatives, so it stops short of the explicit routing required for 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, the description must carry behavioral disclosure on its own. It does convey important operational details: entity_type is an o3d_ enum, how properties and calls are structured, the reference syntax, and the API5/API7 distinction. However, it does not disclose side effects on the document, failure behavior, return values, or prerequisites such as an open document, so the behavioral picture remains incomplete.
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 front-loaded: the main purpose appears in the first sentence, followed by dense but relevant clarifications for the most confusing aspects. Each sentence adds value, and the warning about API7 and SDK reading is placed at the end without bloating the definition.
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?
This is a complex tool with nested settings, references, and API-version caveats, and the description covers several of these well. Still, it intentionally defers to external SDK documentation and does not explain how an agent would discover valid entity_type values, property names, or member names. There is no output schema and no mention of return behavior or error conditions, leaving meaningful gaps for a tool this intricate.
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 for the schema's lack of parameter explanations. It does this well for the complex parameters: entity_type is described as an o3d_ enum, properties as mappings to writable names, calls as member/arguments/expect with optional via getters, and references with a concrete syntax. It does not explicitly explain document_id or name, but those are relatively self-evident from the schema.
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 states a specific action and resource: 'Create any API5 NewEntity-supported feature.' It further clarifies scope with concrete examples (shells, lofts, sweeps, ribs, drafts, patterns, mirrors) and distinguishes API7-only operations from this tool. It does not explicitly name sibling tools like create_part or create_sketch, but the resource scope is reasonably clear.
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 clear context for when to use the tool: when creating API5 NewEntity-supported features with documented definition settings. It also provides an exclusion: 'API7-only operations require api_cast/api_batch,' and advises consulting the SDK first. However, it does not explicitly contrast with siblings like create_part or update_feature, so the guidance is useful but not fully explicit about all alternative routes.
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 behavioral burden. 'Read' appropriately signals a non-mutating operation, but it does not disclose return shape, behavior when feature_id is omitted, or any limitations. This is adequate but 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 a single sentence with no filler or redundancy. The main verb, object, and optional scoping condition are all front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read operation, this is adequate but not complete. There is no output schema and the return value is not described, and the optional feature_id behavior is only implied by the word 'or' rather than explicitly stated.
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 does by mapping feature_id to 'a specific native feature' and implying that omitting it means user variables. document_id is not described, but its purpose is reasonably clear from the parameter name.
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 uses a clear verb ('Read') and identifies the resource: user variables or a native feature's driving variables and expressions. It does not explicitly distinguish itself from sibling tools like set_variable, but the read-vs-write contrast is implicitly clear.
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: use this tool to read variables, either at the user level or for a specific native feature. It does not state exclusions or name alternatives, so it misses the top score, but the intended usage is not left to inference.
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 transparency burden and does so well by disclosing units ('Geometry is mm'), coordinate frame ('local to the selected KOMPAS plane, not world XYZ'), and the support_entity_id alternative. It stops short of describing return values, document side effects, or error behavior, which prevents a top score.
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 compact and front-loaded, with the main capability in the first sentence and every subsequent sentence contributing distinct information (units, revolution prerequisite, coordinate frame, support entity). The revolution sentence is slightly disjointed but not wasteful.
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 captures key environmental constraints for a complex nested schema, including mm units, local coordinates, plane vs support_entity selection, and the revolution-axis requirement. However, there is no output schema and the description does not mention return/status behavior, angle units, or document mutation effects, leaving meaningful gaps for an agent.
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?
Since schema description coverage is 0%, the description compensates by explaining that coordinates/geometry are in mm and local to the plane, and that support_entity_id accepts a native face or construction plane instead of plane/offset. It does not describe document_id or arc angle units, but the added semantic context is substantial.
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 action ('Draw'), the resource (a KOMPAS sketch containing circles, arcs, and polylines), and the plane scope ('XY/XZ/YZ or offset planes'). It does not explicitly differentiate itself from sibling 2D draw_* tools, though the 'Sketch coordinates' and 'KOMPAS plane' phrasing make the CAD-sketch intent clear.
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 clear usage context: it explains that geometry is in mm, coordinates are local to the selected plane, support_entity_id can replace plane/offset selection, and revolution profiles need an open two-point construction polyline. It does not explicitly name alternative tools or state when-not-to-use, but the context is strong enough to guide an agent.
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 full burden. It usefully discloses supported input formats and that the tool returns a document ID, but it does not mention potential side effects, what happens on invalid paths, or whether import creates a new document versus opening an existing one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that leads with the primary action and supported formats, then states the return value. There is no redundant filler or repetition of schema information.
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 one-parameter tool this is reasonably complete, but the lack of annotations, output schema, and explicit relationship to sibling open/import tools leaves some gaps. An agent would benefit from knowing whether this is the right tool for opening existing documents by ID or only for loading files from disk.
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 a 'path' string with no description coverage. The tool description partially compensates by indicating the path should point to supported formats (M3D/A3D or STEP/IGES/STL). While it does not specify path resolution or format details, the single parameter is largely self-explanatory.
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 ('Open'/'import'), the target resource (native M3D/A3D or STEP/IGES/STL files), and the key output (an explicit document ID). This clearly distinguishes it from sibling tools like open_document, which likely operates on already-created documents rather than file paths.
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 the tool is for opening files from a path, and the format list ('M3D/A3D or STEP/IGES/STL') gives some context. However, it does not explicitly state when to choose this over open_document, create_document, or attach_active_model, nor does it mention any exclusions or prerequisites.
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 behavioral disclosure burden. It does add useful behavior: matching is case-insensitive and operates on substring input against installed SDK enums. However, it does not disclose the return format, whether values are also returned with names, or any edge-case behaviors such as empty results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core purpose and matching behavior. There is no redundant phrasing or unnecessary detail.
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 one string parameter and no output schema, the description provides adequate context to invoke it correctly: it names the search target and the matching rule. It could be slightly more complete by clarifying whether the result contains both names and values or just names, but this is a minor gap for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'query' parameter, and schema coverage is 0%, so the description must compensate. It does: 'query' is clearly a substring used for case-insensitive matching against enum names/values. This adds meaning beyond the bare parameter name, though it stops short of giving examples or format 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?
The description states a specific verb ('Find') and resource ('installed SDK enum names/values'), and adds a precise matching criterion ('case-insensitive substring'). This clearly distinguishes it from sibling tools like api_describe_interface and sdk_search, which target different resources or operations.
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 when the tool should be used: when an agent needs to discover enum names/values from the installed SDK via a substring. However, it does not explicitly mention when not to use it or name alternative tools, leaving some routing decisions to inference.
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 for behavioral disclosure. It explains the adoption action, the returned identity information, and advises verifying the returned identity. However, it does not describe potential state changes, failure modes, or whether a model must already be active, leaving some behavior 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 two sentences with no filler. The first sentence states the action and return values; the second provides the usage condition and a verification instruction. Every sentence 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?
For a zero-parameter tool with no output schema, the description covers the core concern completely: when to use it, what it does, and what it returns. It also advises verifying the returned identity, which adds practical guidance for the agent.
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 an empty input schema, so there is nothing for the description to explain about parameter semantics. This matches the baseline of 4 for no-parameter tools.
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 uses a specific verb ('adopt') and resource ('active 3D document'), and clearly states the tool returns the document's name/path and a stable session ID. It is distinct from sibling tools like open_model because it targets an already-open model, though it does not explicitly name alternatives.
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 'Use when the user requests work on an already-open model' gives a clear usage condition and distinguishes this from opening or creating documents. It does not explicitly mention when not to use it, but the context is sufficient for an agent to route correctly.
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 must carry behavioral context, and it does describe the output contents (identity, change state, read-only state, API7 handles). It does not explicitly state that the operation has no side effects or what errors may occur, but 'List' strongly implies a non-mutating query, so the disclosure is adequate if not exhaustive.
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 entire description is one tight, front-loaded sentence that names the action, scope, and return fields without filler. Every phrase 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?
For a zero-parameter, no-output-schema tool, the description is complete: it tells the agent what will be returned (identity, changed/read-only state, typed API7 handles) and what 'all' means ('open native documents'). No additional context is necessary to invoke it 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 tool takes zero parameters, so the schema is fully covered and the baseline for no-parameter tools applies. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') plus a precise resource ('all open native documents') and enumerates the returned data: identity, changed/read-only state, and typed API7 handles. This clearly distinguishes it from sibling document operations like create_document, open_document, save_document, and close_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List all open native documents' implies the tool is for enumerating currently open documents, but the description gives no explicit guidance on when to choose it over alternatives or any exclusions. For a simple read-only list tool this is acceptable but still leaves the decision to inference.
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 behavioral burden. It discloses ordered execution, early termination on first failure, partial results, side-effect persistence via 'No rollback,' and the authority equivalence to api_invoke. It does not describe the return/error shape, but the provided behavioral traits are substantive and non-obvious.
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?
Four compact sentences, each earning its place: core behavior, reference syntax, array syntax, expect semantics, and authority/risk. The main behavioral statement is front-loaded, and there is 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?
Given the nested ApiStep schema, no annotations, no output schema, and a large sibling list, the description covers the critical execution semantics, reference semantics, and side-effect behavior. Missing an explicit example or return/error shape, but the description is substantially complete for a tool of this complexity.
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%, and JsonValue is an empty definition, so the description must compensate. It does by explaining handle/ref/constant syntax, typed array variants, and the practical meaning of expect values. It does not elaborate on action or member semantics, but the most opaque parameter semantics are covered.
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 up to 100 ordered SDK steps; stop on first failure and return partial results.' This clearly distinguishes api_batch from single-step tools like api_invoke and other SDK operations.
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?
Usage context is implied rather than explicit. The description explains batch ordering and no-rollback behavior, and mentions 'same unrestricted local COM authority as api_invoke,' but it never explicitly states when to choose this tool over api_invoke or when not to use it. The expect guidance is parameter-focused, not tool-selection 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 creates documents and, more importantly, that it returns API7 handles rather than a document_id. This is meaningful transparency about output behavior, though it does not cover error cases, permissions, or the effect of the visible parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The action and resource are stated first, and the crucial API7/API5 distinction is front-loaded in the second sentence.
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 two-parameter tool with no output schema or annotations, the description provides the essential purpose, allowed kinds, alternate routing, and return type. The main missing context is the visible flag behavior, but the default and boolean name make it less critical.
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. It lists the allowed document kinds in prose, but these are already present as an enum in the schema, so it adds little. The visible parameter is never mentioned or explained, leaving a real semantic 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?
States a specific verb ('Create') and a clear resource ('native part, assembly, drawing, fragment, specification or text document'). It also distinguishes itself from the sibling create_part by mentioning the API7 handle output versus API5 document_id use case.
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?
Explicitly says to use create_part instead when a document_id for typed API5 modeling tools is needed. This gives an agent a direct routing rule: choose create_document when API7 handles are acceptable or needed, and choose create_part otherwise.
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 behavioral disclosure burden. It discloses an important limitation: session entities are only those created by typed tools, not the full feature tree, and it details the exact return format. This adds meaningful behavioral context beyond the tool name and schema.
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, front-loaded with the core return information, and every sentence contributes value. It packs the essential output format, scope limitation, and alternative usage into just three short sentences without 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?
Given there is no output schema, the description usefully provides the exact return tuple, entity IDs, and COM handles. It also covers the critical scope limitation and directs to api_invoke for existing topology. However, it does not clarify how document_id relates to the model or what 'typed tools' means, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter document_id is not explained in the description, and schema description coverage is 0%. The schema only provides the title 'Document Id', so the description adds no meaning beyond the raw parameter name. For low schema coverage, the description should compensate, but it does not.
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 ('Return') and resource ('bounding box, entity IDs and COM handles'). It also distinguishes itself from the alternative api_invoke by clarifying the scope of session entities versus existing model topology, making its 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: for session entities created by typed tools, not the full feature tree. It then directs the agent to use the part's EntityCollection through api_invoke for existing model topology, providing a clear alternative.
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 and does well: it explains crop normalization, recommends cropping before downsampling, caps output at 2400px, and explicitly states rendering only, with OCR/interpretation delegated to the client. No safety or failure behavior noted, but the tool is clearly a read operation by design.
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?
Four short sentences, each conveying a distinct fact: formats+page, crop format, resolution limit, rendering responsibility. No 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 simple read/convert tool with no output schema, the description covers input formats, page selection, crop behavior, output size cap, and the limit of its responsibility. It is complete enough for an agent to invoke correctly, though it does not specify the image return format (e.g., base64/URL).
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 has 0% description coverage, so the description compensates: it explains `crop` as normalized [left,top,right,bottom] in 0..1 and notes `page` is 1-based; `path` is implied to be a local file path by 'Read local ...'. This adds real meaning beyond 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?
States a specific action 'Read' and exact resource types (PNG/JPEG/TIFF/WebP, PDF page), with 1-based page indexing and output-as-image. This differentiates it from sibling CAD/API tools, and the final note clarifies it only renders, not interprets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use for reading local raster images or PDF pages as images. It does not name alternatives or exclusions, but the supported file types and rendering scope are unambiguous.
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 disclosure burden. It clearly signals destructive action, adds the dependent-object risk, and discloses an API quirk about silent owner deletion. This is meaningful beyond the schema, though error or undo behavior is not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with no filler. The main action, consequence, and limitation are each clearly presented, making the description scannable and 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 two-parameter destructive tool with no output schema, the description covers the target, selection requirement, dependency risk, and valid input restrictions. It does not explain behavior for nonexistent features beyond the face/edge/vertex case, but the essential context is 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%, but the description compensates by tying entity_id to an 'explicitly selected native feature' and excluding face/edge/vertex IDs. document_id is not elaborated, though its role is self-evident from the parameter name. This is adequate but not exhaustive.
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: 'Delete the explicitly selected native feature.' The qualifiers 'explicitly selected' and 'native' distinguish this from sibling create_feature and update_feature, and make the target object 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 establishes that this tool is for deleting an explicitly selected native feature and warns about dependent effects. It also provides a clear exclusion: face/edge/vertex deletion is rejected because API5 would silently delete the owner. It stops short of naming an alternative sibling for those cases, so it is not a 5.
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

kompas3d MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![kompas3d MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/hymaxo/kompas3d-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hymaxo/kompas3d-mcp)

Score Badge

Copy to your README.md:

[![kompas3d MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/hymaxo/kompas3d-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hymaxo/kompas3d-mcp)

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/hymaxo/kompas3d-mcp'

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