The DICOMweb MCP Server allows AI assistants to search, inspect, read reports, and render medical imaging data from a DICOMweb-compliant DICOM archive through natural language.
Search Studies (find-studies): Query DICOM studies using filters like patient name, date range, or modality; results sorted newest first.
Search Series (find-series): Find series within a study, filtered by modality, description, or other DICOM attributes.
Search Instances (find-instances): List instances within a series, sorted by instance number, with pagination support.
Find Structured Reports (find-structured-reports): Locate all Structured Report (SR) instances within a study.
Read Structured Reports (get-structured-report-text): Retrieve and convert SR documents into human-readable text.
Find Encapsulated PDF Reports (find-encapsulated-pdf-reports): Locate all encapsulated PDF documents within a study.
Read Encapsulated PDF Reports (get-encapsulated-pdf-report-text): Extract text content from encapsulated PDF DICOM instances (text-based PDFs only).
Inspect Instance Metadata (get-instance-metadata): Retrieve and display all DICOM attributes of a specific instance as human-readable text.
Render Image Frames (render-instance-frame): Render a specific frame from a DICOM instance as a base64-encoded JPEG or PNG image.
Advanced Query Syntax: Supports DICOM keyword names, 8-digit hex tags, wildcards, fuzzy matching, and pagination (limit, offset).
A Model Context Protocol (MCP) server that exposes a DICOMweb-compliant DICOM archive to AI assistants. It lets any MCP-capable client search studies, series and instances, inspect metadata, read Structured and Encapsulated PDF Reports, and render image frames — all through natural language.
Node.js 20 or later
A running DICOMweb server supporting QIDO-RS and WADO-RS (e.g. orthanc)
The following endpoints must be supported by the DICOMweb server:
Endpoint | Service | Used by |
| QIDO-RS | Search studies |
| QIDO-RS | Search series |
| QIDO-RS | Search instances, search structured reports, search encapsulated PDF reports |
| WADO-RS | Get instance metadata, get structured report text, get encapsulated PDF report text |
| WADO-RS | Render instance frame |
Related MCP server: DICOM MCP Server
npx dicomweb-mcp-serverThe server reads its configuration from a .env file located in the same directory as the script (see Configuration below).
npm install -g dicomweb-mcp-server
dicomweb-mcp-serverCreate a .env file with the connection details for your DICOMweb server. Place the file next to wherever the server is executed from (or in the working directory you configure in your MCP client).
# Required
DICOMWEB_HOST=https://your-dicomweb-server/dicomweb
# Optional — authentication
DICOMWEB_AUTH=basic # basic | bearer
DICOMWEB_USER=username # required when DICOMWEB_AUTH=basic
DICOMWEB_PASS=password # required when DICOMWEB_AUTH=basic
DICOMWEB_TOKEN=your-token # required when DICOMWEB_AUTH=bearer
# Optional — request timeout (milliseconds)
DICOMWEB_TIMEOUT=30000Variable | Required | Description |
| Yes | Base URL of the DICOMweb server (used for both QIDO-RS and WADO-RS requests) |
| No | Authentication type: |
| Conditional | Username — required when |
| Conditional | Password — required when |
| Conditional | Bearer token — required when |
| No | Fetch timeout in milliseconds. Omit to disable. |
Add the server to claude_desktop_config.json:
{
"mcpServers": {
"dicomweb": {
"command": "npx",
"args": ["-y", "dicomweb-mcp-server"],
"env": {
"DICOMWEB_HOST": "https://your-dicomweb-server/dicomweb"
}
}
}
}You can supply all environment variables directly in the env block instead of using a .env file.
Add to your VS Code settings.json or workspace .vscode/mcp.json:
{
"servers": {
"dicomweb": {
"type": "stdio",
"command": "npx",
"args": ["-y", "dicomweb-mcp-server"],
"env": {
"DICOMWEB_HOST": "https://your-dicomweb-server/dicomweb"
}
}
}
}Add to .cursor/mcp.json in your project root, or to the global ~/.cursor/mcp.json:
{
"mcpServers": {
"dicomweb": {
"command": "npx",
"args": ["-y", "dicomweb-mcp-server"],
"env": {
"DICOMWEB_HOST": "https://your-dicomweb-server/dicomweb"
}
}
}
}find-studiesSearches DICOM studies on the configured DICOMweb server. Results are sorted by study date, newest first.
Parameter | Type | Description |
| string | Space-separated |
Example prompts
"Find all CT studies for patient John Doe"
"Search for studies from January 2024"
find-seriesSearches DICOM series within a single study. Results are sorted by series date, newest first.
Parameter | Type | Description |
| string | Study Instance UID — obtain from |
| string | Space-separated |
find-instancesSearches DICOM instances within a single series. Results are sorted by Instance Number ascending.
Parameter | Type | Description |
| string | Study Instance UID — obtain from |
| string | Series Instance UID — obtain from |
| string | Space-separated |
find-encapsulated-pdf-reportsFinds all Encapsulated PDF instances in a study by looking for DOC-modality series and filtering by the Encapsulated PDF SOP Class UID (1.2.840.10008.5.1.4.1.1.104.1).
Parameter | Type | Description |
| string | Study Instance UID — obtain from |
Example prompts
"Find all PDF reports in study 1.2.3.4"
"Are there any encapsulated PDF documents in this study?"
get-encapsulated-pdf-report-textRetrieves an Encapsulated PDF DICOM instance and extracts its text content.
Parameter | Type | Description |
| string | Study Instance UID |
| string | Series Instance UID |
| string | SOP Instance UID — obtain from |
Note: Text extraction only works for searchable (text-based) PDFs. PDFs that consist entirely of scanned page images without an embedded text layer will yield little or no text. In those cases, no OCR is performed.
Example prompts
"Read the PDF report for SOP instance 1.2.3.4.5"
"What does the encapsulated PDF document say?"
find-structured-reportsFinds all Structured Report (SR) instances in a study by looking for SR-modality series and filtering by known SR SOP Class UIDs.
Parameter | Type | Description |
| string | Study Instance UID — obtain from |
get-structured-report-textRetrieves a Structured Report instance and converts it to human-readable text.
Parameter | Type | Description |
| string | Study Instance UID |
| string | Series Instance UID |
| string | SOP Instance UID — obtain from |
get-instance-metadataRetrieves and formats all DICOM attributes of a single instance as human-readable text. Does not retrieve pixel data.
Parameter | Type | Description |
| string | Study Instance UID |
| string | Series Instance UID |
| string | SOP Instance UID — obtain from |
render-instance-frameRenders a specific frame from a DICOM instance and returns it as an inline image (JPEG or PNG).
Parameter | Type | Description |
| string | Study Instance UID |
| string | Series Instance UID |
| string | SOP Instance UID — obtain from |
| integer | 1-based frame index (use |
| enum |
|
Example prompt
"Show me the first frame of SOP instance 1.2.3.4.5 as a JPEG"
The query parameter accepted by the search tools is a space-separated list of key=value pairs.
Key formats
Format | Example |
DICOM keyword name |
|
8-digit hex tag |
|
Special keys
Key | Description |
| Maximum number of results to return |
| Skip the first N results (for pagination) |
| Enable fuzzy (phonetic) name matching |
| Request all available DICOM attributes |
Examples
PatientName=DOE*
StudyDate=20240101-20241231 ModalitiesInStudy=CT
00100020=ABC123 limit=10
fuzzymatching=true PatientName=SmithWildcard * is supported in string values where the DICOMweb server allows it.
A natural conversational sequence with the MCP server looks like this:
Search studies — find-studies with a patient name or date range.
Browse series — find-series with the Study Instance UID returned in step 1.
List instances — find-instances with Study and Series UIDs from steps 1–2.
Inspect or render — get-instance-metadata for DICOM attributes, or render-instance-frame to view pixel data.
Read SR reports — find-structured-reports then get-structured-report-text for SR documents.
Read PDF reports — find-encapsulated-pdf-reports then get-encapsulated-pdf-report-text for Encapsulated PDF documents.
dicomweb-mcp-server is released under the MIT License.
Finds all Encapsulated PDF DICOM instances in a study by searching for DOC-modality series and filtering by EP SOP Class UIDs. Requires a Study Instance UID from find-studies.
| Name | Required | Description | Default |
|---|---|---|---|
| studyInstanceUid | Yes | DICOM Study Instance UID (e.g., 1.2.840.113619.2.55.3). Obtain from find-studies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses it performs a search/filter operation. Does not mention output format, permissions, or potential side effects, adequate for a simple query but not comprehensive.
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?
Single sentence conveys all necessary information without redundancy; front-loaded with verb and resource.
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 no output schema and one parameter, description is sufficient: explains what it does, how it does it, and input source. Lacks output details but those are implied by the tool name and sibling tools.
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 already fully describes the parameter with coverage 100%, so description adds marginal value by reinforcing the prerequisite. Baseline 3 is appropriate.
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?
Description clearly states it finds Encapsulated PDF DICOM instances in a study by searching DOC-modality series and filtering by EP SOP Class UIDs, differentiating it from siblings like find-instances (general) and find-structured-reports (structured reports).
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 requires a Study Instance UID from find-studies, providing clear context. Lacks explicit when-not-to-use or alternatives, but the sibling list implies usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches DICOM instances within a single series, sorted by Instance Number ascending. Requires Study and Series Instance UIDs from find-studies and find-series.
| Name | Required | Description | Default |
|---|---|---|---|
| studyInstanceUid | Yes | DICOM Study Instance UID (e.g., 1.2.840.113619.2.55.3). Obtain from find-studies. | |
| seriesInstanceUid | Yes | DICOM Series Instance UID (e.g., 1.2.840.113619.2.55.3.604688123). Obtain from find-series. | |
| query | Yes | Space-separated DICOM key=value search filters. Keys are DICOM keyword names or 8-digit hex tags (e.g., SOPClassUID=1.2.840.10008.5.1.4.1.1.2). Special keys: limit=N, offset=N. Pass an empty string to return all instances. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It mentions sorting by Instance Number ascending and scope within a series. Missing details on pagination (limit/offset only hinted via query parameter) and error behavior, but adequate for basic understanding.
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?
Two sentences, front-loaded with the main action and sorting, followed by prerequisites. No 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?
The description is sparse for a search tool without output schema. It does not describe return format (list of instance metadata) or explicit pagination behavior. References to sibling tools are helpful. It is functional but could be more complete.
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 descriptions cover 100% of parameters with detailed explanations, so the description adds little extra beyond context. Baseline of 3 is appropriate as the description confirms sorting and prerequisite usage without adding new parameter-specific meaning.
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 it searches DICOM instances within a single series and specifies ordering by Instance Number. It distinguishes from sibling tools like find-studies and find-series by scoping to a single series.
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?
It specifies prerequisites: requires Study and Series Instance UIDs from find-studies and find-series, implying a workflow. However, it does not explicitly state when not to use it or list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches DICOM series within a single study. Returns series sorted by series date, newest first. Does not retrieve instances or image data. Requires a Study Instance UID from find-studies.
| Name | Required | Description | Default |
|---|---|---|---|
| studyInstanceUid | Yes | DICOM Study Instance UID (e.g., 1.2.840.113619.2.55.3). Obtain from find-studies. | |
| query | Yes | Space-separated DICOM key=value search filters. Keys are DICOM keyword names or 8-digit hex tags (e.g., Modality=MR SeriesDescription=CHEST). Special keys: limit=N, offset=N. Pass an empty string to return all series. |
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 sorting order, scope (single study), and non-retrieval of image data. However, it does not mention pagination, error behavior, or rate limits, which are gaps for a query tool.
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?
Three sentences, each adding distinct information: purpose, sorting order, and constraint. No redundancy, and front-loaded with the main 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 two simple parameters and no output schema, the description covers usage constraints, input provenance (from find-studies), and what not to expect. It is adequate but could mention output structure (e.g., list of series UIDs).
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 100%, and the description adds meaning by explaining the query parameter's special keys (limit, offset) and the empty string behavior. This provides value beyond the schema's basic 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 it searches DICOM series within a single study, returns sorted results, and specifies it does not retrieve instances or image data. This distinguishes it from siblings like find-studies and find-instances.
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 requires a Study Instance UID from find-studies, implying the usage context after that tool. It also clarifies it does not retrieve instances or images, guiding the agent to other tools for those tasks, though it does not name them explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds all Structured Report (SR) DICOM instances in a study by searching for SR-modality series and filtering by SR SOP Class UIDs. Requires a Study Instance UID from find-studies.
| Name | Required | Description | Default |
|---|---|---|---|
| studyInstanceUid | Yes | DICOM Study Instance UID (e.g., 1.2.840.113619.2.55.3). Obtain from find-studies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'finds', implying a read operation, but lacks details on side effects, performance, or what exactly is returned (metadata or full objects).
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-loading the core purpose and including a usage prerequisite. Every word is necessary.
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 simple schema and no output schema, the description does not fully explain what the tool returns (e.g., list of instances, metadata). It leaves gaps but is partially compensated by sibling tool names.
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 100%, and the schema already describes the parameter. The description adds minimal value beyond mentioning the source tool, meeting the baseline.
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 it finds Structured Report DICOM instances by searching SR-modality series and filtering by SOP Class UIDs. It specifies the required input and distinguishes from siblings like find-encapsulated-pdf-reports.
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 mentions the prerequisite of a Study Instance UID from find-studies, but does not explicitly state when to use this tool versus alternatives like find-instances or find-series.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches DICOM studies on the configured DICOMweb server. Returns studies sorted by study date, newest first. Does not retrieve series, instances, or image data.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Space-separated DICOM key=value search filters. Keys are DICOM keyword names or 8-digit hex tags (e.g., PatientName=Doe* StudyDate=20200101-20201231 ModalitiesInStudy=CT 00100020=12345). Special keys: fuzzymatching=true, limit=N, offset=N. Pass an empty string to return all studies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it returns sorted studies and does not retrieve series/instances/images. However, it does not detail pagination behavior or authentication requirements beyond the parameter description.
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?
Two succinct sentences that front-load the primary action and key behavioral traits with no redundant information.
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 single parameter and no output schema, the description adequately covers the essential functionality, return value shape, and sorting order. It provides sufficient context for an agent to use 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?
Schema coverage is 100% and the schema parameter description is detailed. The tool description adds no additional parameter-level meaning, only overall tool behavior, so baseline of 3 is appropriate.
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?
Clearly states it searches DICOM studies on a DICOMweb server, returns sorted results, and explicitly lists what it does not retrieve (series, instances, images), distinguishing it from siblings like find-instances and find-series.
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?
Provides context of operation (searches on configured server, sorted by date) and implicitly indicates that for deeper data retrieval other tools should be used, but does not explicitly name alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves and converts an Encapsulated PDF instance to human-readable text. Requires Study, Series, and SOP Instance UIDs from find-encapsulated-pdf-reports. Does not retrieve image data.
| Name | Required | Description | Default |
|---|---|---|---|
| studyInstanceUid | Yes | DICOM Study Instance UID (e.g., 1.2.840.113619.2.55.3). Obtain from find-studies or find-encapsulated-pdf-reports. | |
| seriesInstanceUid | Yes | DICOM Series Instance UID (e.g., 1.2.840.113619.2.55.3.604688123). Obtain from find-series or find-encapsulated-pdf-reports. | |
| sopInstanceUid | Yes | DICOM SOP Instance UID (e.g., 1.2.840.113619.2.55.3.604688123.123.1591781234.469). Obtain from find-instances or find-encapsulated-pdf-reports. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as potential errors, size limits, or failure modes. The description only says 'converts', which is insufficient transparency for a tool with no annotations.
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 concise sentences, front-loaded with the main action, and no extraneous information. Every 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 no output schema and no annotations, the description covers purpose and prerequisites but omits details on output format, error handling, and performance. It is adequate but not thorough.
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 100% with detailed descriptions. The description adds context by specifying the UIDs must come from find-encapsulated-pdf-reports, which is more specific than the schema's mention of multiple sources.
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 retrieves and converts an Encapsulated PDF to human-readable text, using a specific verb and resource. It distinguishes from siblings like get-structured-report-text and render-instance-frame by specifying it's for PDF text only.
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 requires UIDs from a predecessor tool (find-encapsulated-pdf-reports) and clarifies it does not retrieve image data. It lacks explicit 'when not to use' but implies alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves and converts a DICOM instance to human-readable text. Requires Study, Series, and SOP Instance UIDs from find-instances. Does not retrieve image data.
| Name | Required | Description | Default |
|---|---|---|---|
| studyInstanceUid | Yes | DICOM Study Instance UID (e.g., 1.2.840.113619.2.55.3). Obtain from find-studies. | |
| seriesInstanceUid | Yes | DICOM Series Instance UID (e.g., 1.2.840.113619.2.55.3.604688123). Obtain from find-series. | |
| sopInstanceUid | Yes | DICOM SOP Instance UID (e.g., 1.2.840.113619.2.55.3.604688123.123.1591781234.469). Obtain from find-instances. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses conversion to text and non-image nature, but does not mention permissions, rate limits, response size, or error behavior. Adequate for a read-only retrieval tool, but lacks depth for complete 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?
Two sentences with no filler. First sentence states core function; second provides prerequisite and limitation. Every word earns its place.
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 3 parameters all documented, no output schema, and sibling tools listed, description covers what the tool does, its inputs, and what it doesn't do. Missing output format details, but for a conversion tool, this is acceptable. Overall, sufficiently complete for agent selection.
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 covers 100% of parameters with descriptions including examples and source instructions. Description adds context that UIDs come from find-instances, reinforcing schema. Since schema does most work, description still adds value, earning above baseline 3.
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?
Description uses specific verb+resource: 'Retrieves and converts a DICOM instance to human-readable text.' Clearly distinguishes from siblings like render-instance-frame (image) and get-structured-report-text (structured reports) by stating it does not retrieve image data.
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 states prerequisite: 'Requires Study, Series, and SOP Instance UIDs from find-instances.' Also clarifies limitation: 'Does not retrieve image data.' Lacks explicit mention of when to use alternative tools like get-structured-report-text, but context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves and converts a Structured Report (SR) instance to human-readable text. Requires Study, Series, and SOP Instance UIDs from find-structured-reports. Does not retrieve image data.
| Name | Required | Description | Default |
|---|---|---|---|
| studyInstanceUid | Yes | DICOM Study Instance UID (e.g., 1.2.840.113619.2.55.3). Obtain from find-studies or find-structured-reports. | |
| seriesInstanceUid | Yes | DICOM Series Instance UID (e.g., 1.2.840.113619.2.55.3.604688123). Obtain from find-series or find-structured-reports. | |
| sopInstanceUid | Yes | DICOM SOP Instance UID (e.g., 1.2.840.113619.2.55.3.604688123.123.1591781234.469). Obtain from find-instances or find-structured-reports. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It honestly states that it retrieves and converts SR to text and does not retrieve images. However, it lacks details on potential side effects (none expected for read), permissions needed, rate limits, or error behavior. The description is truthful but minimal for full 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 two sentences long, with the first stating the core action and result, and the second providing prerequisites and exclusions. Every sentence is informative and necessary. There is no wasted text, and 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 simple retrieval tool with fully-described required parameters and no output schema, the description covers the essential: what it does, what it needs, and what it doesn't do. Minor gaps exist, such as not specifying the output encoding or format, but these are acceptable given the simplicity. Overall, it is sufficiently complete for an agent to use 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 schema already describes all three parameters with 100% coverage, including format and examples. The tool description merely restates that UIDs are required, adding no new semantic insight beyond the schema. Therefore, the baseline score of 3 is appropriate.
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 verb 'retrieves and converts', the resource 'Structured Report instance', and the output 'human-readable text'. It also explicitly mentions what it does not do (retrieve image data), distinguishing it from sibling tools like render-instance-frame. This provides high purpose clarity.
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 explains the prerequisite: 'Requires Study, Series, and SOP Instance UIDs from find-structured-reports.' This tells the agent when to use the tool and what inputs are needed. It also clarifies that it does not retrieve images, guiding the agent away from using it for image data. However, it does not explicitly list when not to use it or suggest alternatives, so a slight deduction applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renders a specific frame from a DICOM instance to an image format. Requires Study, Series, and SOP Instance UIDs from find-instances, and a frame number. Returns the rendered image as a base64-encoded string.
| Name | Required | Description | Default |
|---|---|---|---|
| studyInstanceUid | Yes | DICOM Study Instance UID (e.g., 1.2.840.113619.2.55.3). Obtain from find-studies. | |
| seriesInstanceUid | Yes | DICOM Series Instance UID (e.g., 1.2.840.113619.2.55.3.604688123). Obtain from find-series. | |
| sopInstanceUid | Yes | DICOM SOP Instance UID (e.g., 1.2.840.113619.2.55.3.604688123.123.1591781234.469). Obtain from find-instances. | |
| frame | No | 1-based index of the frame to render (e.g., 1 for the first frame) | |
| outputFormat | No | Desired MIME type for the rendered output (e.g., image/jpeg) | image/jpeg |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns 'the rendered image as a base64-encoded string', which is critical behavioral info. No annotations are provided, so this description carries the full burden, and it adequately informs about the output format without contradictions.
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, directly stating the function and prerequisites. Every sentence adds necessary information without redundancy or 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 the straightforward nature of the tool and full schema descriptions, the description covers the returned output format and required inputs. It doesn't discuss error handling or performance, but that's acceptable for a simple rendering tool.
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 input schema has 100% description coverage, with each parameter's purpose already explained (e.g., 'DICOM Study Instance UID'). The description only mentions the UIDs and frame number generically, adding no significant new meaning beyond the schema.
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 'Renders a specific frame from a DICOM instance to an image format', specifying the resource (DICOM instance frame) and action (render). It distinguishes from sibling tools like find-instances (which retrieves UIDs) and get-instance-metadata (metadata retrieval).
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 instructs that Study, Series, and SOP Instance UIDs are required and that they come from find-instances. It also mentions the frame number. While it doesn't explicitly state when not to use the tool, the context is clear enough for typical use.
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.
find-encapsulated-pdf-reportsfind-instancesfind-seriesfind-structured-reportsfind-studiesget-encapsulated-pdf-report-textget-instance-metadataget-structured-report-textrender-instance-frameScored across 9 tools
Each tool targets a specific resource or action: studies, series, instances, encapsulated PDF reports, structured reports, and metadata/rendering. There is clear separation between find and get operations, and between different document types, preventing confusion.
All tool names follow a consistent verb-noun pattern with lowercase and hyphens (e.g., find-studies, get-instance-metadata, render-instance-frame). No mixing of conventions.
With 9 tools, the set is well-scoped for a DICOMweb server focused on querying and retrieving data. Each tool has a clear role, and the number aligns with typical best practices.
The server covers core query and retrieval operations for studies, series, instances, and special document types. Missing write operations (store, delete) and bulk retrieval, but for a read-oriented viewer, the surface is reasonably complete.
Hosted MCP server exposing US hospital procedure cost data to AI assistants
MCP server for searching Airweave collections with natural language queries.
Official remote MCP server for Archivist AI TTRPG campaign memory: characters, sessions, and more.
DocBase MCP server for AI agents
