Skip to content

How answers are shaped

The tools are written for agents. An answer should give what the standard says in fewer tokens than reading the source would, and say where it came from.

Every answer is markdown: a bold heading, a few facts, and tables where the standard has tables. It ends with one line naming the parts, sections or tables it came from and the edition:

Source: PS3.6 Table 6-1; PS3.3 Table A.3-1 (2026d)

There is no JSON envelope, confidence score or caveat. A Warning: line appears only when the answer is missing something the source has.

Text in the standard is full of references such as “See Section C.7.3.1.1.1 for Defined Terms”. The build resolves each one to its target, so the answer keeps the reference and an agent can follow it with dicom_read.

Modules include macros, and macros include other macros, so a fully expanded module can be several times longer than its own table. dicom_module answers with an outline by default: the module’s own rows, each macro as one line with its size, and descriptions cut to their first sentence and condition. The answer ends with the call that gives more.

dicom_iod lists modules until asked for attributes, and then expands only the M and C modules. Filters by Type, usage and module keep an answer to what a task needs, and each filtered answer ends with what it left out, so nothing is dropped silently.

When macros are expanded (dicom_module with detail = "full" or type, and dicom_iod with expand), each macro’s attributes go where it is included, with > marking sequence nesting. When the same macro is included again, it is marked “listed above” instead of being repeated.

Answers longer than about 16,000 characters (about 4,000 tokens) are split at block boundaries. Each page ends with the call for the next one:

Page 1 of 6. Next: dicom_iod("CT Image", expand=true, page=2).

dicom_read returns a section with all its subsections when they fit in one page. Otherwise it returns the section’s own text and lists the subsections to read next.

An unknown or ambiguous name never returns a guess. The answer says what was not found and lists the closest names, or the parts that share a section label, so the next call can pick one.

Answers suggest the follow-up call in MCP form, for example dicom_code("CID <n>") after a list of context groups. On the command line, run the command of the same name.