gisgp

dxf_to_geojson

Convert an AutoCAD DXF file's contents to GeoJSON — e.g. "convert this DXF to GeoJSON", "AutoCAD drawing to GIS format", "DXF export from Civil 3D to GeoJSON", "extract only the UTILITIES layer from this DXF". POINT/LINE/LWPOLYLINE/POLYLINE/ARC/CIRCLE/ELLIPSE/SPLINE/HATCH/MPOLYGON convert (curves tessellated into LineString/Polygon), TEXT/MTEXT become points with a text property, and block INSERTs are expanded at their real position/scale/rotation with ATTRIB values as properties; 3D solids and meshes have no 2D GIS equivalent and are skipped, not errored on. Every feature's properties.layer carries its DXF layer name (group code 8). Pass layer to return only that layer's entities — see list_dxf_layers to discover what layer names exist first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "dxf": "<dxf>"
    },
    "name": "dxf_to_geojson"
  }
}

Input Schema

Name	Required	Description	Default
`dxf`	Yes
`layer`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 10, 2026

addedInput schema / properties / layer

Added value: +{
+  "default": "",
+  "title": "Layer",
+  "type": "string"
+}

AddedAug 10, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With zero annotations the description carries the full burden and does substantial work: entity-type coverage, curve tessellation into LineString/Polygon, TEXT/MTEXT becoming points with a `text` property, INSERT blocks expanded with position/scale/rotation and ATTRIB properties, and 3D solids/meshes skipped rather than erroring. The unexplained piece is coordinate reference handling — DXF typically has no CRS and the description never states what CRS the output carries or whether reprojection is needed.

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?

Front-loaded with the verb+resource, then the quoted example utterances, then supported-entity behavior, then the layer workflow. Dense and mostly waste-free, though the run of four quoted phrasings is slightly redundant for an agent that already read the first clause.

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?

An output schema exists, so return-shape explanation is unnecessary, and the description covers entity handling and layer scoping thoroughly. The remaining shortfall is CRS/georeferencing behavior and the exact form of the `dxf` input — both material for a GIS conversion tool.

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 0%, so the description must compensate. It explains `layer` well (filters to that layer's entities, discover names via list_dxf_layers), but `dxf` is only described as "an AutoCAD DXF file's contents" — ambiguous whether it is a filesystem path, raw DXF text, base64, or a URL, which is the single most important thing to get right before calling.

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?

Names a specific verb and resource (convert DXF file contents to GeoJSON) and immediately distinguishes itself from siblings by describing the layer-filter case and pointing to list_dxf_layers, plus the reverse sibling geojson_to_dxf is implicitly contrasted by direction. An agent can select this over convert_file or georeference_dxf with reasonable confidence.

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?

Provides concrete invocation phrasings ("convert this DXF to GeoJSON", "extract only the UTILITIES layer") and an explicit ordering rule: call list_dxf_layers first to discover layer names before using the `layer` filter. No explicit when-not-to-use guidance versus generic siblings like convert_file or georeference_dxf, which is the only gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All gisgp tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.