cadkit

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation5/5
Each tool has a clearly distinct purpose (e.g., cad_extrude vs cad_revolve, cad_find_edges vs cad_find_faces). Sketch tools are all prefixed with cad_sketch_ and address different operations (line, circle, arc, etc.). No ambiguity between tools.
Naming Consistency5/5
All tools use the consistent 'cad_' prefix followed by a verb_noun pattern in snake_case (e.g., cad_sketch_begin, cad_extrude, cad_delete_feature). No mixing of conventions.
Tool Count4/5
33 tools is on the higher side, but the domain (CAD modeling) justifies the number. Each tool serves a specific function, and the count is still manageable for an agent. Slight over-scoping in sketching (12 tools) but not excessive.
Completeness4/5
The toolkit covers the full CAD workflow: document/part studio creation, sketching with constraints/dimensions, 3D operations (extrude, revolve, fillet, hole, shell, mirror, pattern), measurement, variables, and export. Minor gaps like advanced assembly or referencing are absent but not critical for basic modeling.
Average 3.5/5 across 33 of 33 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 47 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 carries the full burden. It merely states 'delete' without disclosing irreversibility, impact on dependent features, permission requirements, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly terse. While concise in word count, it fails to provide necessary context for a destructive tool, making it under-specified.
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?
Given the tool's complexity (4 required params, no output schema, no annotations), the description is severely incomplete. It does not explain what happens upon deletion or how to interpret results.
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 coverage is 0%. The description only mentions featureId, but there are 4 required parameters. It adds no meaning beyond 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 clearly states the action (delete) and the resource (feature) with a specific identifier (featureId). It distinguishes from siblings like cad_suppress, but could be more specific about scope or side effects.
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 like cad_suppress or cad_edit_feature. Missing prerequisites or context for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the operation types (NEW/ADD/REMOVE/INTERSECT) and depth format, but fails to mention behavioral traits like modification of the document, required sketch state (closed), side effects, or error conditions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal (two sentences) and front-loads the core purpose. It avoids redundancy but could be better structured by listing parameters. Overall, it is appropriately concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description lacks crucial context: return value, synchronous/asynchronous behavior, prerequisites (e.g., existing sketch), and failure modes. It is not complete enough for reliable agent usage.
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 explains 'operation' and 'depth' meanings but does not clarify the roles of documentId, workspaceId, elementId, sketchFeatureId, or name. Only 2 of 7 parameters gain context, leaving significant gaps.
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 'Extrude a sketch region' with a specific verb and resource. The operation enum and depth format add detail. However, it does not differentiate from sibling tools like cad_revolve, leaving some ambiguity about when to use this specific extrusion tool.
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 (e.g., cad_revolve for rotational extrusions). No conditions, prerequisites, or exclusions are mentioned, leaving the agent to infer usage from the bare purpose.
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 full burden for behavioral disclosure. It only mentions that it returns elementId, omitting any side effects, authorization needs, or constraints (e.g., whether it overwrites existing elements or creates new ones).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At 5 words in a single sentence, it is extremely concise but at the expense of completeness. It earns its place but lacks structure and crucial 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?
The tool has 4 parameters (3 required), no output schema, and no annotations. The description fails to explain the purpose of Part Studio, the role of each parameter, or return value structure. Agents likely misunderstand usage.
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 coverage is 0%, and the description adds no meaning beyond the raw parameter names. It fails to explain the purpose of 'elementId' (is it an existing element to modify or a new ID?), or constraints on 'name'. This leaves the agent guessing.
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 explicitly states 'Create a Part Studio; returns elementId.' It uses a specific verb ('Create') and resource ('Part Studio'), distinguishing it from sibling tools like cad_document_create (creates a document) or cad_sketch_begin (starts a sketch).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or limitations. The description merely states what it does without contextual usage hints.
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 exist, so the description must carry the burden. It only reveals the return value but omits side effects (e.g., mutation), permissions, idempotency, or error conditions. For a creation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, no superfluous words. It is efficient but could be slightly more structured with clarity on 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?
With 2 parameters (one required), no output schema, and many sibling tools, the description lacks detail about parameter usage and return value structure. It is too minimal for a creation tool.
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%. The description adds no meaning to the parameters 'name' or 'description'. It does not explain format, constraints, or purpose beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (document), and specifies the return value (documentId + Main workspaceId). It distinguishes from sibling tools like cad_part_studio_create which creates a different resource.
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 like cad_part_studio_create. No prerequisites or context provided.
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?
Annotations are absent, so description carries full burden. It mentions 'Returns the translation result' but does not clarify if the operation is synchronous or asynchronous, nor any side effects. Minimal disclosure about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The first sets the action, the second provides format and parameter info. Could be better structured (e.g., list format values separately), but efficient overall.
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 5 parameters, 3 required, no output schema, and no annotations, the description is incomplete. It does not explain the output format of 'translation result', error conditions, or execution model (sync/async). Leaves important gaps for an export tool.
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 description must explain parameters. It explains 'format' (lists allowed values and default) and 'partId' (optional, exports single part), but the three required parameters (documentId, workspaceId, elementId) are not described, leaving ambiguity.
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 verb 'Export' and the resource 'part studio', and lists supported file formats with a default. It differentiates from siblings as the only export tool, but could be more explicit about what 'export' entails (e.g., triggers a download).
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?
No explicit guidance on when to use this tool versus alternatives. Since there are no competing export tools in siblings, it is the sole option. However, prerequisites (e.g., need a part studio) are implied but not 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?
No annotations are provided, so the description must disclose behavioral traits. It only mentions the operation but doesn't state if it's destructive, permissions needed, or side effects. The radius format note is helpful but insufficient.
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 that is front-loaded with the action and key details. It is appropriately sized without unnecessary words, but could include more structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of six parameters (five required) and no output schema, the description is incomplete. It fails to explain many input parameters and does not describe return values or error 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?
Only two parameters (edgeIds, radius) are explained in the description out of six. The schema has no descriptions, so the description must cover more. It adds meaning for radius (inches/expression) and edgeIds (deterministic ids) but neglects documentId, workspaceId, elementId, and 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 clearly states the tool fillets edges and references deterministic ids from cad_find_edges, distinguishing it from sibling tools like cad_chamfer and cad_sketch_fillet. However, it doesn't explicitly mention that it's for 3D parts, which could be inferred from context.
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?
It gives guidance that edge ids should come from cad_find_edges and radius can be a number or expression, but it doesn't specify when to use versus alternatives like chamfer or when not to use.
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 must fully disclose behavioral traits. It only says 'Returns deterministic ids', but does not state whether the tool is read-only, requires authorization, or has side effects. For a 'find' operation it is likely safe, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single paragraph with embedded explanations. It front-loads the main purpose and then lists variants. Slight room for improvement by breaking into clearer sentences or bullet points.
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 complex with 10 parameters and multiple kind options. The description covers each kind and its relevant parameters reasonably well. However, it lacks explanation of the return format, error handling, and the meaning of 'deterministic ids'. Given no output schema, more detail would be useful.
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?
Since schema description coverage is 0%, the description is crucial. It explains the 'kind' enum and parameters like normal, radius, tolerance, axis, coordinate, max with examples. However, it omits the required parameters documentId, workspaceId, and elementId entirely, leaving their purpose unstated.
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 'Find faces by geometry' which is a specific verb+resource. It lists various kinds (planar_by_normal, cylindrical, etc.) with examples, making the purpose clear. However, it doesn't explicitly differentiate from sibling tools like cad_find_edges, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, context, or when not to use it. Sibling tools like cad_find_edges or cad_sketch_* are not referenced, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions wall direction is inward. Does not disclose behavior for invalid faces, negative thickness, or whether operation modifies original.
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?
Single sentence, concise, front-loads purpose. Could benefit from more structure to separate parameter info, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complex CAD shell operation with no output schema, no annotations, and 6 parameters (5 required). Description lacks depth on behavior when thickness exceeds solid, face selection rules, or return value.
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?
Only thickness is described (inches or variable). FaceIds are vaguely 'given faces'. Other parameters like documentId, workspaceId, elementId, name have no description. Schema coverage is 0%, so description falls short.
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 verb 'Hollow' and resource 'the solid' are clear. 'Removing the given faces and leaving a wall' distinguishes it from other CAD tools like extrude or chamfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. No prerequisites (e.g., solid must be a closed volume) or when-not-to-use mentioned.
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 must fully disclose behavior. It states the tool adds a circle and returns entityId, but does not explain side effects (e.g., whether the circle is added to an active sketch, if any sketch must be started first) or constraints (e.g., coordinate system, units). The behavioral contract is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. It front-loads the primary action and return value. However, the conciseness sacrifices completeness, but as a single dimension it is well-structured.
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 4 parameters and no output schema or annotations, the description lacks essential context. It does not explain the required sessionId parameter, nor does it specify coordinate systems, units, or the requirement of an active sketch. The description is too sparse to fully inform 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 clarify parameters. It adds meaning to 'construction' (reference circle), but sessionId is unexplained, center and radius are only implied by their type. The description does not fully compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a circle, which is a specific verb and resource. It differentiates from sibling tools like cad_sketch_line or cad_sketch_arc. It also mentions the return value (entityId), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to use a circle vs. an arc or other sketch primitives). There is no mention of prerequisites or context, so usage decisions are left entirely to the agent.
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 must fully disclose behavior. It mentions operation types but omits critical details like error conditions, authorization needs, or whether the feature is created or modified. The return format is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) but could be better structured. It front-loads the main action but mixes the angle note with operation enum in a run-on format. It is efficient but lacks clarity on parameter grouping.
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 8 parameters, no output schema, and no annotations, the description is too brief. It does not explain required parameters (e.g., axisId, sketchFeatureId) or the overall workflow. The tool is moderately complex, and the description leaves significant 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?
With 0% schema description coverage, the description must explain all parameters. It only covers angle and operation partially, leaving documentId, workspaceId, elementId, sketchFeatureId, axisId, and name unexplained. This is insufficient for autonomous agent use.
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 'Revolve a sketch region about an axis edge', which is a specific verb and resource. It distinguishes from sibling tools like cad_extrude and cad_chamfer by focusing on rotational 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 provides some usage hints like angle options and operation types, but lacks explicit when-to-use vs alternatives such as extrude or mirror. It does not specify prerequisites like sketch closure or axis intersection.
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 partially compensates by revealing the return value structure (entityId.start/end). However, it does not mention side effects, authentication, or rate limits.
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?
Single sentence with no fluff. Front-loaded with the main action and key return detail.
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?
Lacks context about coordinate system, units, relationship to current sketch, error handling, and the optional 'construction' parameter. Minimal for a CAD tool.
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 does not explain any parameters (start, end, construction, sessionId). It only mentions 'points' in the return value, not the input coordinates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a line') and the resource, and specifies the return value format (entityId with start/end points). It distinguishes from sibling tools like cad_sketch_rectangle or cad_sketch_circle.
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 (e.g., polyline, rectangle). No mention of prerequisites or context like needing an active sketch.
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 provided, so description carries full burden. It mentions equal-distance behavior and deterministic IDs but fails to disclose destructive nature, required permissions, error conditions, or impact on the document.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no extraneous text. Front-loaded with core purpose and key usage detail (edge IDs, distance format).
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?
Covers basic purpose and critical parameter semantics, but lacking output description, behavior on failure, prerequisite element state, and details for optional parameters. Adequate for a simple tool but incomplete.
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?
Description explains distance parameter (inches, expression/variable) and source of edgeIds, but does not clarify documentId, workspaceId, elementId, or name. With 0% schema coverage, this is partial but helpful.
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 clearly identifies it as an equal-distance chamfer on edges, and mentions deterministic edge IDs from cad_find_edges. However, it does not explicitly differentiate from similar tools like cad_fillet, leaving potential ambiguity.
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?
Implies usage via cad_find_edges for edge IDs and notes distance units, but lacks explicit guidance on when to use this tool versus alternatives like cad_fillet, and no when-not-to-use instructions.
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 provided, so description must convey behavioral traits. Describes mutation (edit) but omits side effects, reversibility, error handling, or required permissions. Only basic operation description.
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 sentences, concise and direct. First sentence states action and inputs, second highlights key capability. No fluff, though slightly dense and could be clearer about mutual exclusivity of expression/value.
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?
No output schema and no description of return values, prerequisites, or side effects. For a tool with 7 parameters, the description is incomplete, focusing only on core editing functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains parameterId with examples and distinguishes expression vs value. However, it does not describe documentId, workspaceId, elementId, or featureId, leaving significant gaps. Adds some value but incomplete.
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?
Clearly states verb 'edit' and resource 'stored parameter of an existing feature'. Provides specific examples of parameterId (depth, radius, length) and distinguishes from siblings like cad_set_variable by mentioning retargeting to a variable without rebuilding.
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?
Implies usage for editing a single feature parameter and retargeting to a variable, but lacks explicit when/when-not guidance or contrast with sibling tools like cad_set_variable or cad_extrude. No prerequisites or exclusions mentioned.
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 discloses behavioral details: operation matches seed feature and defaults accordingly. It explains planeId flexibility. However, it omits potential effects like whether original features are retained, permissions needed, or parametric behavior.
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 two sentences, efficient and to the point. It front-loads the core purpose and explains key parameters. Slightly more structure (e.g., listing parameters in order) would improve readability.
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 output schema, no annotations, and 7 parameters with 0% schema descriptions, the description covers only a few parameters and lacks details on return values, prerequisites, error handling, or side effects. For a mirroring tool with moderate complexity, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to featureIds, planeId, and operation (including enum guidance). However, it does not explain documentId, workspaceId, elementId, name, or the ADD/INTERSECT enum options. Since schema coverage is 0%, the description partially compensates but leaves significant gaps.
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 ('Mirror whole features across a plane') and explains key parameters (featureIds, planeId, operation). It implicitly distinguishes from sibling tools like cad_sketch_mirror by specifying 'whole features', but 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 provides usage context for the operation parameter (default NEW for additive, REMOVE for cuts) and notes that planeId can be standard planes or a face/plane id. However, it does not explicitly guide when to use this tool versus alternatives like cad_pattern or cad_sketch_mirror.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the rectangle is 'constrained' and returns line IDs, but does not disclose side effects (e.g., whether it modifies existing geometry) or requirements (e.g., active sketch). Minimal but not misleading.
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 waste. However, it could be slightly expanded without losing conciseness to address missing context.
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 tool with 3 parameters and no output schema, the description is partially complete. It specifies the return format but omits crucial context like the need for an active sketch (suggested by sibling tools like cad_sketch_begin). The behavioral transparency and guidelines gaps reduce completeness.
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?
With 0% schema description coverage, the description does not explain the meaning of corner1 and corner2 beyond being arrays. It fails to clarify they are 2D points or the rectangle orientation. This leaves ambiguity despite the simple parameter structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'a constrained rectangle', distinguishing it from sibling sketch tools like cad_sketch_line or cad_sketch_circle. The return format is also specified.
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 (e.g., cad_sketch_polyline for unconstrained rectangles). No mention of prerequisites like an active sketch.
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 must disclose behavioral traits. It mentions efficiency but does not explicitly state whether the tool is read-only, what happens with empty part studios, or any required permissions. The measurement nature implies safety, but not explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with essential information, and contains no superfluous text. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's outputs and efficiency, but lacks parameter explanations and explicit behavioral disclosure. Given the tool's simplicity, it is mostly complete but has gaps that could hinder correct usage.
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 three required parameters with zero description coverage, and the tool description does not explain what documentId, workspaceId, or elementId refer to. It only mentions the 'part studio' context, which partially hints at elementId, but is insufficient for the agent to map parameters correctly.
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 measures solids in a part studio, returning solid count, total volume in cubic inches, and bounding box dimensions. It specifies it does this in one FeatureScript eval, making it distinct from sibling tools which perform modifications or other analyses.
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 efficient use via 'ONE FeatureScript eval' and 'Quota-frugal', but does not explicitly state when to use this tool over alternatives or provide exclusion criteria.
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?
Discloses that the feature remains in the tree, but lacks details on side effects (e.g., impact on downstream features) and permissions, especially with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant information, appropriately front-loaded.
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 5 required parameters, no output schema, and no annotations, the description omits crucial context like reversibility, prerequisites, and behavior when already suppressed.
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?
Only clarifies 'featureId' and 'suppressed' from the five required parameters; documentId, workspaceId, elementId are unexplained despite 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (suppress/unsuppress) on a specific resource (feature by featureId) and the effect (leaves it in the tree), distinguishing from deletion.
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?
Implies toggling visibility without removal, but no explicit when-to-use or comparison with sibling tools like cad_delete_feature or cad_edit_feature.
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 were provided, so the description must disclose behavioral traits. It explains the types of constraints and the special case for ground_origin, but does not mention side effects on existing constraints, required active sketch, or return behavior.
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 three sentences and covers essential information without unnecessary fluff. It is front-loaded with the core action. However, slight improvement could be made by separating the ground_origin special case more clearly.
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 the tool's complexity (5 parameters, no output schema), the description covers types and parameter formats but omits the sessionId purpose, required fields beyond 'type', and return values. Adequate for basic use but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so by listing valid 'type' values, explaining the format for 'a', 'b', and 'c' parameters, and describing the ground_origin behavior. Adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a geometric constraint' with a specific list of constraint types, and explains the format of entity IDs. It distinguishes the tool from sibling sketch tools by focusing solely on constraints.
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 other sketch tools (e.g., line, dimension) or any prerequisites like having an active sketch. No alternative tools are mentioned.
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?
Without annotations, the description fully discloses side effects: trimming lines, dropping corner coincident, inserting arc, adding tangent constraints. It also specifies return value. Minor omission: no mention of assumptions like lines must intersect.
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, highly efficient, front-loaded with action, no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core behavior and return value, but lacks detail on parameter semantics, error conditions, and limitations. With 4 unannotated parameters and no output schema, more completeness is expected.
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?
With 0% schema description coverage, the description should explain all parameters. Only 'radius' is explained (unit inches). 'sessionId', 'line1', 'line2' remain opaque; the description does not clarify that line1 and line2 are line entity IDs.
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 rounds a corner where two lines meet with a tangent arc, specifying the resource (corner of two lines) and action (round) uniquely among sibling tools like cad_fillet (3D edges).
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 (e.g., cad_chamfer or cad_fillet). The description only explains what it does, not the 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?
With no annotations, the description mentions returning a sessionId and implies a state change, but lacks details on side effects, permissions, or lifecycle of the session.
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 concise sentences with front-loaded key information, no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (3 required), no output schema, and no annotations, the description is insufficient; it fails to explain required identifiers or the session's scope.
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?
Only two of six parameters (plane and face) are explained; the required documentId, workspaceId, and elementId are not described, and the optional name is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (open a sketch session) and the target (standard plane or existing face), distinguishing it from sibling sketch tools like cad_sketch_line which operate within an existing sketch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains two usage modes (plane vs. face) and provides a source for the face id, but does not explicitly state when not to use this tool or mention prerequisites like having a valid element.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is a read operation ('reads the assignVariable features') and highlights it makes a single API call, implying efficiency. It does not mention side effects, but as a read-only tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and an example. Every sentence adds value: first defines action, second adds implementation detail and efficiency. No wasted words.
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 provides an example and mentions the return format (name + expression) and a single API call, but lacks details on output structure, error cases, or prerequisites. No output schema exists, so more detail would be helpful, but for a simple list tool it is minimally adequate.
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?
Input schema has 0% coverage (no parameter descriptions). The description does not explain the three required parameters (documentId, workspaceId, elementId), only implying elementId refers to the part studio. With no schema descriptions, the description should clarify parameter meanings but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists CADkit variables in a part studio, providing the name and authored expression with an example. It specifies the verb 'List' and the resource 'cadkit variables in this part studio', distinguishing it from sibling tools like cad_set_variable.
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 for reading variables but does not explicitly state when to use or when not to use, nor does it mention alternatives. The context from sibling tools suggests cad_set_variable for writing, but no direct guidance is given.
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?
Discloses update-or-create behavior and expression format with examples, which goes beyond basic description. No annotations provided, so description carries full burden; it covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action, no superfluous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior and parameter use for expression, but missing parameter descriptions for IDs and name. Adequate for a tool with no output schema or annotations, but not fully 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?
Only the 'expression' parameter is partially described with an example. Other required parameters (documentId, workspaceId, elementId, name) are not explained, and schema coverage is 0%.
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?
Clearly states 'Set a part-studio variable' and distinguishes from sibling tools like cad_get_variables. Provides specific action and resource, with update-or-create behavior.
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?
Implied usage for setting variables, but no explicit when-to-use or when-not-to-use compared to alternatives. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that reflected copies are emitted, a MIRROR constraint is added, and the return format. This is good but could mention if original lines are unmodified 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 three sentences with no wasted words. The first sentence defines the action, the second adds constraints and return, and the third sets scope. Perfectly front-loaded and concise.
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 three parameters, no output schema, and no annotations, the description covers the core behavior, constraints, and return value. It lacks parameter details but is otherwise complete for a sketch tool where sessionId is standard.
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 adds no meaning to the individual parameters 'sessionId', 'entityIds', or 'axis'. It does not explain their format, domain, or purpose beyond the implied axis type.
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 it mirrors sketch lines across an existing line entity (the axis), specifies the result (reflected copies and MIRROR constraint), and notes it works on lines only. This distinguishes it from sibling tool cad_mirror which likely mirrors 3D bodies.
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: mirror sketch lines across a line axis. It notes 'Lines only for now,' implying not for other entities. However, it does not explicitly mention alternatives or when not to use, leaving some ambiguity.
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 'Copies are geometric (not a live-linked pattern)' and states the return format '{originalId: [copyIds...]}'. This goes beyond the schema, but it does not mention potential side effects like permission requirements or whether the operation is reversible.
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 (4 sentences) and well-structured, front-loading the purpose then detailing each kind. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description covers the core pattern logic and return format. However, it omits guidance on entityIds (presumably sketch entities) and sessionId, and does not address error cases or prerequisites. It is adequate but has clear gaps 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.
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 add meaning. It explains the context for direction, spacing, center, and angle, and clarifies that count includes the original. However, it does not describe the required parameters sessionId or entityIds (which are likely standard but should be mentioned for clarity). This leaves a gap for new users.
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 it repeats sketch lines/circles as geometric copies, specifying the resource and action. It mentions two kinds (linear, circular) but does not explicitly distinguish it from sibling tools like cad_pattern (for 3D patterns) or cad_sketch_mirror, which slightly reduces differentiation.
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 explicit usage guidance for each kind: 'kind=linear needs direction=[dx,dy] + spacing (inches between instances); kind=circular needs center=[cx,cy] + angle (degrees between instances)'. It also explains that count includes the original. However, it does not specify when not to use this tool or mention alternatives, missing a clear exclusion clause.
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 must carry the full burden. It mentions that extruding unions the elements into a clean slot and returns {sides, caps} ids, but does not disclose potential behavior like coordinate system, units, or prerequisites.
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. The main action is front-loaded, and the return value is clearly stated.
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, the description covers the return type. However, it lacks details on coordinate units, error handling, and prerequisites. For a tool with 4 required parameters, more context would be helpful.
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, but the description explains the key parameters: two centre points (center1, center2) and width. It adds meaning beyond the raw schema, though sessionId is not explained.
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 explicitly states the tool adds an obround (rounded slot) between two centre points with a given width, using specific CAD terminology. It clearly distinguishes from sibling sketch tools like cad_sketch_circle or cad_sketch_rectangle.
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?
No explicit when-to-use or when-not-to-use guidance is provided. While the purpose is clear, the description does not help the agent decide between this tool and other sketch primitives in ambiguous cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses behavioral details such as the default angle (360), and warns that NEW operation for cuts 'leaks a stray body'. It explains operation matching seed features, adding valuable transparency beyond basic purpose.
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 dense paragraph that front-loads the main purpose and uses semicolons to separate clauses. It is concise without losing clarity, though bullet points could improve readability.
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 the tool's complexity (12 parameters, no output schema, no annotations), the description covers the key parameters and behaviors but omits documentation for common parameters like documentId, workspaceId, elementId, and name. It also does not explain return values or error conditions.
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 add meaning. It explains relationships between kind, directionId/axisId, spacing/angle, count, and operation. However, many parameters (documentId, workspaceId, elementId, name, featureIds, angle) are not described individually, leaving gaps.
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 patterns whole features and distinguishes between linear and circular patterns, specifying required parameters for each. It differentiates from sibling tool 'cad_sketch_pattern' which is for sketch patterns.
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 explicit conditions for each pattern kind (kind=linear needs directionId+spacing+count; kind=circular needs axisId+count+angle). It also advises on operation selection: NEW for additive bosses, REMOVE for hole/cut patterns. However, it does not mention when not to use the tool or alternatives.
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, and the description lacks disclosure of behavioral traits such as whether the tool mutates the sketch, what prerequisites are needed (e.g., an active sketch), error scenarios, or if it is idempotent. The phrase 'driving dimension' implies constraint, but more context is needed.
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 that front-loads the key purpose and immediately provides usage details in parentheses. Every word adds value, with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers most parameters and core behavior. It lacks explanation of the return value (e.g., what the tool returns after adding a dimension) and does not describe 'sessionId'. Overall, it is fairly complete for a dimension-adding 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 description adds significant meaning beyond the schema by explaining the 'kind' enum options, how 'entity' and 'entity2' are used (e.g., distance requires two entities), and the format of 'value' (inches or expression). However, 'sessionId' is not mentioned, and 'entity' IDs are not explained.
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 'Add a driving dimension' and explains the different kinds (length, radius, etc.). It distinguishes the tool from siblings like cad_sketch_line or cad_sketch_circle by focusing specifically on dimensions.
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 explicit guidance on which kind to use for different geometry types (line, circle, etc.) and explains value formats. However, it does not mention when not to use this tool or offer alternatives, such as using a reference dimension or constraints.
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 full burden. It mentions 'Returns deterministic ids' but does not explicitly state read-only behavior, authentication needs, or side effects. Since the name implies read-only, it is adequate but not fully detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, but it is a single paragraph without bullet points or clear separation of inputs. Every sentence adds value, but better structure could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 6 kinds, no output schema), the description is remarkably complete, covering each kind's behavior and key parameter usage. It also notes the return type (deterministic ids) and distinguishes from 31 sibling tools.
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?
Despite 0% schema description coverage, the description adds meaning to the 'kind' parameter and explains how other parameters (radius, tolerance, axis, max, coordinate) relate to each kind. For example, 'circular (radius+tol)' and 'extreme... axis=Z max=false'. Some parameters like 'through' are only briefly mentioned.
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 finds edges by geometry and enumerates six specific kinds (circular, concave, convex, linear, extreme, on_plane) with brief explanations, distinguishing it from sibling tools like cad_fillet or cad_chamfer.
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 explicit guidance for each kind (e.g., 'concave is ideal for fillets', 'extreme... to fillet at once'), implying when to use each variant. However, it does not explicitly state when not to use this tool or compare it to alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full transparency burden. It discloses that the sketch is posted as a feature and that require_well_formed can prevent posting. However, it does not mention side effects (e.g., document modification) or potential error conditions, which is a gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first covers main purpose and output, second covers optional parameter. No wasted words, efficient and clear.
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 that the tool has only two parameters and no output schema, the description adequately covers key aspects. It could mention error handling or prerequisites (e.g., an active sketch), but is largely sufficient for simple tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the require_well_formed parameter (well-formed check) and implicitly covers sessionId by context. This adds value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('post the sketch as one feature') and what it returns (featureId plus diagnostics). It distinguishes itself from other sketching tools (e.g., sketch_line, sketch_constrain) by being the finalization step.
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 explicit guidance on the require_well_formed parameter ('Set require_well_formed=true to refuse...'). It implies this tool is used after a sketch is created, but does not explicitly compare to alternatives like cad_sketch_begin or cad_sketch_line, leaving some ambiguity for the agent.
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?
Discloses auto coincident-joins, closed loop, auto_hv constraints, and ground_first behavior. Returns line ids. No annotations provided, so description carries burden. Missing context on sketch state 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?
Three concise sentences: overall action, options, return value. No redundancy. Front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and all boolean options. Missing details on sketch context (e.g., whether sketch must be active), error cases, or interaction with existing sketch entities. Adequate for a sketch 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?
Explains points array, closed, auto_hv, and ground_first with specific meanings beyond schema (e.g., 'closes the loop', 'applies horizontal/vertical'). schema coverage 0%, so description compensates well, except sessionId is not explained (likely understood from context).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it adds a chain of lines through points, distinguishing it from single line (cad_sketch_line) and other sketch tools. The verb 'Add' and resource 'chain of lines' are specific.
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?
Implies usage for multiple connected lines, but does not explicitly compare to siblings like cad_sketch_line or cad_sketch_rectangle, nor when not to use it. No alternatives mentioned.
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?
Describes geometric behavior (counterclockwise sweep, radius set by start, end snaps to radius) and construction mode, but does not mention prerequisites like active sketch.
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?
Single sentence with clear, front-loaded purpose and no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return value and parameter behavior; missing only sessionId context and edge cases, but adequate given sibling tool consistency.
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?
Adds meaning to center, start, end, and construction parameters beyond schema; explains radius derivation and return value access. SessionId is standard and not described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it adds a center-point arc swept counterclockwise from start to end, returns entityId, and distinguishes from other sketch tools by specifying geometry behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on using swap start/end for complementary arc and construction flag for reference arcs, but does not explicitly state when not to use.
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?
The description discloses that the call costs no API request, counts only successful calls (2xx/3xx), and relates to a 2,500/user/yr budget, providing useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load key information: what it reports, the counting criteria, cost, and usage context. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, usage timing, and behavioral implications, leaving no gaps despite the absence of output schema or annotations.
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?
With no parameters and 100% schema coverage, the description does not need to add parameter details; it correctly focuses on the tool's purpose and behavior.
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 reports the count of successful Onshape API calls made in the session, distinguishing it from all sibling CAD tools that perform geometric operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises checking before/after live work to monitor quota usage, though it does not mention situations where this tool should not be used or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses that counterbore/countersink use native Hole feature, 'up' flips drill direction, and depth accepts numbers or variables. Does not detail return values or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with core purpose, then details styles and options. Compact but not terse; each sentence adds value. Could be slightly more structured but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, 7 required, and no output schema, the description covers all essential aspects: required params, styles, special behaviors (up, through). Complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates fully. It explains all key parameters: plane as Front/Top/Right or face id, center format, diameter/depth accepting variables, style options with sub-parameters, and boolean flags.
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 it creates holes at given centers on a plane/face, with specific verb 'Hole(s) at the given centers'. It distinguishes from siblings like chamfer, fillet, extrude by being a hole creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use different styles (simple, counterbore, countersink) and options like 'up' and 'through'. It does not explicitly state when not to use or name alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![cadkit-mcp MCP server](https://glama.ai/mcp/servers/saltyeg/cadkit-mcp/badges/card.svg)](https://glama.ai/mcp/servers/saltyeg/cadkit-mcp)

Score Badge

Copy to your README.md:

[![cadkit-mcp MCP server](https://glama.ai/mcp/servers/saltyeg/cadkit-mcp/badges/score.svg)](https://glama.ai/mcp/servers/saltyeg/cadkit-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/saltyeg/cadkit-mcp'

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