Aspicio
Server Details
DXF drawings for AI agents: structured facts, PNG renders, and an interactive in-chat viewer.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- frontsail-ai/aspicio
- GitHub Stars
- 0
- Server Listing
- aspicio-dxf-viewer
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.
Tool Definition Quality
Average 4.5/5 across 4 of 4 tools scored.
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.
All tool names follow a consistent verb_noun snake_case pattern (describe_dxf, load_dxf_for_viewer, render_dxf, view_dxf), making it predictable.
With 4 tools, the server is well-scoped for DXF drawing analysis: one for facts, one for static image, one for interactive use, and one internal loader. No bloat.
The tool surface covers the main use cases for a DXF analysis server: retrieving structural information, visual inspection via image, and interactive exploration. No obvious gaps for its stated purpose.
Available Tools
4 toolsdescribe_dxfDescribe a DXF drawingARead-onlyInspect
Return 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.) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by detailing return content (including skipped/unsupported types) and the hosting limitation for local files, providing behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient paragraph, front-loaded with the core purpose, and every sentence adds value without redundancy.
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 no output schema, the description fairly covers what the JSON includes. The tool is simple with one parameter, and the description addresses key aspects, though it could mention typical use cases more explicitly.
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?
With 100% schema coverage and only one parameter, the description adds meaning by clarifying that 'source' can be a URL or inline text and notes the hosted server limitation, which is not in the 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?
The description clearly states the tool returns a structured JSON summary of a DXF drawing and lists specific items (units, bounding box, layers, entity counts, text). It distinguishes from sibling tools by focusing on structural information without rendering.
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?
The description explicitly says to use this tool for answering structural questions without rendering an image, implying when it is appropriate. It does not name sibling tools directly but the context provides them; sufficient guidance.
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 widgetARead-onlyInspect
Internal: 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) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so safety is covered. The description adds that the output is base64 bytes, which is useful but basic. No contradiction.
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, no fluff. First sentence defines action and output, second provides usage context. Efficient and clear.
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?
For a simple retrieval tool with full schema coverage and annotations, the description is sufficient. It might lack error or limitation details, but overall complete.
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 description coverage is 100%, so the schema already documents parameters. The description does not add parameter-specific meaning beyond the overall purpose.
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 the tool returns DXF bytes (base64) for the viewer, and distinguishes itself from siblings (describe, render, view) by being an internal loader for the widget.
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 says 'Called by the widget, not the model,' giving clear when-not-to-use guidance. However, it does not mention alternatives for other use cases.
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 imageARead-onlyInspect
Render 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.) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns an image (not text), mentions a direct image link for URL sources, and notes constraints about local file paths. This provides useful behavioral context beyond the safety annotations.
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?
The description is a single paragraph with essential information front-loaded (purpose, then usage, then output handling). Every sentence adds value, no redundant or vague statements.
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 tool's simplicity (2 parameters, no output schema), the description covers core functionality, use cases, output format, and UI considerations. It is complete enough for an AI agent. Minor omissions: no mention of error cases or DXF version limitations, but not critical.
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%, baseline 3. The description adds context about the source parameter: it can be a URL or inline text, and clarifies that local file paths are not supported. It also mentions default width (1200) implicitly. This extra explanation enhances understanding beyond the 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?
The description clearly states 'Render a DXF drawing to a PNG image you can look at', specifying the verb (Render) and resource (DXF drawing to PNG). It distinguishes from siblings by directing to describe_dxf for measurements and view_dxf for interactive viewing.
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 this to answer visual questions', 'For structural facts and measurements, prefer describe_dxf; never measure pixels', and 'When the user wants to see or explore the drawing themselves, prefer view_dxf'. Also advises on handling image display in chat 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 viewerARead-onlyInspect
Open 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) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint false), describes widget delivery mechanism, handling of small vs. large drawings, and that viewer posts status back. 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?
Three sentences, no waste. Front-loaded with purpose, then usage, then behavioral notes. Every sentence adds value.
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 2 parameters with full schema coverage, no output schema, and annotations clear, description covers use case, constraints, and pitfalls. Sufficient for agent to select and invoke correctly.
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%, descriptions add context: source includes note about hosted server and local alternative, allow_file_open explains default behavior. Meaning added 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?
Clearly states 'Open an interactive DXF viewer' and differentiates from siblings (describe_dxf for facts, render_dxf for image). Specific verb+resource with scope.
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 says 'when the user wants to see or explore the drawing themselves' and provides exclusions: 'for your own analysis use describe_dxf or render_dxf'. Also gives behavioral guidance on not re-fetching or blind-retrying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.