S1000D BREX (S1000D Stack)

@shuji-bonji/s1000d-brex-mcp

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.

[!IMPORTANT] 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 from s1000d.org and point the S1000D_SPEC_DIR environment variable at the extracted folder.

What it does

What it does not do

[!WARNING]

• 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.

[!NOTE] The absence of a rule in one BREX does not mean the absence of a restriction. A higher BREX (followed through brexDmRef, 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.

Configuration

Folders can also be given with the tool argument csdbDirs. When the argument is given, only those folders are used; S1000D_CSDB_DIR and csdbDirs in the config file are not used (they are not added together). The default BREX is still looked up under S1000D_SPEC_DIR. Folders that do not exist are skipped and listed in _notes of the response. A BREX can be given as a file path, as a DMC (the DMC- prefix is optional), or omitted (the default BREX).

A mistake that the caller can fix by changing an argument is returned not as a tool failure (isError) but as error: { code, path, detail }, the same shape as the other S1000D Stack servers. code is one of file-not-found (no such file), not-found (the BREX given by DMC, or the default BREX, was not found) and input-error (an argument is malformed or missing), and path names the argument to fix (/brex, /path and so on).

Config file (when environment variables are not passed, as with plugins in Claude Desktop)

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.

Example configuration for Claude Desktop / Claude Code

{  "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"      }    }  }}

Running over HTTP (embedding in a product)

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/mcpnpx -y @shuji-bonji/s1000d-brex-mcp --http --port 3100 --path /brex

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.

Check rules

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.

Development

npm installnpm run buildnpm test            # runs on self-made test data onlynpm run test:spec   # uses the S1000D distribution (set its location with S1000D_SPEC_DIR)

License

MIT