An MCP server that lets an LLM read S1000D BREX (Business Rules Exchange) data modules and check data modules against those rules, reporting readable rule details and violation locations.
explain_brex — lists a BREX's rules: target XPath, whether forbidden/required/optional, allowed values and meanings, severity, and applicable schema context; filter by kind/context/search and page with offset/limit.
lookup_sns — explains what an SNS code (system / subsystem / sub-subsystem / assembly) means, from a DMC or codes directly, returning the matched hierarchy with titles.
lookup_value — explains what an element or attribute value means in the project and which values are allowed, optionally checking a specific value.
list_notations — lists allowed illustration/multimedia formats (base set, exclusions, per-schema redefinitions), and computes the effective set for a given schema context.
check_against_brex — checks a data module (or PM/comment) against a BREX, following the brexDmRef chain layer by layer, and reports each violation with XPath, line, actual value, rule ID and severity, plus manual checks for prose rules.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@s1000d-brex-mcp Check DMC-A320-A-00-00-00-00A-001A-D against the project BREX and list violations."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English | 日本語
An MCP server that lets an LLM read S1000D® BREX (Business Rules Exchange) data modules and check data modules against a BREX. It returns, in a form people can read, what a project or organisation has written in its BREX: which elements and attributes may be used, which values are allowed and what they mean, what the standard numbering system (SNS) codes mean, and which illustration formats may be used. It also reports whether a data module follows those rules, with the location of each violation.
This is a personal project and is not affiliated with ASD (Aerospace, Security and Defence Industries Association of Europe). S1000D® is a registered trademark of ASD.
The S1000D specification, XML schemas, default BREX and official samples are not included in any package or repository, because their terms of use do not grant redistribution. Obtain them froms1000d.org and point the S1000D_SPEC_DIR environment variable at the extracted folder.
Tool | Description |
| Lists the rules of a BREX. Returns the target (XPath), whether it may be used (forbidden, required or optional), the allowed values and their meaning, the severity level and the schemas the rule applies to. Narrow the list with |
| Returns what a standard numbering system (SNS) code refers to, from a DMC or a code |
| Returns what an element or attribute value means in the project, and which values are allowed |
| Returns the illustration and multimedia formats that may be used, split into the base set ( |
| Checks a data module against a BREX and returns each violation with its location (XPath and line number), actual value, rule ID, description and severity level. By default it follows the |
Related MCP server: solibri
It does not validate against the XML schema (XSD). Schema errors can hide BREX violations or create false ones. Run schema validation with validate_schema / verify_data_module in s1000d-verify-mcp.
It does not judge conformance to S1000D. passed: true from check_against_brex means only that no machine-checkable BREX rule was violated in every layer that could be resolved. nonContextRules (rules written as prose) are returned as manualChecks, and a person makes the judgement.
It does not interpret the meaning of severity level codes (brsl01 to brsl99). The project defines them, so they are returned as they are.
The absence of a rule in one BREX does not mean the absence of a restriction. A higher BREX (followed throughbrexDmRef, ending at the S1000D default BREX) or a business rules document written for people may restrict it. check_against_brex reports the layers it could not find in unresolvedBrex. Treat a result in which this field is not empty as incomplete.
Environment variable | Description |
| The folder where the S1000D distribution you obtained is extracted. The default BREX ( |
| The folder that holds the project's data modules. Several folders can be given, separated by |
Folders can also be added with the tool argument csdbDirs. A BREX can be given as a file path, as a DMC (the DMC- prefix is optional), or omitted (the default BREX).
If S1000D_SPEC_DIR / S1000D_CSDB_DIR are not set, the server reads the config file ~/.config/s1000d-stack/config.json (under XDG_CONFIG_HOME if it is set; S1000D_CONFIG changes the location). Claude Desktop does not pass environment variables to servers installed as plugins, and does not substitute ${VAR} written in the plugin's env. When you install the server as a plugin, write the folders here.
{
"specDir": "/path/to/s1000d/issue-7",
"csdbDirs": ["/path/to/your/csdb"]
}Environment variables take precedence when they are set. Paths that start with ~/ are accepted. The config file is read again on every call, so the server does not need to be restarted after you edit it.
{
"mcpServers": {
"s1000d-brex": {
"command": "npx",
"args": ["-y", "@shuji-bonji/s1000d-brex-mcp"],
"env": {
"S1000D_SPEC_DIR": "/path/to/s1000d/issue-7",
"S1000D_CSDB_DIR": "/path/to/project/csdb"
}
}
}
}The default is stdio. With --http the server starts over Streamable HTTP, so a CSDB product's server or a web application can call it over HTTP (the embedding foundation of stage 2.5).
npx -y @shuji-bonji/s1000d-brex-mcp --http # http://127.0.0.1:3000/mcp
npx -y @shuji-bonji/s1000d-brex-mcp --http --port 3100 --path /brexArgument | Default | Meaning |
|
| Address to bind to |
|
| Port; |
|
| Path of the MCP endpoint. |
| (see below) | Host names allowed in the |
| (see below) | Host names allowed in the |
When --host is a loopback address (127.0.0.1 / ::1 / localhost), Host and Origin are limited to localhost names (DNS rebinding protection). When bound to any other address they are not checked, so put the server behind the product's reverse proxy or authentication. Authentication, authorization and multi-tenancy are not part of this server. Environment variables and the config file work the same as with stdio.
The check follows Chap 4.10.2 (BREX data module) and Chap 7.9 (Business rules processing) of S1000D Issue 7. See the README of @shuji-bonji/s1000d-core for details.
Item | Handling |
|
|
| The blocks whose schema matches the target data module, and the common blocks, are applied |
| A violation if a NOTATION declared in the DOCTYPE is not in the allowed set |
Layers | Each layer is checked separately; the layers are not merged. |
npm install
npm run build
npm test # runs on self-made test data only
npm run test:spec # uses the S1000D distribution (set its location with S1000D_SPEC_DIR)MIT
Check a data module against BREX rules and report violations with location (XPath + line), actual value, rule id, objectUse text and severity. By default follows the data module's brexDmRef chain (project BREX → … → S1000D default BREX found under S1000D_SPEC_DIR) and checks each layer separately; pass "brex" to check against one specific BREX instead or in addition. Does NOT validate against the XML schema (XSD): run schema validation separately. nonContextRules cannot be checked automatically and are returned as manualChecks.
| Name | Required | Description | Default |
|---|---|---|---|
| xml | No | The data module as an XML string (alternative to path; max 5 MB). | |
| brex | No | A specific BREX (file path or DMC) to check against. With followChain=false it is the only layer; otherwise it is added to the chain. | |
| path | No | File path of the data module to check. | |
| csdbDirs | No | Extra folders to search for data modules and BREX by DMC (in addition to S1000D_CSDB_DIR and S1000D_SPEC_DIR). | |
| followChain | No | Follow the brexDmRef chain of the data module (default true). | |
| includeManualChecks | No | Include nonContextRules as manualChecks in each layer (default true). | |
| maxViolationsPerLayer | No | Cap on violations returned per layer (default 200). The total count is always reported. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses the default multi-layer BREX chain, per-layer checking, manualChecks for nonContextRules, and the exclusion of XSD validation. It does not explicitly state read-only safety or permission requirements, but the 'check' and 'report' wording strongly implies a non-mutating operation.
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 front-loaded with the core purpose and return details, then proceeds to default behavior, alternatives, and exclusions. Every sentence adds useful information without repetition or filler.
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?
It explains the return fields and manualChecks behavior despite there being no output schema, which is important for this multi-parameter tool. The main gap is that it does not state that at least one of xml or path must be supplied, since the schema has no required parameters.
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 description coverage is 100%, so the schema already documents all seven parameters in detail. The description adds some conceptual context about the brex parameter and the followChain behavior, but does not clarify csdbDirs, maxViolationsPerLayer, or the xml/path one-of choice beyond what the schema already says.
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 states a specific verb and resource: check a data module against BREX rules and report violations with concrete fields. It clearly distinguishes this from XML schema validation, but does not differentiate against the listed sibling tools such as explain_brex.
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 explains the default brexDmRef chain behavior, when to pass a specific brex, and that schema validation must be run separately. However, it does not explicitly route the agent between this tool and siblings like explain_brex or lookup_value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the rules of a BREX data module in readable form: for each rule, the target (XPath), whether it is forbidden / required / optional, the allowed values with their meanings, severity, and the schema context it applies to. Also returns the BREX header (DMC, parent BREX, counts). Use "kind" and "context" to narrow, "offset"/"limit" to page.
| Name | Required | Description | Default |
|---|---|---|---|
| brex | No | Which BREX to use: a file path to a BREX data module (.xml), or a DMC (e.g. "KENBAIKI-A-00-00-00-00A-022A-D", "DMC-" prefix optional) searched in csdbDirs / S1000D_CSDB_DIR / S1000D_SPEC_DIR. Omit to use the S1000D default BREX found under S1000D_SPEC_DIR. | |
| kind | No | Rule kind to list (default: all). | all |
| limit | No | Maximum rules to return (default 50, max 500). | |
| offset | No | Index of the first rule to return (default 0). | |
| search | No | Case-insensitive text to find in objectPath, objectUse, rule id or value meanings. | |
| context | No | Only rules that apply to this schema (file name such as "descript", "proced", "pm") plus the common rules. Omit for all contexts. | |
| csdbDirs | No | Extra folders to search for data modules and BREX by DMC (in addition to S1000D_CSDB_DIR and S1000D_SPEC_DIR). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the return payload in useful detail (per-rule fields plus the BREX header with DMC, parent BREX and counts) and the pagination model. It never states that the operation is read-only, nor what happens when the DMC lookup fails or the default BREX under S1000D_SPEC_DIR is missing, which matters for a 7-parameter tool with a filesystem search path.
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 purpose, no filler. The long enumeration of per-rule fields is dense but each item is meaningful content, so it earns its space.
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?
There is no output schema, and the description compensates by describing the returned rule structure and header, so an agent knows what it will get back. Combined with 100% schema coverage on all 7 optional parameters, nothing essential for calling it correctly is missing.
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%, so the baseline is 3. The description adds only the narrowing/paging roles for kind, context, offset and limit; it says nothing extra about 'brex' resolution or the 'search' matching semantics beyond what the schema already documents.
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 states a specific verb and resource ('List the rules of a BREX data module') and enumerates exactly what each rule entry contains (XPath target, forbidden/required/optional status, allowed values, severity, schema context) plus the header. It is clear on its own, but it never distinguishes itself from the sibling check_against_brex, which is the obvious alternative an agent would weigh.
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?
Guidance exists but is aimed at parameters, not at tool selection: 'Use kind and context to narrow, offset/limit to page' tells the agent how to shape the call. There is no statement of when to use this versus check_against_brex (inspect rules vs. validate a document), so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the illustration / multimedia notations (file formats) a BREX allows: the base set (common to all schemas) and the per-schema additions and exclusions. Pass "context" to get the effective set for one schema. Returns an empty base set when the BREX has no notation rules (then the BREX does not restrict notations).
| Name | Required | Description | Default |
|---|---|---|---|
| brex | No | Which BREX to use: a file path to a BREX data module (.xml), or a DMC (e.g. "KENBAIKI-A-00-00-00-00A-022A-D", "DMC-" prefix optional) searched in csdbDirs / S1000D_CSDB_DIR / S1000D_SPEC_DIR. Omit to use the S1000D default BREX found under S1000D_SPEC_DIR. | |
| context | No | Schema file name (e.g. "ipd", "proced") to compute the effective set for. | |
| csdbDirs | No | Extra folders to search for data modules and BREX by DMC (in addition to S1000D_CSDB_DIR and S1000D_SPEC_DIR). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it discloses the base-vs-per-schema split and the meaningful empty-base-set behavior. It does not mention error behavior if the BREX cannot be found, but the read-only listing intent is clear.
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 front-loaded and tightly written: it states the core listing behavior first, then the context parameter effect, then the empty-set caveat. Every sentence 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 no output schema and no annotations, the description adequately explains what is returned conceptually (base set plus per-schema additions/exclusions, and empty base set behavior). It does not fully specify the output structure, but it is sufficient for correct invocation.
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 description coverage is 100%, so the schema already documents all three parameters. The description adds some meaning by explaining that "context" computes the effective set for one schema, but otherwise does not go beyond the structured parameter documentation.
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 gives a specific verb and resource: listing the illustration/multimedia notations a BREX allows, split into base set and per-schema additions/exclusions. It clearly distinguishes the tool from sibling operations like explain_brex and check_against_brex by focusing on the allowed notation set.
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 explicitly tells the agent to pass "context" to get the effective set for a specific schema, and explains that an empty base set means the BREX does not restrict notations. It does not, however, state when to choose this tool over explain_brex or check_against_brex.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain what a Standard Numbering System (SNS) code means in a BREX: pass a DMC (the system / subsystem / sub-subsystem / assembly codes are taken from it) or the codes directly. Returns the matched hierarchy with titles; "exact: false" means only a prefix matched.
| Name | Required | Description | Default |
|---|---|---|---|
| dmc | No | A DMC whose SNS part should be looked up. | |
| brex | No | Which BREX to use: a file path to a BREX data module (.xml), or a DMC (e.g. "KENBAIKI-A-00-00-00-00A-022A-D", "DMC-" prefix optional) searched in csdbDirs / S1000D_CSDB_DIR / S1000D_SPEC_DIR. Omit to use the S1000D default BREX found under S1000D_SPEC_DIR. | |
| assyCode | No | Assembly code (2 or 4 characters). | |
| csdbDirs | No | Extra folders to search for data modules and BREX by DMC (in addition to S1000D_CSDB_DIR and S1000D_SPEC_DIR). | |
| systemCode | No | System code (2-3 characters), when not passing dmc. | |
| subSystemCode | No | Subsystem code (1 character). | |
| subSubSystemCode | No | Sub-subsystem code (1 character). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and does disclose the return format ("matched hierarchy with titles") plus the meaning of "exact: false" as a prefix-only match. It implies a read-only lookup, though it does not explicitly state permission or side-effect behavior.
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 compact and front-loaded, starting with the core purpose and then covering input modes and return semantics. Every clause contributes useful information without repetition.
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 seven-parameter tool with no output schema, the description adequately explains the input alternatives and the key return-shape signal ("matched hierarchy with titles"). It could say more about edge cases such as missing input or default BREX selection, but the rich schema covers most parameter details.
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%, so the schema already documents all seven parameters. The description still adds useful meaning by explaining that DMC supplies the system/subsystem/sub-subsystem/assembly codes and that "exact: false" indicates a prefix match.
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 names a specific verb ("Explain") and a specific resource ("Standard Numbering System (SNS) code") within a BREX. It also clarifies the two input modes, DMC-based or direct code-based, making the tool's role distinct from generic lookup or BREX explanation siblings.
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 states how to invoke the tool (pass a DMC or codes directly) but does not explicitly say when to use it versus siblings such as explain_brex or lookup_value. Usage is implied by the input alternatives rather than through clear inclusion/exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain what a value of an element or attribute means in a BREX, or list the allowed values. Pass "target" as an attribute name (e.g. "securityClassification"), an element name, or an XPath fragment; optionally "value" to check one value. Returns the matching rules with allowed values and their meanings, and whether the value is allowed.
| Name | Required | Description | Default |
|---|---|---|---|
| brex | No | Which BREX to use: a file path to a BREX data module (.xml), or a DMC (e.g. "KENBAIKI-A-00-00-00-00A-022A-D", "DMC-" prefix optional) searched in csdbDirs / S1000D_CSDB_DIR / S1000D_SPEC_DIR. Omit to use the S1000D default BREX found under S1000D_SPEC_DIR. | |
| value | No | The value to check against the allowed values (optional). | |
| target | Yes | Attribute name ("infoCode", "@infoCode"), element name ("language"), or XPath fragment to match against objectPath. | |
| context | No | Schema file name (e.g. "descript") to pick context-specific rules in addition to common ones. | |
| csdbDirs | No | Extra folders to search for data modules and BREX by DMC (in addition to S1000D_CSDB_DIR and S1000D_SPEC_DIR). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It does disclose the return content: matching rules, allowed values, meanings, and whether a value is allowed. It does not explicitly confirm read-only behavior, error conditions, or BREX source fallback behavior beyond what the schema already says.
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 front-loaded and efficient, moving from the core purpose to invocation details and return behavior. It is dense but not bloated; minor tightening is possible but not 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?
There is no output schema, but the description explains what is returned. The schema fully covers the five parameters, including BREX source resolution. The main missing piece is explicit routing guidance relative to 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 description coverage is 100%, so the baseline is 3. The description adds examples for target and value, but those forms are also covered by the schema descriptions, and the brex, context, and csdbDirs parameters are not elaborated in the description.
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 states a specific verb and resource: explain what an element/attribute value means in a BREX, or list allowed values. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as check_against_brex, which also concerns allowed values and validation.
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 explains how to invoke the tool with target and optional value, and gives examples such as "securityClassification". However, it does not state when to use this instead of check_against_brex or explain_brex, so the usage boundary is only implied.
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.
v0.4.0check_against_brexexplain_brexlist_notationslookup_snslookup_valueScored across 5 tools
The five tools have largely distinct purposes: notation listing, rule explanation, SNS lookup, value lookup, and data module checking. There is some overlap because explain_brex can also surface notation/value rules that list_notations and lookup_value return, but the descriptions make the intended scopes reasonably clear.
All tool names use consistent snake_case and begin with a verb (list_, explain_, lookup_, check_). The pattern is predictable across the set, even though the verbs vary appropriately by action.
Five tools is well-scoped for a BREX-focused MCP server. Each tool has a clear, non-redundant role: notation listing, rule explanation, SNS decoding, value interpretation, and validation.
The surface covers the main BREX workflows: inspecting rules, decoding SNS codes, interpreting values, listing notations, and checking data modules. Minor gaps exist, such as no dedicated way to enumerate all SNS codes or search rules by free text, but these are workable through existing tools.
Checks AI-written code against your rules as it is written, and keeps a record of what it found.
Check ISO 20022 messages (pacs.008, pain.001, camt.053, seev.031) against schema and rules.
Governance copilot for AI-assisted coding. 72 packs, 532 rules, proof bundles.
Check AI work against requirements and return structured verdicts, findings, and repair steps.
