Opens, inspects, and renders DXF/CAD drawings for AI agents: describe_dxf returns structured facts (layers with actual drawn colors, units, bounds, text content) and render_dxf returns PNG images. On MCP Apps hosts like ChatGPT and Claude, view_dxf opens an interactive in-chat viewer with pan, zoom, and layer toggles.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 4 of 4 tools scored. Lowest: 3.9/5.
Each tool has a distinct purpose: describe_dxf for structured facts, render_dxf for static images, view_dxf for interactive exploration, and load_dxf_for_viewer as an internal helper. No overlap or ambiguity.
All tool names follow the consistent verb_dxf pattern (e.g., describe_dxf, render_dxf) using snake_case, making the set predictable and easy to navigate.
With 4 tools, the set is well-scoped for a DXF viewer server: one for structured data, one for rendered images, one for interactive viewing, and one internal loader. No excess or deficiency.
The tools cover the full lifecycle of analyzing and viewing a DXF drawing: structural description, static rendering, and interactive exploration. The internal loading tool supports the viewer widget, leaving no obvious gaps for the stated purpose.
describe_dxfDescribe a DXF drawingAReturn a structured JSON summary of a DXF drawing — units, bounding box, layers (with the color actually drawn), per-type entity counts, the drawing's text content (title blocks and dimension values included), and any skipped/unsupported types. Use this to answer structural questions (what layers exist, how many parts, what size, what does it say) without rendering an image.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | A publicly reachable http(s) URL to a .dxf file, or the DXF content inline as text. (This is a hosted server — local file paths are not available; use the npx @aspicio/mcp local server for files on disk.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds that the tool returns a read-only summary, includes text content, and notes skipped/unsupported types. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence that efficiently conveys the tool's purpose and usage. No wasted words; front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 param, no output schema), the description is complete: it describes the output contents in detail, explains the parameter with usage notes, and provides a clear use case. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'source' is described with practical details: accepts URLs or inline DXF text, notes that local file paths are unavailable, and suggests an alternative local server. This adds significant value beyond the schema's description, which is already thorough (100% coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a structured JSON summary of a DXF drawing, listing specific contents (units, bounding box, layers, counts, text, unsupported types). It differentiates from siblings by focusing on structural questions without rendering an image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: for structural questions (what layers, how many parts, size, text) and clarifies it does not render an image, implying alternatives like render_dxf. Does not explicitly name sibling tools, but context provides them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_dxf_for_viewerLoad a DXF for the viewer widgetAInternal: returns DXF bytes (base64) for the in-chat viewer. Called by the widget, not the model.
| Name | Required | Description | Default |
|---|---|---|---|
| length | No | Byte length of the requested range | |
| offset | No | Byte offset of the requested range | |
| source | Yes | http(s) URL of the DXF (same guards as the other tools) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false; the description adds that it returns base64 DXF bytes. This provides some value beyond annotations but does not describe any side effects or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with one sentence, front-loading key information (internal, purpose). Every word earns its place, though it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and rich annotations, the description covers return format and context. It lacks error behavior details, but overall is sufficient for an internal tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema (100% coverage), so the description adds no further meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns DXF bytes in base64 for the in-chat viewer, and explicitly says it is internal and called by the widget, not the model. This distinguishes it from siblings like 'describe_dxf', 'render_dxf', and 'view_dxf'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Internal' and 'called by the widget, not the model,' providing clear guidance that the model should not invoke this tool directly. However, it does not explicitly mention alternatives for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_dxfRender a DXF to an imageARender a DXF drawing to a PNG image you can look at. Use this to answer visual questions (what does it look like, where is a feature) — it returns an image, not text. For structural facts and measurements, prefer describe_dxf; never measure pixels. Some chat UIs do not display the returned image to the user: for URL sources the result also includes a direct image link — show it to the user (e.g. as a markdown image) when they need to see the render. When the user wants to see or explore the drawing themselves, prefer view_dxf (interactive viewer) — if your platform gates it behind user approval, offer it and ask rather than substituting a static render.
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | PNG width in pixels (default 1200) | |
| source | Yes | A publicly reachable http(s) URL to a .dxf file, or the DXF content inline as text. (This is a hosted server — local file paths are not available; use the npx @aspicio/mcp local server for files on disk.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, open-world, non-destructive. Description adds that output is an image (not text), includes direct image link for URL sources, and notes potential UI limitations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive: first sentence states purpose, then usage guidelines, then display notes. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity, good annotations, and sibling tools, description covers when to use, alternatives, output format, display instructions, and source types. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% already documents parameters. Description clarifies source can be URL or inline text and explains the hosted server context, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'render' and resource 'DXF to PNG image'. Clearly distinguishes from siblings: describes describe_dxf for structural facts and view_dxf for interactive exploration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: use for visual questions, avoid for measurements, prefer alternatives. Also instructs on displaying image to user in some UIs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
view_dxfOpen a DXF in the interactive viewerAOpen an interactive DXF viewer the user can pan, zoom, and toggle layers in (renders in-chat on MCP Apps-capable hosts). Use this when the user wants to see or explore the drawing themselves; for your own analysis use describe_dxf (facts) or render_dxf (image). The viewer shows only the drawing from this call. Delivery is handled by the widget itself: small drawings are embedded in the result and larger URL-sourced drawings are fetched by the widget through its own tool call — never re-fetch or inline the file for the viewer's sake, and don't blind-retry if the user reports an empty viewer (the viewer posts its actual status back to the conversation context).
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | A publicly reachable http(s) URL to a .dxf file, or the DXF content inline as text. (This is a hosted server — local file paths are not available; use the npx @aspicio/mcp local server for files on disk.) | |
| allow_file_open | No | Show open-file controls in the viewer (default false: viewer is locked to this drawing) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral details: small drawings embed, larger ones are fetched via widget, status is posted back to conversation, and instructions on not re-fetching. It could be slightly more specific about size thresholds but is very informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a clear warning, all front-loaded. No wasted words; every sentence adds value. The structure first states purpose, then usage context, then behavioral caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description comprehensively explains viewer behavior, embedding vs fetching, status reporting, and constraints. For a simple viewer with 2 parameters, it covers all necessary context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions. The description adds context beyond schema, e.g., source parameter explains public URL vs inline text and notes local files aren't available, and allow_file_open gets a clear default. This enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it opens an interactive DXF viewer and distinguishes it from siblings like describe_dxf (facts) and render_dxf (image). The verb 'open' combined with 'viewer' and the specific resource (DXF) make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'when the user wants to see or explore the drawing themselves; for your own analysis use describe_dxf or render_dxf'. Also warns against re-fetching or blind-retrying, providing clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
