AutoCAD LT AutoLISP MCP Server

by puran-water

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v3.0.0
Disambiguation5/5
Each tool category has a distinct purpose with clear boundaries: annotation for annotations, block for blocks, drawing for file management, entity for entity operations, layer for layers, pid for P&ID, system for server management, and view for viewport control. Within categories, operations are well-differentiated by specific actions and target entities, with no significant overlap that would cause confusion.
Naming Consistency4/5
Tool names are highly consistent within categories, using clear verb_noun patterns (e.g., create_text, list_layers, zoom_extents). There are minor deviations, such as 'get_screenshot' (verb_noun) vs. 'zoom_extents' (verb_adjective), and some operations like 'undo' or 'redo' are single verbs, but overall the naming is predictable and readable across the set.
Tool Count5/5
With 8 tools, the server is well-scoped for AutoCAD LT AutoLISP functionality, covering essential domains like drawing management, entity creation, annotation, and specialized P&ID tasks. Each tool category serves a distinct purpose, and the total count is manageable without being overwhelming or too sparse for the domain.
Completeness5/5
The tool set provides comprehensive coverage for AutoCAD LT operations, including full CRUD/lifecycle for entities, layers, and blocks, along with drawing file management, annotation, P&ID-specific functions, system controls, and viewport manipulation. There are no obvious gaps; agents can perform complete workflows from creation to modification and export.
Average 3.3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, implying mutations, which aligns with 'create' operations in the description. The description adds value by detailing specific operation types and their data structures, but doesn't disclose behavioral traits like permissions, side effects, or rate limits beyond what annotations provide.
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 appropriately sized and front-loaded with a clear purpose statement. The bulleted list of operations is efficient, though some details could be more structured. No wasted sentences, but minor improvements in clarity are possible.
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 3 parameters with 0% schema coverage and an output schema exists, the description partially compensates by detailing operations. However, it doesn't fully explain parameter semantics or behavioral context, leaving gaps for a mutation tool with multiple operations.
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 partially does by listing operations and their data fields, but doesn't explain the 'operation' parameter's allowed values or the purpose of 'include_screenshot'. The data structures are described but lack context on units or constraints.
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 handles annotation operations (text, dimensions, leaders) in AutoCAD, specifying the resource. It distinguishes from siblings like 'drawing' or 'entity' by focusing on annotation creation. However, it doesn't explicitly contrast with all siblings, missing a direct comparison.
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 'entity' or 'drawing' is provided. The list of operations implies usage for creating specific annotation types, but lacks explicit context, prerequisites, or exclusions.
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?
Annotations indicate readOnlyHint=false, and the description confirms this with operations like 'insert' and 'update_attribute' that imply mutations. The description adds some behavioral context by listing specific operations and their data structures, but doesn't disclose permissions, side effects, or error conditions beyond what annotations imply.
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 efficiently structured with a summary line followed by bullet-like operation listings. Each operation is clearly named with minimal data structure hints. No wasted sentences, though the formatting could be more polished.
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 (multiple operations with different data structures), 0% schema coverage, and presence of an output schema, the description is moderately complete. It covers operation types and basic data shapes but lacks comprehensive parameter documentation, error handling, or relationship to sibling tools.
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 for 3 parameters, the description must compensate but only partially does. It explains the 'operation' parameter through listed operations and hints at 'data' structures for each operation, but doesn't document 'include_screenshot' at all or provide full details on data field requirements/constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Block definition, insertion, and attribute management' with specific operations listed. It distinguishes this tool from siblings like 'entity' or 'layer' by focusing on block operations, though it doesn't explicitly contrast with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lists operations but doesn't indicate when each operation is appropriate, what prerequisites exist, or how this tool relates to sibling tools like 'entity' or 'drawing'.
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?
Annotations provide readOnlyHint=false (indicating mutations) and a title, but the description adds useful context about what specific drawing operations are available (creating layers, inserting symbols, drawing lines, etc.). However, it doesn't disclose important behavioral traits like whether operations are destructive to existing drawings, authentication requirements, rate limits, or error conditions. The description adds some value beyond annotations but misses key behavioral details.
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 efficiently structured with a brief introductory statement followed by a bulleted list of operations. Each operation is clearly named with its required data fields. While comprehensive, it maintains a clean, scannable format without unnecessary verbiage. The structure helps the agent quickly understand available functionality.
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 (12 operations with varying data structures), the description provides substantial operational detail. With an output schema present, the description doesn't need to explain return values. The main gap is lack of guidance about when to use this versus sibling tools, but otherwise it gives the agent sufficient information to understand what the tool can do.
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 compensates well by detailing 12 specific operations with their expected data fields. For example, it specifies that 'insert_symbol' requires {category, symbol, x, y, scale?, rotation?} - providing semantic meaning that the bare schema lacks. The description effectively documents the 'operation' parameter's possible values and their associated data structures.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states this is for 'P&ID drawing with CTO symbol library' and lists specific operations, which gives a general purpose. However, it doesn't clearly differentiate from sibling tools like 'drawing' or 'block' - the relationship to these other drawing-related tools is unspecified. The purpose is somewhat clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the sibling tools like 'drawing', 'block', 'layer', or 'annotation'. The description simply lists operations without context about appropriate use cases, prerequisites, or alternatives. The agent must infer usage from the operation names alone.
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?
Annotations provide readOnlyHint=true, indicating safe read operations. The description adds useful context about specific operations like 'execute_lisp' being for 'File IPC only' and mentioning 'spawn diagnostics' for runtime, which goes beyond annotations. However, it doesn't cover rate limits, authentication needs, or detailed 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?
The description is well-structured with a brief header followed by a bulleted operation list, making it easy to scan. Each operation is succinctly described. However, the 'execute_lisp' line could be more concise, and some operations lack clarity (e.g., 'runtime' vs 'status').
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 (multiple operations) and 0% schema coverage, the description is incomplete—it doesn't explain all parameters or their relationships. The presence of an output schema helps, but the description should better clarify operation-specific behaviors and parameter 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?
With 0% schema description coverage for 3 parameters, the description carries full burden. It only mentions 'data: {code}' for the execute_lisp operation, leaving 'operation' and 'include_screenshot' parameters unexplained. This insufficiently compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Server status and management' and lists specific operations, providing a good overview of what it does. However, it doesn't explicitly differentiate this system management tool from its siblings (annotation, block, drawing, etc.), which are presumably CAD-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the operation list (e.g., 'health' for quick checks, 'init' for re-initialization), but doesn't explicitly state when to use this tool versus alternatives. There's no guidance on prerequisites or when-not-to-use scenarios.
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?
Annotations provide readOnlyHint=false, indicating potential mutations, which aligns with operations like 'create' and 'set_properties'. The description adds value by listing specific operations and their required data parameters, giving context about what actions are possible. However, it doesn't disclose additional behavioral traits like permission requirements, side effects, or error handling beyond what annotations imply.
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 front-loaded with a clear purpose statement followed by a bulleted list of operations and their data requirements. It's efficiently structured with zero wasted sentences, though the bulleted format could be slightly more polished for 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 (multiple operations with varying data needs), 0% schema coverage, and the presence of an output schema, the description does a decent job. It covers operation types and data structures but lacks details on error cases, permissions, or how operations interact. The output schema likely handles return values, but more behavioral context would improve completeness.
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 carries the full burden of explaining parameters. It effectively details the 'operation' parameter with specific values (list, create, etc.) and outlines the 'data' structure for each operation (e.g., {name, color?} for create). This compensates well for the schema gap, though it doesn't explicitly cover the 'include_screenshot' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Layer creation and management' and lists specific operations (list, create, set_current, etc.), which provides a clear verb+resource combination. However, it doesn't explicitly differentiate this tool from sibling tools like 'entity' or 'drawing' that might also manage CAD elements, so it doesn't reach the highest level of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lists operations but doesn't explain when to choose 'layer' over sibling tools like 'entity' or 'annotation', nor does it mention prerequisites or exclusions for specific operations. This leaves the agent with minimal contextual 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?
Annotations indicate readOnlyHint=false, suggesting write capabilities, which aligns with operations like 'create', 'save', and 'undo'. The description adds behavioral context by specifying what each operation does (e.g., 'saves to path if given, else QSAVE'), but doesn't cover permissions, rate limits, or error handling beyond the 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 efficiently structured with a brief header and bullet-pointed operations, each with clear data requirements. Every sentence adds value without redundancy, making it easy to scan and understand.
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 with multiple operations and 0% schema coverage, the description provides substantial context on operations and data. Since an output schema exists, it doesn't need to explain return values, but it could benefit from more behavioral details like error cases or dependencies.
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 compensates well by explaining the 'operation' parameter values (e.g., create, open, save) and the 'data' parameter structures for each operation (e.g., {name?}, {path}). However, it doesn't detail the 'include_screenshot' parameter, leaving a minor gap.
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 performs 'Drawing file management' and lists specific operations like create, open, save, etc., providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'entity' or 'layer' which might handle related drawing components.
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 like 'annotation' or 'block'. It simply lists operations without context about prerequisites, appropriate scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations. While annotations provide readOnlyHint=true and a title, the description explains the three specific operations (zoom_extents, zoom_window, get_screenshot) and their purposes. This gives the agent concrete understanding of what behaviors to expect, though it doesn't mention side effects like temporary view changes or file output for screenshots.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear headline followed by bullet-point operations. Each operation is briefly described with just enough detail. There's minimal waste, though the formatting with dashes could be slightly cleaner for parsing.
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 moderate complexity (5 parameters, 3 operations), annotations covering safety (readOnlyHint), and an output schema (which handles return values), the description provides adequate context. It explains the core operations clearly, though additional details about coordinate systems or screenshot formats would make it more 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?
With 0% schema description coverage, the description partially compensates by explaining that x1, y1, x2, y2 are used for 'zoom_window' operation coordinates. However, it doesn't explain the 'operation' parameter's expected values beyond listing them, nor does it clarify coordinate systems, units, or defaults. The description adds some meaning but doesn't fully compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'viewport control and screenshot capture' and lists three specific operations, making it clear what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'drawing' or 'entity' which might also involve view-related functionality, preventing a perfect score.
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. There's no mention of when to choose 'view' over sibling tools like 'drawing' or 'entity', nor any context about prerequisites or typical use cases for viewport operations.
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?
Annotations provide readOnlyHint=false, correctly indicating this is a mutation tool. The description adds significant behavioral context by detailing 19 specific operations with their parameter patterns, which goes beyond the annotations. However, it doesn't disclose important behavioral traits like error conditions, permission requirements, whether operations are destructive (beyond 'erase'), or how modifications affect the drawing state.
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 efficiently structured with clear operation categories (Create/Read/Modify) and bullet-like syntax for each operation. Every line adds value by specifying operation-parameter mappings. While somewhat dense due to the many operations, there's minimal waste—each operation specification serves a clear documentation 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?
Given the tool's complexity (19 operations across 3 categories), 0% schema coverage, and the presence of an output schema (which handles return values), the description provides substantial operational context. It documents parameter requirements for each operation type, which is crucial given the schema's lack of descriptions. The main gap is the absence of behavioral constraints and sibling tool differentiation.
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?
With 0% schema description coverage and 10 parameters, the description carries the full burden of parameter documentation. It excels by mapping each operation to specific parameter requirements (e.g., 'create_line — x1, y1, x2, y2, layer?'), providing clear semantic meaning that the schema's generic property names completely lack. The description effectively compensates for the schema's deficiencies.
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 this tool handles 'Entity creation, querying, and modification' which is a specific verb+resource combination. It distinguishes itself from siblings like 'layer', 'block', or 'drawing' by focusing specifically on geometric entities rather than layers, blocks, or drawing properties. However, it doesn't explicitly contrast with these alternatives in the description text itself.
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 its siblings (annotation, block, drawing, layer, pid, system, view). It lists operations but doesn't explain prerequisites, when certain operations are appropriate, or what distinguishes entity operations from other CAD manipulation tools. The user must infer usage from the operation list alone.
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:

[![autocad-mcp MCP server](https://glama.ai/mcp/servers/puran-water/autocad-mcp/badges/card.svg)](https://glama.ai/mcp/servers/puran-water/autocad-mcp)

Score Badge

Copy to your README.md:

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

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