MCP server plugin for Codex that provides integration with DTS (Distributed Testing System) services via HTTP transport with bearer token authentication
Critical gaps across all dimensions. Tool definitions are inferred from names and brief descriptions only, no explicit schema definitions visible in source code. Descriptions are minimal (10-20 chars), far below the 50-200 char baseline for LLM-optimized tools. No parameter schemas, types, or constraints documented. No output schemas visible. Error handling and recovery guidance absent. Tools lack the structure needed for reliable agent composition.
Get the status of a DTS artifact
Cancel a DTS job
Complete an upload session for DTS
Create a new upload session for DTS
Delete a DTS artifact
Download output from a DTS job
Explain a DTS error
Get details of a DTS job
No input schemas visible in source code. All 14 tools lack documented parameter types, constraints, and descriptions.
Tool descriptions are 10-20 characters (e.g., 'Ping the DTS service to verify connectivity'). Baseline is 50-200 chars for LLM-optimized tools. No WHEN to use, no prerequisites, no dependencies documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | 2026-07-28+ | v2 |
List DTS artifacts
List DTS jobs
List available DTS pipelines
Ping the DTS service to verify connectivity
Publish content to DTS
Publish OSGB content to DTS
No output schemas documented. LLMs cannot infer what fields to expect from tool responses, breaking downstream tool chaining. E.g., dts_list_artifacts should document whether it returns artifact_id, artifact_name, status, created_at, etc.
Destructive tools (dts_delete_artifact, dts_cancel_job) lack confirmation/dry-run patterns and error recovery guidance. No documentation of what happens on failure or how to undo.
Tool definitions are inferred from names and brief descriptions only, no explicit tool registration with schemas visible in provided source.