dts-mcp-server

by zhouning

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.3/5 across 8 of 8 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/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 `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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dts-mcp-server MCP server](https://glama.ai/mcp/servers/zhouning/dts-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/zhouning/dts-mcp-server)

Score Badge

Copy to your README.md:

[![dts-mcp-server MCP server](https://glama.ai/mcp/servers/zhouning/dts-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/zhouning/dts-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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