aspicio-dxf-viewer-remote

Render a DXF to an image

render_dxf

Read-only

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.

Input Schema

TableJSON Schema

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.)

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All aspicio-dxf-viewer-remote tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Resources

Need Help?