Skip to main content
Glama
ThalesMMS

simple-dicom-mcp

by ThalesMMS

query_studies

Query DICOM studies using search criteria such as patient ID, date range, modality, or study description. Retrieve matching study results with customizable attributes.

Instructions

Query studies matching the specified criteria from the DICOM node.

This tool performs a DICOM C-FIND operation at the STUDY level to find studies matching the provided search criteria. All search parameters are optional and can be combined for more specific queries.

Args: patient_id: Patient ID to search for (supports wildcards), e.g., "12345678" or "123" patient_sex: Patient sex (F, M, O) patient_birth_date: Patient birth date or range in DICOM format: - Single date: "19700101" - Date range: "19700101-19801231" study_date: Study date or date range in DICOM format: - Single date: "20230101" - Date range: "20230101-20230131" modality_in_study: Filter by modalities present in study, e.g., "CT" or "MR" study_description: Study description text with wildcards. IMPORTANT: Use wildcards on BOTH sides for substring matching, e.g., "CHEST" to find "CT CHEST W CONTRAST". Using "CHEST*" only matches descriptions starting with "CHEST". accession_number: Medical record accession number (supports wildcards) study_instance_uid: Unique identifier for a specific study limit: Maximum number of results to return (None = no limit) attribute_preset: Controls which attributes to include in results: - "none": No attributes, use with additional_attributes (default) - "custom": Our custom attributes additional_attributes: List of specific DICOM attributes to include beyond the preset exclude_attributes: List of DICOM attributes to exclude from the results filters: Dictionary of DICOM tag names to filter values. Use this to filter by any DICOM attribute not in the standard parameters. Supports wildcards. Example: {"RequestedProcedureDescription": "CHESTANGIO*"}

Returns: Dictionary containing query results and status metadata. The results list includes entries like: { "StudyInstanceUID": "1.2.840.113619.2.1.1.322.1600364094.412.1009", "StudyDate": "20230215", "StudyDescription": "CHEST CT", "PatientID": "12345", "ModalitiesInStudy": "CT" }

Notes: Returns success False if the query fails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
patient_idNo
patient_sexNo
patient_birth_dateNo
study_dateNo
modality_in_studyNo
study_descriptionNo
accession_numberNo
study_instance_uidNo
limitNo
attribute_presetNonone
additional_attributesNo
exclude_attributesNo
filtersNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains the underlying operation (C-FIND), supports wildcards and date ranges, and notes that failure returns success=False. It does not cover auth or performance, but as a query tool, transparency is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-organized with clear sections and front-loaded purpose. While comprehensive, some parameter explanations could be slightly more concise, but overall it is highly informative.

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 (13 parameters, no annotations), the description covers parameter semantics, usage format, and return examples. It lacks explicit pagination details and comprehensive error handling, but is sufficiently complete for a query tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It provides detailed explanations, formats, examples, and wildcard guidance for all 13 parameters, adding significant meaning beyond the schema.

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 it performs a DICOM C-FIND at the STUDY level, distinguishing it from sibling tools like query_instances and query_series. It precisely indicates the resource (studies) and action (query), making the purpose unambiguous.

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 explains that all parameters are optional and combinable, and provides usage examples. However, it does not explicitly contrast with sibling tools or state when not to use this tool, which would further aid selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/ThalesMMS/simple-dicom-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server