root-ext-cad

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool has a clearly distinct purpose: model_inspect summarizes, model_validate checks manufacturability, model_build executes scripts, model_mesh tessellates, model_diff compares, drawing_project projects to 2D, text_to_cad generates from text, and the calc_* tools cover specific engineering calculations with no overlap.
Naming Consistency4/5
Tool names consistently use a verb_noun pattern with model_ and calc_ prefixes. Minor deviations: drawing_project uses noun_verb, and text_to_cad uses a different form, but they are still clear and fit the overall scheme.
Tool Count5/5
11 tools is well-scoped for a CAD server covering both model operations and engineering calculations. Each tool serves a specific need without being overwhelming or too sparse.
Completeness4/5
Covers core CAD workflows: inspect, validate, build, mesh, diff, project, and text generation. Calculation tools cover common mechanical engineering needs. Minor gaps like direct export to common formats or more advanced analysis, but overall complete for its stated purpose.
Average 4.2/5 across 11 of 11 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so no side effects exist. The description adds context about the friction coefficient (K) and torque formula, noting that lubrication changes K dramatically, which is valuable beyond the annotation-only info.
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 a single sentence that packs many outputs, making it dense. It lacks front-loading or structure (e.g., bullet points) that would improve readability for an agent.
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?
No output schema exists, so the description must convey return format. It lists several computed values (pitch, area, clearance holes, etc.), but does not present them as structured keys or explain the exact output object, leaving gaps.
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%, but the description adds meaning to friction_k (default 0.2 dry, lubrication effect) and property_class (proof stress). size_m is implied by the range but not explicitly described, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific purpose: computing metric coarse-thread fastener numbers for a size range (M1.6–M30). It lists discrete outputs (pitch, tensile stress area, etc.), distinguishing it from sibling calculation tools like calc_fits or calc_beam.
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 versus alternatives is provided. The domain is implied through the list of outputs, but there is no comparison with siblings or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds valuable context: that the tool works on geometry (not feature trees) and that reshaped bodies are reported as removed+added. This extra behavioral detail helps the agent understand limitations beyond the annotation's safety flag.
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 long, front-loaded with the core purpose, and adds only essential clarifications. Every sentence adds value without 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?
The description explains the tool's outputs and limitations well, but lacks details on parameter semantics and return format (no output schema). For a tool with two required parameters and no output schema, more completeness would be beneficial, but the description covers the core functionality adequately.
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 two parameters (path_a, path_b) have 0% schema description coverage. The description mentions 'Two B-rep revisions (STEP/BREP/IGES)' but does not explicitly describe the parameters' meaning, format, or constraints (e.g., local vs URL, file extension requirements). More parameter-level guidance is needed to 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 computes a geometric diff of two B-rep revisions and lists specific outputs (volume, area, bbox deltas, per-body matching). It distinguishes itself from a feature tree diff and implicitly from sibling tools like model_inspect (which inspects a single model) by specifying the diffing functionality.
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 geometric comparison of B-rep files and clarifies it is not for feature tree diffs, but it does not explicitly state when to use this tool over siblings like model_inspect or model_validate. No direct exclusions or alternative tool names are given, 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?
Annotations already declare readOnlyHint=true, so the description adds context: it computes from standard formulas, returns specific outputs (deviations in µm, clearance, fit type), and advises verification against ISO 286-2 tables. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and key constraints. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's engineering complexity, no output schema, and three parameters, the description adequately explains what the tool computes and returns, mentions the standard basis, and includes a verification caution. It covers essential context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must compensate. It explains valid ranges for hole (H5–H11) and shaft letters (d e f g h js k m n p s) but does not detail default values or format. It provides some semantic context beyond the schema but is not comprehensive for all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes ISO 286 limits and fits for hole-basis subset, specifying hole grades H5–H11, shaft letters, size range to 500 mm, and outputs deviations, clearance, and fit type. This specific verb-resource combination distinguishes it from sibling tools like calc_beam or calc_fastener.
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 hole-basis fits but does not explicitly state when to use vs. alternatives or provide exclusions. It mentions verifying critical fits against official tables, but no guidance on when not to use this tool or mention of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only (readOnlyHint=true). The description adds value by detailing the outputs (I, deflection, moment, stress, safety factor) and the mathematical model used (Euler-Bernoulli), as well as limitations (no shear, buckling). This provides behavioral context beyond what annotations offer.
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 (three sentences) and front-loaded with core purpose. It packs significant detail but lacks bullet points or clear separation of input/output sections, which marginally reduces readability. Still, it is efficient without 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 the complexity (8 parameters, nested objects, no output schema), the description covers the main inputs, supported cases and sections, units, and outputs. It mentions the return values. However, it does not include an example or explicitly map dims_mm keys for each section type, which would enhance completeness.
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?
With 0% schema description coverage, the description compensates partly by explaining case types, section geometries, units, and the default E value. However, it does not explicitly describe all parameters (e.g., load_n, udl_n_mm) or clarify that dims_mm keys depend on the section type. The explanation is helpful 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?
The description clearly states it performs Euler-Bernoulli beam bending analysis for first-cut design. It lists supported cases (cantilever_point, etc.) and section types (rect, round, tube), making it distinct from sibling tools like calc_fits or calc_fastener. The explicit mention of what it does not include further differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use this tool for simple beam bending and explicitly excludes shear deflection, buckling, and stress concentration, implying those are not computed. However, it does not explicitly state 'use this for first-cut estimates' or mention alternative tools for advanced cases, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations that already indicate idempotency and non-destructiveness, the description adds rich behavioral context: it details the subprocess execution, CPU and timeout limits, default export formats, directory constraints ('never a directory containing the script itself'), and the return of a build report. No contradictions with annotations.
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 sentence that packs significant information. It is front-loaded with the primary action. While every part is relevant, the density slightly harms readability. Breaking into multiple sentences would improve structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing scripts, exporting, subprocess management), the description covers the core workflow, safety constraints, and return value. It could mention error handling or script failure behavior, but overall it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides essential meaning for all 5 parameters: it explains script_path is required, params is available inside the script, wall_s defaults to 75, formats default to step+glb, and out_dir defaults to 'derived/' beside the script with discussed constraints. This compensates for the missing schema descriptions, though not with per-parameter detail.
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 executes a parametric CAD script and exports the result. It uses specific verbs ('EXECUTES', 'exports') and identifies the resource (script, result shape). It distinguishes from siblings like model_inspect and model_validate by focusing on generating geometry from scripts.
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 explains the execution context (subprocess, resource limits) but does not explicitly state when to use this tool versus alternatives like model_inspect or text_to_cad. It implies usage for building models from code, but lacks direct exclusions or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses network call (consistent with openWorldHint), file output location, editable source, and the STARTER quality warning. Exceeds annotation alone.
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 front-loaded with purpose, covering prerequisites, side effects, and a warning. No redundant phrases.
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?
Good context on output (files in out_dir, KCL source) and network usage, but missing explanation for two parameters and no return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description only outlines prompt and out_dir, ignoring timeout_s and output_format. Insufficient for an agent to understand all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool generates a STARTER CAD model from a text prompt via a specific API, which differentiates it from inspection/validation sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions required environment variable (ZOO_API_KEY) and the need to verify dimensions, but does not compare to alternatives like model_build for manual modeling.
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?
Annotations already declare readOnlyHint=true. The description adds behavioral context by detailing the envelope verdict, which goes beyond annotations. No contradictions or missing 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?
Two sentences efficiently convey purpose and optional usage. No redundancy, front-loaded with main action.
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 input details and behavior well. It lacks return format or error conditions, but is sufficient for a read-only calculation 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?
With 0% schema coverage, the description compensates well by specifying component fields (name, mass_g, x_mm, y_mm, z_mm) and envelope fields. It adds meaning beyond the unannotated schema, but could be more precise about envelope 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 tool computes total mass and 3D center of gravity from a component list, with an optional envelope for a CG-within-envelope verdict. It uses specific terms and distinguishes from siblings like calc_fits and calc_fastener.
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 input format and envelope usage, but does not explicitly state when to use this tool vs alternatives. It implies context by focusing on mass properties, but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Behaviors such as separate layers for visible/hidden edges, output format selection by suffix, and refusal of colliding paths are disclosed. The idempotentHint annotation is consistent, and no contradictions exist.
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 paragraph with no redundancy. Each sentence conveys essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity, the description covers input types, output formats, views, layers, and a safety check. It could explicitly state the output is a file or data, but overall it is adequate.
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 explains the role of path, out_path, view, scale, and include_hidden by implication. For example, it mentions hidden edges are dashed, linking to include_hidden. This adds value beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool projects B-rep models (STEP/BREP/IGES) to 2D SVG/DXF from named views, distinguishing it from sibling tools like model_inspect or model_mesh. It specifies input formats, output formats, and view options.
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 notes this is 'a silhouette for hand-off, NOT a dimensioned drawing,' clarifying when to use. It also mentions the collision refusal behavior, but does not explicitly compare to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive. Description adds constraints: refuses collision with input (safety check) and writes only one output file. It also mentions tolerances are echoed in report. No contradiction with 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?
Two sentences covering all critical aspects: action, inputs, outputs, constraints, and tolerances. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input formats, output formats, tolerances, and collision constraint. Lacks explicit description of the report output (echoed but not defined) and error handling, but is sufficient for a simple file conversion tool with no output schema.
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% parameter descriptions. Description compensates by defining linear_tolerance_mm and angular_tolerance_deg with units, implying path/out_path are file paths, and clarifying output format determined by suffix. Could be more explicit about input/output roles.
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 specifies the exact verb (Tessellate), source (B-rep models: STEP/BREP/IGES), and output (mesh files: STL, GLB, GLTF, 3MF by suffix). It clearly distinguishes from siblings like model_inspect or model_validate which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies use when converting a B-rep model to a mesh at given tolerances. Does not explicitly state when not to use or compare with alternatives, but the sibling tools are sufficiently different that context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, confirming safety. Description adds significant behavioral context: every finding includes evidence and threshold, and it clarifies that missing checks are 'absent, not hidden'. This fully informs the agent about tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: first states the core purpose, second adds transparency about findings, third clarifies exclusions. Front-loaded with 'DFM-lite lint', no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers purpose, parameter usage (clearance_mm), limitations, and behavioral transparency. Sibling tools are sufficiently diverse, so no risk of confusion. Complete for a linting/validation tool.
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?
With 0% schema description coverage, the description partially compensates by clarifying that clearance_mm is used for pairwise interference and clearance checks. However, it does not explain the 'path' parameter, which is self-explanatory but still relies on schema for name/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?
Description clearly states 'DFM-lite lint for a B-rep model' and enumerates specific checks (kernel validity, non-manifold topology, etc.), distinguishing it from siblings that perform different operations like building, inspecting, or meshing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use (for B-rep model linting) and explicitly lists what it does NOT check (wall thickness, draft, threads, GD&T), implying when it should not be used. However, it does not name alternative sibling tools for those exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds important behavioral details: file types, local processing, and volume reporting conditions (watertight for mesh). No contradictions, and disclosures go beyond 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?
Description is a single paragraph with three sentences, each earning its place. It is front-loaded with the main action and efficiently covers supported formats, computed properties, and privacy.
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 (multiple formats, optional density, per-solid data) and no output schema, the description thoroughly explains what the tool returns and under what conditions, making it complete for agent decision-making.
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 has 0% description coverage; the description fully compensates by explaining that 'density_g_cm3' is for mass calculation and 'path' is for the model file. It adds semantic value 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?
Description clearly states the tool summarizes a CAD model with specific outputs (bounding box, volume, etc.) and lists supported file formats. It contrasts with sibling tools like model_validate and model_build, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspection without explicit when-to-use vs siblings, but it provides context such as 'Reads the file on this machine; nothing leaves it,' which guides on privacy. A more explicit comparison would improve clarity.
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:

[![root-ext-cad MCP server](https://glama.ai/mcp/servers/graphgrow/root-ext-cad/badges/card.svg)](https://glama.ai/mcp/servers/graphgrow/root-ext-cad)

Score Badge

Copy to your README.md:

[![root-ext-cad MCP server](https://glama.ai/mcp/servers/graphgrow/root-ext-cad/badges/score.svg)](https://glama.ai/mcp/servers/graphgrow/root-ext-cad)

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/graphgrow/root-ext-cad'

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