S1000d Verify MCP Server

@shuji-bonji/s1000d-verify-mcp

English | 日本語

An MCP server that lets an LLM know, with evidence, how far an S1000D® data module has been checked. It performs three steps — validation against the XML schema (XSD), a check against BREX (Business Rules Exchange), and resolution of references (dmRef, pmRef, ICN, internalRef and applicRefId) — and returns the results combined into a single verification status (verification). This verification status has the same shape as the one s1000d-reader-mcp embeds in its content responses.

[!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. To run XSD validation and checks against the default BREX, obtain them from s1000d.org yourself and point the S1000D_SPEC_DIR environment variable at the extracted folder.

What it does

Verification status (verification)

schema-not-found is not valid. It means that XSD validation did not run.

What it does not do

[!WARNING]

• It does not decide conformance to S1000D. schema: valid and brex: passed mean only that no errors were found against the XSD and the BREX rules that a machine can check. nonContextRules (agreements written as prose) are returned as manualChecks, and a person makes the judgement. A project's business rules document is outside the scope of every tool.
• It does not return explanations of BREX rules or the meaning of values. That is the job of explain_brex / lookup_value in s1000d-brex-mcp. Severity level codes (brsl01 to brsl99) are returned as they are.
• It does not evaluate applicability (which product the content applies to). check_references only looks at whether the target of applicRefId exists. The evaluation is done by s1000d-reader-mcp. The exception is suggest_fixes with product, which reports only applicability that cannot be decided because the product lacks a value.
• It does not apply fixes to the document. suggest_fixes only returns candidates. Have the LLM choose among the candidates, and ask the user when confidence is none (the instructions say the same).
• It does not interpret DML values (dmlType / dmlEntryType / issueType). reconcile_dml compares identifiers and issues only; it does not verify the content of the listed objects (use verify_csdb for that).

[!NOTE] In a document that violates the XSD, elements may be in positions that differ from the specification, so BREX violations can be reported falsely or hidden. When schema.state is invalid, read the BREX results as a rough indication only (the response also says so in _notes).

Configuration

Folders can also be added with the tool argument csdbDirs.

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.

Configuration example for Claude Desktop / Claude Code

{
  "mcpServers": {
    "s1000d-verify": {
      "command": "npx",
      "args": ["-y", "@shuji-bonji/s1000d-verify-mcp"],
      "env": {
        "S1000D_SPEC_DIR": "/path/to/s1000d/issue-7",
        "S1000D_CSDB_DIR": "/path/to/your/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-verify-mcp --http                      # http://127.0.0.1:3000/mcp
npx -y @shuji-bonji/s1000d-verify-mcp --http --port 3102 --path /verify

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.

How it works

All validation logic lives in the shared library @shuji-bonji/s1000d-core; this server holds only the interpretation of arguments and the shape of the responses. XSD validation uses libxml2-wasm (the WebAssembly build of libxml2), and each XSD is compiled once and reused, so the 106 official samples of Issue 7 are validated in under 0.5 seconds. The BREX check calls the same functions as s1000d-brex-mcp, so the results of the two servers match.

Development

npm install
npm test            # runs with self-made test data only
npm run test:spec   # uses the distribution you obtained (set the location with S1000D_SPEC_DIR; default ../../specs/s1000d/issue-7)
npm run build && S1000D_SPEC_DIR=/path/to/issue-7 npm start   # starts over stdio

License

MIT. S1000D® is a registered trademark of ASD. This software is not affiliated with ASD and does not include the specification, schemas or official samples.