Loading ToolBench
An MCP server for interacting with DICOM nodes, enabling C-ECHO verification and DICOM node discovery
Server has 3 tools with basic definitions and schemas. Tool names follow verb_noun convention (list_, dicom_cecho, dicom_cecho_by_name), which is good. However, descriptions lack actionable detail for LLM selection, parameters are sparsely documented, and output schemas are not declared. No error handling guidance is present. The tool names themselves are domain-specific but lack clarity around when to use dicom_cecho vs dicom_cecho_by_name without reading implementation code. Most concerning: no documentation of output structure, no guidance on error recovery, and descriptions are generic boilerplate. This is typical community server quality, functional but not LLM-optimized.
Perform a DICOM C-ECHO verification with a remote node Args: remote_ae_title: The AE title of the remote DICOM node ip: IP address of the remote node port: Port number of the remote node local_ae_title: The AE title to use for the local end (default: "MCP_DICOM") Returns: Dictionary containing success status and message
Perform a DICOM C-ECHO verification with a remote node using its configured name Args: node_name: The name of the remote node as configured in nodes.yaml local_ae_name: The name of the local AE title to use (default: "default") Returns: Dictionary containing success status and message
List all configured DICOM nodes from the nodes.yaml file Returns: Dictionary containing the list of nodes and their details
Output schemas not documented. No declared return type structure for any tool. LLMs cannot predict what fields to extract or chain downstream calls.
Parameter descriptions are minimal. 'node_name: The name of the remote node as configured in nodes.yaml' lacks guidance on how to discover valid names or what happens if the name doesn't exist. 'local_ae_name: The name of the local AE title to use (default: "default")' does not explain what AE titles are or where to find them.
Tool descriptions lack WHEN to use guidance. 'dicom_cecho' and 'dicom_cecho_by_name' appear to do nearly the same thing, one takes a name, the other takes resolved parameters. The descriptions do not explain: use the _by_name version if you already have a configured node, use the raw version if you have raw IP/port. This forces LLMs to reverse-engineer the distinction.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
No error handling guidance. If list_dicom_nodes returns an empty list, or dicom_cecho_by_name cannot find the node, responses contain only 'success: false' and a message. No indication of whether this is retryable, user-fixable (e.g. check nodes.yaml), or fatal. No suggestions for alternatives.
list_dicom_nodes input schema is empty ({}). The tool takes no parameters, but this should be explicitly documented in the description, e.g. 'Requires no parameters. Call this first to discover configured DICOM nodes.'
IP and port parameters lack constraints. 'port: Port number of the remote node' does not state valid range (1 - 65535). 'ip: IP address of the remote node' does not specify IPv4 vs IPv6 or validation rules. LLMs may pass invalid values.
No idempotency guarantee or side-effect declaration. dicom_cecho and dicom_cecho_by_name perform network I/O (C-ECHO). The description does not state whether this is read-only (diagnostic) or has side effects on the remote DICOM node. Risk field says READ_ONLY, but this is not replicated in the tool description.