cadlens-mcp

Official

by cadlens-co

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.6.0
Disambiguation5/5
Each tool has a distinct purpose: two parse variants clearly separated by input source (local file vs URL), plus status checking, result retrieval, image refresh, listing, and deletion. There is no functional overlap between any tools.
Naming Consistency5/5
All tools follow the consistent pattern 'cadlens_<verb>_<object>' with snake_case (e.g., parse_file, get_result, delete_job). The naming is uniform, predictable, and clearly indicates both the action and the resource.
Tool Count5/5
Seven tools is an ideal size for a CAD parsing service. Each tool covers a necessary part of the workflow without redundancy or bloat, making the toolset well-scoped and easy to navigate.
Completeness5/5
The toolset covers the full lifecycle of a parse job: creation (from file or URL), status polling, result retrieval with multiple detail modes, preview image refresh, job listing, and deletion. No critical operations are missing.
Average 4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 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

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 the operation is irreversible and that it also removes the uploaded file and preview image, which is beyond the obvious 'delete job' action. It does not mention error behavior or idempotency, but the destructive scope is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action and immediately states consequences. Every word adds value, with no waste.
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 delete tool with one parameter, the description covers key behavioral aspects like irreversibility and associated file deletion. However, it lacks usage context, parameter semantics, and any mention of return behavior or error conditions, leaving gaps given absent annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema contains only job_id with no parameter description, and schema coverage is 0%. The tool description does not mention job_id or explain its meaning, format, or how to obtain it, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a job and its associated files/preview image, with a specific verb and resource. It distinguishes itself from sibling tools like get_job and parse_file by indicating a destructive removal action.
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, such as whether deletion should occur after job completion or if there are prerequisites. The description offers no exclusions or cautions beyond irreversibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only mentions a size limit (max 100 MB) and the action of parsing. It fails to disclose whether parsing is asynchronous (despite webhook_url and notify_email parameters suggesting a job-based flow), what the response format is, what happens after parsing, or any side effects. The reference to 'Same output as cadlens_parse_file' is vague without sibling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing two short sentences that front-load the key action and size limit. No unnecessary words or repetition—every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, and the presence of webhook/notify parameters that hint at job-based asynchronous behavior, the description is incomplete. It does not explain the return structure or job mechanics, and the webhook_url parameter is left undocumented. The brief reference to a sibling tool does not fill this gap.
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 67% (url and notify_email have descriptions, webhook_url does not). The description adds the 100 MB size constraint for the url parameter, which is not in the schema. However, it does not clarify webhook_url, leaving a parameter unaddressed. Overall, the description adds marginal value but relies mostly on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Download a CAD file from a URL (max 100 MB) and parse it.' It uses specific verbs (download, parse) and a resource (CAD file from URL), and distinguishes itself from the sibling tool cadlens_parse_file by explicitly noting 'Same output as cadlens_parse_file' while differing in input source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you have a URL to a CAD file) and explicitly references an alternative (cadlens_parse_file) by stating the output is the same. However, it does not explicitly state when not to use it or provide a direct comparison beyond the sibling mention.
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 the 100-job limit, newness ordering, and API key scoping, which is useful behavioral context. However, with no annotations provided, it does not explicitly state read-only nature or what each job entry includes, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the action ('List') and packs all key details (scope, order) without any filler. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description covers the essential scope and ordering constraints. It could mention the structure of returned job items, but given sibling tools and simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is nothing to document. The baseline for 0-param tools is 4, and the description appropriately adds no unnecessary param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('CAD parse jobs') with precise scoping ('100 most recent', 'newest first'). It distinguishes from sibling tools like get_job (single job) and delete_job (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?
The description implies usage for retrieving recent jobs but does not explicitly state when to use this over alternatives like get_job or how it differs from listing via other means. Sibling names make the distinction inferable, but the description lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the 'full' mode can be very large, which is useful. However, it doesn't mention failure modes (e.g., job not found, still running) or explicitly state read-only behavior beyond the verb 'Fetch'. The prerequisite 'completed' is mentioned but not elaborated.
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, followed by concise mode usage. Every phrase earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a result-retrieval tool with 4 params and no output schema, the description covers the essential modes, the size warning, and the completion prerequisite. It could be slightly more explicit about the nature of the 'summary' output, but the sibling tools provide enough context for an agent to select and invoke this tool successfully.
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 50%, with descriptions only for layer_name and entity_type. The description adds value by explaining the meaning of each mode and clarifying that 'full' returns large JSON. It doesn't describe job_id, but that's self-explanatory. The conditional requirements are already in the schema, so the description adequately compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Fetch the parsed result of a completed CAD job', using a specific verb and resource. It clearly differentiates from sibling tools like cadlens_get_job (status) and cadlens_parse_file (creation) by focusing on parsed results of completed jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool (after completion) and provides mode-specific guidance (summary, entities_by_type, entities_on_layer, full). It doesn't explicitly mention alternatives or exclusions, but the sibling context and 'completed' prerequisite make the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that the tool polls until completion or 5 minutes elapse, and that it returns a summary including a preview image URL. This gives a clear operational model, though it doesn't detail failure modes or timeout behavior outcomes.
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 straightforward sentences cover formats, size limit, execution behavior, return value, and next-step tool. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return summary and preview URL, and points to cadlens_get_result for detailed data. The overall workflow is sufficiently sketched, though it omits explicit mention of job status fields or error handling.
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 schema already covers all three parameters at 100% coverage, so the description adds no new parameter syntax or format details. It does contextualize the returned job_id as the input for cadlens_get_result, but that is not parameter-specific.
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 parses local CAD files, lists supported formats (DWG/DXF/DWF/DWFx/DGN-V7/PDF), and specifies a 100 MB limit. The word 'local' distinguishes it from the sibling cadlens_parse_url, making the resource and scope 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 use for local files vs. URLs (via 'local') and explicitly directs users to call cadlens_get_result with the returned job_id for detailed entity data. It provides a clear next step but does not explicitly contrast with cadlens_parse_url or list disallowed scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It discloses that the URL is valid for 3600 seconds (expiration) and that it is cheaper than re-fetching the full result, which are meaningful behavioral traits. It does not mention potential errors or prerequisites beyond 'completed job', but the key behaviors are covered.
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 primary action, and directly followed by a cost-saving note and validity duration. Every word contributes to understanding the tool, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, single-parameter tool with no output schema, the description covers the essential context: what it does, when to use it, cost implications, and URL expiration. It does not explicitly state the return value (the URL), but this is strongly implied. Minor gaps remain regarding error behavior for non-completed jobs, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does not explicitly explain the job_id parameter, but the name and context ('for a completed job') imply its role. Given the single, self-explanatory parameter, the description adds minimal semantic value beyond what is already evident from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Re-fetch the presigned preview-image URL for a completed job.' This specific verb+resource distinguishes it from sibling tools like cadlens_get_result, and the cost comparison 'Cheaper than re-fetching the full result' further differentiates its use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need the preview image URL for a completed job and want to avoid the cost of fetching the full result. It implies a usage scenario but does not explicitly state alternatives or exclusions, though the comparison to 'full result' serves as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the return values (PENDING, PROCESSING, COMPLETED, FAILED). The read-only nature is clear from 'Check', and the tool's behavior is predictable. It lacks explicit mention of error handling or polling implications, but this is minor for such a simple status endpoint.
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, directly states the action and the possible return values, with no wasted words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one well-documented parameter and no output schema, the description is complete. It explains what statuses can be returned, which is sufficient for an agent to understand the tool's role in the parse workflow.
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 schema provides complete coverage for job_id, including its source ('returned by parse_file/parse_url'), so the description adds no additional parameter semantics. The baseline of 3 applies since the schema already documents the parameter fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose with a specific verb ('Check') and resource ('status of a CAD parse job'), and it distinguishes from siblings by listing the exact status values returned. It is immediately obvious this tool is for status polling, not for results or management.
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 the usage context by referencing job_id from parse_file/parse_url, reinforcing the expected flow. However, it does not explicitly name alternatives like list_jobs or get_result, so the agent must infer when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

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

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