The dts-mcp-server provides an interface (local via stdio or remote via HTTPS) to control DTS Engine 6.1, a Windows tool for generating 3D digital-twin tiles from various input types (shapefiles, OSGB, DEM/DOM, BIM, point clouds, etc.).
Key capabilities:
Health Check (dts_ping): Verify Engine installation, version, and GDAL info.
List Pipelines (dts_list_pipelines): Show available publish pipelines, their flags, and verification status.
Validate Flags (dts_validate): Pre-flight check flag sets against pipeline specs without running Engine.
Execute Pipelines (dts_publish): Run any pipeline (e.g., road) with full flags, producing 3D tiles.
Publish OSGB (dts_publish_osgb): Run both sequential stages for oblique photogrammetry data.
Explain Errors (dts_explain_error): Look up exit codes from Engine's error table.
Manage Jobs (dts_get_job, dts_list_jobs, dts_cancel_job): Monitor and control running publish jobs.
Artifact Management (dts_create_upload, dts_complete_upload, dts_artifact_status, dts_list_artifacts, dts_delete_artifact, dts_download_output): Upload, track, and download input/output data securely.
Job Files (dts_create_job, dts_job_types): Generate .aconf job configs for Engine's -jsonPath mode.
Provides tools to control DTS Engine 6.1 for generating 3D digital-twin tiles, including pipeline discovery, flag validation, publishing, error resolution, and job file creation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dts-mcp-server run the road pipeline using roads.shp, dom.tif, and dem.tif"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server and CLI for DTS Engine 6.1 and 7.0 (飞渡科技 / Freedo), a Windows GUI tool that produces 3D digital-twin tiles from shapefiles, oblique photogrammetry, DEM/DOM rasters, BIM, and point clouds.
Engine ships no SDK and no documented CLI. This project drives the 93-flag
command line that Engine's own GUI shell uses internally — recovered by
decompiling that shell, which is a managed .NET assembly. The full contract is in
docs/ENGINE_PROTOCOL.md.
Three interfaces over one core:
Remote MCP gateway (dts-mcp-server) — 14 tools over HTTPS with bearer
auth, plus a signed data channel for uploading inputs and collecting results.
This is how a macOS or Linux client drives a Windows-only product. See
docs/REMOTE.md.
Local stdio server (dts-mcp-server --stdio) — 8 tools, no TLS and no
data plane, for a client on the same machine that can pass host paths.
CLI (cli-anything-dts-engine) — subcommands plus a REPL, for humans and
shell scripts.
Windows. Engine is Windows-only.
DTS Engine installed and licensed. A required dependency, not optional:
this project drives the real EngineWorker.exe.
Python 3.10+.
The flag contract was recovered from 6.1; 7.0 drives the same command line
and publishes a valid .3dt, but its exit codes are less specific, so
dts_explain_error resolves fewer of them to a distinct cause. Discovery accepts
any tree holding EngineWorker.exe; core.install.KNOWN_MAJORS records only the
majors actually exercised, and the tests assert against it rather than a literal.
Related MCP server: SpatialGrid MCP Server
python -m venv .venv
.venv/Scripts/python.exe -m pip install -e ".[dev]"Engine is discovered automatically at %APPDATA%\DTS Engine\<version>. Override
with DTS_ENGINE_DIR when it lives elsewhere:
export DTS_ENGINE_DIR="D:/Users/you/AppData/Roaming/DTS Engine/7.0"On the Windows host:
Set-ExecutionPolicy Bypass -Scope Process # client Windows defaults to Restricted
.\scripts\bootstrap.ps1 # secrets, address, certificates
.\scripts\install_scheduled_task.ps1 # autostart at logon + firewall
.\scripts\start.ps1
.\scripts\status.ps1 # verifyRun these as the normal user, not elevated — only the firewall step needs administrator, and it self-elevates. An elevated shell would leave the gateway process running with rights it does not need.
Copy %LOCALAPPDATA%\DtsMCP\certs\ca.crt to the Mac, and read the bearer token
from %LOCALAPPDATA%\DtsMCP\config\server.env. The gateway sends only its leaf
certificate, so a client cannot pull the CA off the wire — it has to arrive out of
band. Verify it did by comparing digests on both ends:
# Windows. Hashes the DER encoding, not the file, so a CRLF/LF rewrite in transit
# does not change the answer.
[Security.Cryptography.X509Certificates.X509Certificate2]::new(
"$env:LOCALAPPDATA\DtsMCP\certs\ca.crt").GetCertHashString('SHA256')# Client. Same value, lower case.
openssl x509 -in ca.crt -outform der | shasum -a 256On the Mac:
./clients/macos/configure-macos.sh install --host <windows-ip> --ca ./ca.crt
./clients/macos/verify-connection.sh --host <windows-ip>That stores the token in the Keychain, publishes it to GUI apps via a
LaunchAgent, trusts the CA for SSL in the login keychain, and writes an
mcp.json naming the env var rather than embedding the secret:
{
"mcpServers": {
"dts": {
"type": "http",
"url": "https://192.168.50.170:8770/mcp",
"bearer_token_env_var": "DTS_MCP_TOKEN"
}
}
}That mcp.json is a reference shape, not a universal one. bearer_token_env_var
is not a field every client understands, so check what yours expects. Claude Code,
for one, wants the header spelled out, and will not find the CA in the login
keychain because Node keeps its own trust store:
claude mcp add --transport http dts https://<windows-ip>:8770/mcp \
--header "Authorization: Bearer $(security find-generic-password -a "$(id -un)" -s dts-mcp -w)"
export NODE_EXTRA_CA_CERTS="$HOME/Library/Application Support/dts-mcp/ca.crt"Without NODE_EXTRA_CA_CERTS the handshake fails with an error that names neither
the certificate nor the CA. The same applies on Linux, where
configure-macos.sh does not run at all: install the CA wherever the client's TLS
stack looks, and pass the token however that client accepts it.
The Windows host must stay logged in. Autostart is a logon scheduled task, not a Windows service, because Engine's licence check and GUI subsystem need an interactive session — session 0 will not do.
Read docs/REMOTE.md before using the data plane; it covers
uploads, artifact references, retention, and the security boundary.
Distinct from the Engine traps below: these cost a debugging session, not a failed publish.
The firewall rule is Private-profile only. If Windows has classified the
network as Public — the default for many Wi-Fi connections — the rule installs,
looks correct in Get-NetFirewallRule, and silently drops every client. Check
with Get-NetConnectionProfile and reclassify:
Set-NetConnectionProfile -InterfaceAlias <name> -NetworkCategory Private.
Scripts will not run under the default execution policy. Client editions of
Windows ship Restricted, which refuses every .ps1 with a SecurityError
that says nothing about policy scope. Set-ExecutionPolicy Bypass -Scope Process
fixes it for one shell without changing machine state.
Do not run bootstrap.ps1 from inside a sandboxed or packaged shell. Writes
to %LOCALAPPDATA% get redirected into that application's private container, so
a later start.ps1 from an ordinary shell reports the configuration missing
while the certificates sit somewhere else entirely.
The two servers expose overlapping but different sets — stdio is not a subset of remote. Five tools are common. The artifact and job families are remote-only, because only the gateway has a data plane and a queue; three are stdio-only, because that mode is free to accept and return host paths.
Remote (14) | stdio (8) | |
| ✓ | ✓ |
| ✓ | — |
| ✓ | — |
| — | ✓ |
Remote:
Tool | Purpose |
| Verify the install. Call this first. |
| The 9 pipelines, their flags, |
| Resolve an exit code through Engine's shipped table. |
| Begin an upload; returns a signed PUT URL. |
| Verify the digest and extract archives. |
| State and |
| Manage stored inputs. |
| Queue a publish job. |
| Queue OSGB, running both required stages. |
| Track work. |
| Signed GET URL for the result archive. |
For a client on the Windows host itself, skip TLS and the data plane entirely:
# data_agent/mcp_servers.yaml
dts:
transport: stdio
command: D:/adk/standalone/dts-mcp-server/.venv/Scripts/python.exe
args: ["-m", "dts_mcp_server", "--stdio"]Eight tools: dts_ping, dts_list_pipelines, dts_explain_error, dts_publish,
dts_publish_osgb, plus three with no remote equivalent — dts_validate
(pre-flight a flag set without running Engine), dts_create_job (write an .aconf
job file, the input for Engine's -jsonPath mode), and dts_job_types (the
.aconf data types, with the fields transcribed for each; a null fields means
that schema was never transcribed, so it is not validated rather than guessed at).
Path flags take plain host paths here, not artifact references.
cli-anything-dts-engine info
cli-anything-dts-engine --json pipelines
cli-anything-dts-engine --json errors --code 201
cli-anything-dts-engine run road --outpath ./out \
--set roadShp=roads.shp --set domPath=dom.tif --set demPath=dem.tifRun with no subcommand for a REPL. Agent-facing docs:
src/cli_anything/dts_engine/skills/SKILL.md.
Learned by probing a real install; each cost a failed run to discover.
road requires domPath even though the shell's base template omits it.
Without it: exit 201.
Input CRS must be projected. Geographic coordinates fail with 203/209/215.
shp is not a general vector converter. It builds vegetation/material
resources and wants tree attributes; a polygon shapefile fails with 302. Use
road or vtpk for general vector work.
OSGB needs two processes. Tiling then LOD pyramid. Use dts_publish_osgb
/ publish-osgb, not a bare osgbLod run.
Never drive EngineMaster.exe. It returns -1 (0xFFFFFFFF) instead of the
child's error code. This project always uses EngineWorker.exe.
Engine is not a GDAL wrapper. It bundles GDAL 3.0.5 for format I/O and reprojection only; LOD generation, mesh simplification, texture atlasing, and 3DT tiling have no GDAL equivalent.
src/dts_mcp_server/
app.py MCP at /mcp + artifact routes on one port
auth.py bearer verifier, artifact URL signer
config.py settings; secrets carry a minimum length
tls_bootstrap.py local CA + 825-day IP-SAN leaf
host_address.py one address for SAN, base URL and firewall scope
artifacts.py resumable upload, signed transfer, retention
workspace.py per-job sandbox, safe archive extraction
jobs.py queue, cancellation, host-path scrubbing
engine.py artifact references -> Engine flags
mcp_tools.py the 14 remote tools
stdio_server.py local-only mode (no TLS, no data plane)
scripts/ Windows deployment (bootstrap, start, firewall)
clients/macos/ configure-macos.sh, verify-connection.sh
src/cli_anything/dts_engine/
core/pipelines.py 9 pipelines, each citing its source line in the shell
core/errors.py parses Engine's shipped ~90-code error table
core/job.py .aconf job files, schema from Config*.cs
core/publish.py execution, incl. OSGB's two-stage sequence
utils/engine_backend.py invokes the real EngineWorker.exe
utils/udp_log.py Engine's UDP progress channel
docs/ENGINE_PROTOCOL.md the reverse-engineered contract
docs/TEST.md test plan, results, and coverage gapsexport DTS_ENGINE_DIR="…/DTS Engine/7.0"
.venv/Scripts/python.exe -m pip install -e ".[dev,test-fixtures]"
.venv/Scripts/python.exe -m pytest tests/ -v153 tests. Unit and gateway tests are pure and run anywhere; the E2E tier invokes the real Engine and fails rather than skips when it is absent — a harness that cannot drive the software is not working. Security tests encode attacker intent (path traversal, zip bombs, signed-URL replay, host-path leakage) rather than happy paths. One symlink test skips without the privilege to create one.
tests/remote_smoke.py is a separate end-to-end check against a running
listener, since TLS is terminated by uvicorn rather than by the app:
python tests/remote_smoke.py --base https://<host>:8770 --ca <ca.crt>See docs/TEST.md for the plan, results, and an honest list of
coverage gaps.
road is verified end-to-end and publishes a real .3dt tile. The other eight
pipelines have flag names transcribed from the decompiled shell but unconfirmed
input requirements; they report verified: false, and dts_list_pipelines says
so. Verifying them needs input data (OSGB datasets, .max scenes, .vtpk
packages, DTM job descriptions) not available on the development machine.
MIT.
Write an .aconf job file, the input for Engine's -jsonPath mode.
data_type is one of Terrain, Osgb, MAX, BIM, LAS, Material, Vector, Sea,
Skeletal, DTOModeData. Field names are the C# property names Engine expects
(e.g. RoadShpPath, OutputPath) — call dts_job_types to list the known ones.
Note: job-file mode is transcribed from the decompiled shell but has not been verified end-to-end. Prefer dts_publish for production work.
| Name | Required | Description | Default |
|---|---|---|---|
| out | Yes | ||
| fields | No | ||
| data_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently states that job-file mode is "transcribed from the decompiled shell but has not been verified end-to-end," which is a significant reliability caveat. It also directs users away for production. However, it does not describe what happens on success (e.g., whether files are overwritten) or error behavior, so it's not fully transparent, but the added caveat is valuable.
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 three sentences, each earning its place: the first states the core purpose, the second provides critical parameter details, and the third adds a necessary caveat and alternative. It is front-loaded with the most important information and contains zero wasted words.
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 complexity of the tool (job file generation with many field names), the description adequately covers the key aspects: purpose, data_type, field naming, alternatives, and reliability. It lacks return-value details or failure behavior, but with no output schema and sparse parameter schema, the description provides enough context for an agent to invoke the tool effectively, especially with the pointer to dts_job_types for exhaustive fields.
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 0%, so the description must compensate. It explains `data_type` with an explicit list of valid values (Terrain, Osgb, MAX, BIM, LAS, Material, Vector, Sea, Skeletal, DTOModeData) and clarifies that field names are C# property names Engine expects, with examples (RoadShpPath, OutputPath). This gives substantial meaning beyond the bare schema. However, the `out` parameter is not explicitly described, leaving a small gap.
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 opens with a specific verb and resource: "Write an .aconf job file, the input for Engine's -jsonPath mode." This clearly states the tool's function and distinguishes it from siblings like dts_publish (production publishing) and dts_job_types (listing field names). The purpose is unambiguous and uniquely identifies the tool's role.
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 provides usage guidance: "Prefer dts_publish for production work" gives a clear when-not-to-use alternative, and "call dts_job_types to list the known ones" directs to a complementary tool. It also warns that the mode is transcribed from decompiled shell and not verified end-to-end, implying caution. This exceeds simple context by naming specific alternatives and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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+).
ok reports whether the lookup succeeded. Whether the code means success
is indicates_success — do not conflate the two.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description provides critical behavioral details: it clarifies the semantics of `ok` versus `indicates_success`, warning against conflating lookup success with code success. This adds meaningful transparency about the tool's output interpretation.
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 compact and front-loaded with the primary purpose, followed by essential band mappings and a cautionary note. No superfluous words; each 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 a single parameter and no output schema, the description is quite complete: it explains the exit-code bands, the meaning of `ok`, and the separate `indicates_success` field. It lacks only a minimal example or explicit statement about return type, but overall it is sufficient.
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 `code` has zero schema-description coverage, but the description compensates by defining code ranges and bands, giving the integer parameter concrete meaning. This enables users to know what values to pass and what they represent.
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's function: explaining DTS Engine exit codes using a lookup table. This verb-resource pair is specific and distinct from sibling tools like dts_ping or dts_create_job, which perform other operations.
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 implies the tool should be used when one encounters a DTS Engine exit code and needs to interpret it. It does not explicitly state when not to use it or mention alternatives, but the distinct purpose makes the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List .aconf job data types and the fields transcribed for each.
A null fields means that type's schema has not been transcribed from the
decompiled shell, so its fields are not validated rather than guessed at.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It goes beyond a basic listing by transparently explaining that a null `fields` value means the schema has not been transcribed, so fields are 'not validated rather than guessed at.' This is a meaningful behavioral caveat that helps the agent interpret results correctly.
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 two sentences long, front-loaded with the core action and resource, and then adds a single valuable caveat. Every sentence earns its place, with no filler or 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 that this is a parameterless listing tool with no output schema, the description provides the essential context: what is listed and an important semantic note about null fields. It could be slightly richer by explicitly stating the expected output form (e.g., a list of type names with field arrays), but it is sufficient for a straightforward list operation.
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?
This tool has zero parameters and the input schema is empty, so there is nothing for the description to clarify. The baseline of 4 applies; the description appropriately focuses on the tool's purpose rather than inventing unnecessary parameter details.
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 begins with the specific verb 'List' followed by a precise resource: '.aconf job data types and the fields transcribed for each.' It clearly distinguishes this tool from siblings like dts_list_pipelines (pipelines) and dts_create_job (job creation), leaving no ambiguity about what dts_job_types does.
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 implies usage — if you need to see job data types and their transcribed fields, this is the tool — but it does not explicitly state when to prefer it over alternatives or mention any exclusions. For a simple listing tool, the implied context is adequate, yet there is no direct 'use this when' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the publish pipelines, their flags, and whether each is verified.
verified: true means the pipeline has been confirmed by a successful real
run. Unverified pipelines have correct flag names transcribed from the
decompiled GUI shell, but their required input combinations are unconfirmed —
expect to iterate on error codes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It goes beyond a simple list by defining 'verified: true' as confirmed by a successful real run and warns that unverified pipelines have unconfirmed input combinations and may require error-code iteration. This is valuable behavioral context that aids the agent's expectations.
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 two sentences, both necessary. The first states the function and scope, the second explains the meaning of the verified flag. There is no filler, and the key information is front-loaded.
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 zero-parameter list tool with no output schema, the description sufficiently conveys what the output contains (pipelines, flags, verified status) and explains the meaningful distinction between verified and unverified. It lacks an explicit return format but this is not critical given the tool's simplicity.
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 tool has zero parameters, so the schema trivially covers 100% of them. The description provides no parameter-specific details because there are none, matching the baseline of 4 for tools with no parameters.
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 uses a specific verb ('List') and names the exact resource ('publish pipelines') plus the details provided (flags, verified status). It is clearly distinct from sibling tools like dts_publish and dts_create_job, which perform actions rather than listing metadata.
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 implies the tool should be used to discover available pipelines and their verification status before creating a publish job, but it does not explicitly state 'use this when' or mention alternatives. The caveat about unverified pipelines and iterating on error codes offers context but no direct guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses what the tool does (checks installation/reachability), what it reports (Engine version, executables, bundled GDAL), and its critical dependency behavior (other tools fail without it). Lacks detail on error handling or return format, but for a simple ping this is substantial transparency.
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 three sentences long and every sentence adds value: purpose, usage instruction, and what is reported/dependency. No wasted words, and it is front-loaded with the primary 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 tool's simplicity (no parameters, no output schema), the description fully captures what an agent needs: the purpose, when to call, what output information to expect, and the critical dependency context. It is complete for selecting and invoking the tool 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?
The tool has no parameters, and the input schema is empty. Per the rubric, a baseline of 4 applies when there are 0 parameters. The description adds no parameter info needed, since there are none to explain.
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's function: 'Check that DTS Engine is installed and reachable.' It uses a specific verb (check) and resource, and distinguishes itself from siblings by positioning it as a first-step prerequisite ('Call this first', 'Every other tool fails if this one does').
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 is provided: 'Call this first' and 'Every other tool fails if this one does.' This makes it clear that the tool should be used before all other sibling tools, and implies it is a gate for the rest. This is strong when-to-use guidance even without naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a DTS Engine publish pipeline and report artifacts.
flags takes any of Engine's 93 flags without the leading dash, e.g.
{"roadShp": "roads.shp", "domPath": "dom.tif", "demPath": "dem.tif"}.
The verified workflow is pipeline="road", which drapes vector features onto
terrain. It needs a PROJECTED shapefile (geographic coordinates fail with
203/209/215) plus a DOM raster; domPath is mandatory despite looking
optional.
Success yields a .3dt tile plus DataInfor.txt. On failure, read error.band
and log — the UDP log usually carries a more specific message than the
exit code. Use dts_explain_error for any code.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| flags | No | ||
| strict | No | ||
| outpath | Yes | ||
| timeout | No | ||
| pipeline | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides detailed behavioral context: success yields .3dt tile plus DataInfor.txt, failure requires reading error.band and log, with UDP log carrying more specific messages. It also discloses that domPath is mandatory despite appearing optional, and that geographic coordinates fail with specific error codes.
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?
Well-structured with front-loaded purpose, followed by parameter examples, workflow requirements, success/failure behavior, and alternative tool guidance. Every sentence contributes meaningful information with no 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?
For a complex tool with no annotations and no output schema, the description covers the core workflow, required inputs, success/failure outputs, error debugging, and even alternative tool guidance. This fully equips an agent to invoke and interpret results for the primary verified path.
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 description adds substantial meaning for flags (93 flags, format example, mandatory domPath), strict (experimental flags), and pipeline (verified 'road' workflow). However, it does not explicitly clarify outpath or timeout, though their names and schema types are self-explanatory. Given 0% schema coverage, this is a strong but not perfect compensation.
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 states 'Run a DTS Engine publish pipeline and report artifacts' with a specific verb and resource. It clearly differentiates from siblings by directing OSGB users to dts_publish_osgb and error-code handling to dts_explain_error.
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 gives when-to-use: the verified workflow is pipeline='road', lists prerequisites (projected shapefile, DOM raster), and alternative tool guidance for OSGB and error explanation. It also explains when to set strict=False for experimental flags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. ok is true only if both stages succeed.
| Name | Required | Description | Default |
|---|---|---|---|
| flags | No | ||
| inpath | Yes | ||
| outpath | Yes | ||
| timeout | No | ||
| async_pyramid | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool runs two sequential stages and that 'ok' is true only if both succeed, which is useful. However, it omits other behavioral aspects such as side effects, overwrite behavior, or error handling, leaving gaps for an agent.
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 concise, with two short paragraphs that front-load the purpose and then add essential context. Every sentence is informative and no words are wasted.
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 has 5 parameters, no output schema, and no annotations, the description is incomplete. It explains the overall process but omits crucial details about parameter usage, return format, and how optional settings affect behavior, making it inadequate for full autonomous invocation.
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 0%, but the description does not mention any of the five parameters (inpath, outpath, flags, timeout, async_pyramid) or their meaning. It adds no value beyond what the bare schema shows, failing to compensate for the lack of parameter descriptions.
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 publishes oblique-photogrammetry OSGB data with a specific verb and resource. It also explains the two-stage process, distinguishing it from the sibling dts_publish tool which likely handles other data types.
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 implies usage for OSGB publishing and provides context that both tiling and LOD pyramid stages are required. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to understand when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| flags | Yes | ||
| pipeline | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that the tool runs locally and does not execute anything, which covers side effects. However, it does not specify what the tool returns upon success or failure, leaving the agent uncertain about how to interpret the result.
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 two sentences, front-loaded with the core action, and every phrase earns its place. It communicates functionality and benefits without fluff.
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 there is no output schema and no annotations, the description should explain what happens after validation. It states that it 'catches missing required flags and typos,' but does not describe the return value or error reporting format. For a simple validation tool, it is adequate but lacks critical details for a fully informed agent.
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 0%, and the description adds minimal semantic value beyond rephrasing 'flags' as 'flag set' and 'pipeline' as 'pipeline spec.' It fails to clarify the expected format of the pipeline string or the structure of the flags object, which is a significant gap.
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 a specific verb+resource: 'Check a flag set against a pipeline spec without running anything.' It distinguishes this from siblings like dts_publish by emphasizing it does not execute, making its validation role obvious.
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 says 'Cheap pre-flight' and explains it prevents malformed publishes from costing Engine time, which clearly implies it should be used before publishing. While it doesn't explicitly name alternatives, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0dts_create_jobdts_explain_errordts_job_typesdts_list_pipelinesdts_pingdts_publishdts_publish_osgbdts_validateEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Product Management
Autopilot MCP server for GEO analyses, reports, content, audits, memories and agents.
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhouning/dts-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
