Skip to main content
Glama

build_data_module

Build a single S1000D data module or publication module from a structured draft, number it from allocation rules, and verify XML against XSD, BREX, and references with automatic fixes.

Instructions

Build ONE S1000D data module (descript / proced / process / fault) or publication module (pm) from a structured draft and number it from the allocation rules. You give titles, paragraphs, steps, tables, figures and references as a tree; the server writes the XML (you never write XML, DMCs, ICNs or the BREX reference). The XML is verified (XSD, BREX along the brexDmRef chain, references; applicability too when a product is given); fixes the server is certain about (confidence "exact") are applied automatically and verified again, up to maxFixRounds times. Returns xml, fileName, dmCode (pmCode for a pm), verification, appliedFixes[] (what was changed automatically), fixes[] (what remains: candidates to choose from), the updated ledger and the next ICN number. Writes into the CSDB only when write is true. A malformed draft comes back as error.code "input-error" with the path of the problem.

Input Schema

NameRequiredDescriptionDefault
draftYesThe data module as a tree. kind decides which node kinds are accepted.
writeNoWrite the result into the CSDB (the first folder of csdbDirs / S1000D_CSDB_DIR). Default false: the XML is only returned. Nothing is written when the XML is not valid against the XSD unless allowInvalid is true.
productNoThe product to evaluate applicability for. attributes: ACT productAttribute id → value; conditions: CCT cond id → value. Omit to skip the applicability check.
csdbDirsNoCSDB folders (in addition to S1000D_CSDB_DIR) used to resolve references, find BREX and number new objects. The FIRST folder is also where write: true writes.
maxFixesNoCap on the remaining fixes listed in the response (default 50).
overwriteNoWith write: true, replace a file of the same name. Default false: an existing file is left alone and reported as write-conflict.
allocationYesNumbering rules and the ledger. Pass the ledger of the previous response back so that the same sourceId keeps the same DMC and the same asset keeps the same ICN.
issuePolicyNoWhen the CSDB already has the same data module and the draft gives no issueInfo: raise issueNumber (default), raise inWork, or keep the issue.increment-issue
allowInvalidNoWith write: true, write even when verification.schema.state is "invalid". Default false.
assetFormatsNoFile format of each figure original, by assetId (or ICN): { extension: "PNG", notation: "png", publicId? }. Default: taken from the original file name for known formats (png, jpg, gif, svg, cgm, pdf).
maxFixRoundsNoHow many times to apply the fixes the server is certain about (confidence "exact") and verify again (default 3). 0 turns automatic fixing off.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does: it discloses the verification chain (XSD, BREX along brexDmRef, references, applicability), the bounded auto-fix loop with confidence "exact" and maxFixRounds, the two-tier fix reporting (appliedFixes vs fixes), write gating on write:true, and the input-error code. It also states the server keeps no state and the ledger must be round-tripped.

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

Conciseness5/5

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

Front-loaded with the action and scope in the first clause, then verification behavior, then return values, then the write gate, then the error case — a sensible priority order. It is long but nearly every clause carries information; the 'you never write XML, DMCs, ICNs or the BREX reference' aside earns its place by preventing wasted effort.

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?

With 11 parameters, deep nesting and no output schema, the description correctly enumerates the return shape (xml, fileName, dmCode/pmCode, verification, appliedFixes, fixes, ledger, next ICN) and the failure mode. The remaining gap is routing the residual fixes[] to the sibling apply_fixes, and any note on required CSDB directory setup.

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

Parameters3/5

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

Schema description coverage is 100%, so both the draft tree and allocation are already documented field by field. The description adds framing (you supply titles/paragraphs/steps/tables/figures/references, never XML/DMC/ICN/BREX text) and names maxFixRounds, but contributes no new per-parameter semantics. Baseline 3 is right.

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?

States a specific verb and resource — build ONE data module of a stated set of kinds or a publication module — from a structured draft, and says the DMC/PMC comes from allocation rules. The scope (one object per call) and the output artifacts are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the description never says when to pick this over the sibling apply_fixes for leftover fixes[], nor when to re-run rather than patch. The write:false / write:true split hints at a preview-then-commit workflow but requires the agent to infer it.

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