dts-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DTS_ENGINE_DIR | No | Path to the DTS Engine installation directory. Defaults to %APPDATA%\DTS Engine\<version>. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| dts_pingA | Check that DTS Engine is installed and reachable. Call this first. Reports the Engine version, which executables are present, and the bundled GDAL. Every other tool fails if this one does. |
| dts_list_pipelinesA | List the publish pipelines, their flags, and whether each is verified.
|
| dts_explain_errorA | Explain a DTS Engine exit code using the table Engine ships. Bands: io (0-19), lod (100-119), terrain (200-249), resource (300-309), crs (400-409), vtpk (500-509), dem_opt (600+).
|
| dts_validateA | Check a flag set against a pipeline spec without running anything. Cheap pre-flight: catches missing required flags and typos locally, so a malformed publish costs no Engine time. |
| dts_publishA | Run a DTS Engine publish pipeline and report artifacts.
The verified workflow is Success yields a .3dt tile plus DataInfor.txt. On failure, read Set strict=False to pass experimental flags the spec does not list. For OSGB use dts_publish_osgb instead: that format needs two sequential processes and this tool would only run the first. |
| dts_publish_osgbA | Publish oblique-photogrammetry OSGB data, running both required stages. OSGB publishing is two sequential Engine processes: tiling, then the LOD
pyramid. Stopping after the first leaves an incomplete dataset, so both are
run and reported here. |
| dts_create_jobA | Write an .aconf job file, the input for Engine's -jsonPath mode.
Note: job-file mode is transcribed from the decompiled shell but has not been verified end-to-end. Prefer dts_publish for production work. |
| dts_job_typesA | List .aconf job data types and the fields transcribed for each. A null |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool targets a distinct operation: health check, pipeline enumeration, error lookup, validation, job type enumeration, standard publish, OSGB publish, and job file creation. The two publish tools are clearly separated by data format, so no ambiguity exists.
All tools share the dts_ prefix and use snake_case with a consistent verb_noun pattern (e.g., dts_list_pipelines, dts_explain_error, dts_create_job). The one exception, dts_publish_osgb, still follows the pattern with a format suffix and remains predictable.
With 8 tools, the server is well-scoped for its domain. Each tool serves a necessary role in the DTS Engine workflow without redundancy or excessive granularity.
The tool set covers the full operational lifecycle: checking engine health, listing pipelines and job types, validating flags, running both standard and OSGB publishes, creating job files, and explaining errors. No obvious gaps exist for the stated purpose.