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 MCP Server Validate the XML schema of data modules in the 'dm' directory."
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.
An MCP (Model Context Protocol) server that gives an LLM agent a working toolset for reviewing S1000D technical publications — the structured-authoring XML standard used across aerospace and defense for maintenance and engineering documentation.
S1000D content is authored as small, modular XML units called data modules, each identified by a structured Data Module Code (DMC), validated against publicly published XML schemas, cross-referenced against other data modules and graphics, and filtered by an applicability model that says which content applies to which product variant or configuration. In a real authoring environment, tools like Arbortext Editor, Windchill, and DevTrack handle schema validation, cross-reference integrity, applicability checking, and change-impact tracking as separate, disjoint steps in someone else's workflow.
This project reimplements the spirit of that tooling as a set of MCP tools an LLM
agent can call directly — and then chains those tools into a single agentic review
workflow via a SKILL.md — using only public S1000D schema documentation and
entirely hand-built, non-proprietary sample data modules. No proprietary or
work-related content is used anywhere in this repository.
Related MCP server: BigContext MCP
Tool | Purpose |
| Validate a data module against the public S1000D XSD; return structured errors with line numbers. |
| Parse a directory of data modules, build a reference graph (DMC / graphic references), flag dangling or orphaned references. |
| Scaffold a new, schema-valid empty data module from a template, given DMC parts, info code, and title. |
| Validate applicability annotations against a sample Applicability Cross-reference Table (ACT). |
| Given a validation error and its surrounding XML context, call the Anthropic API (with an S1000D-authoring-rules system prompt) for a suggested corrected snippet and explanation. |
On top of the individual tools, a review-data-module SKILL.md chains them into one
workflow: validate → check cross-references → check applicability → suggest_fix for
each failure → summarize findings in a report.
🚧 Early development — see the roadmap below and the repo's Issues for what's in progress.
Language: Python (3.10+), managed with uv
XML validation: lxml against the public S1000D XSD
LLM: Anthropic API (Claude)
MCP: the official Python MCP SDK
Testing: pytest, against a small hand-built corpus of sample data modules
(some valid, some deliberately broken)
CI: GitHub Actions running pytest on push
git clone https://github.com/i2oss/s1000d-mcp.git
cd s1000d-mcp
uv syncRun the server:
uv run s1000d-mcpAdd to your MCP client config (e.g. claude_desktop_config.json):
{
"mcpServers": {
"s1000d": {
"command": "uv",
"args": ["--directory", "/absolute/path/to/s1000d-mcp", "run", "s1000d-mcp"]
}
}
}Core tool set (schema validation, cross-references, skeleton generation,
applicability, suggest_fix)
review-data-module SKILL.md
GitHub Actions CI
v0.1.0 release
DITA schema support
Simplified Technical English (STE)-style rule linting
CLI wrapper
Built by Ross Shelton as a demonstration of agentic AI
development — MCP tooling and Claude SKILL.md workflows — applied to a real
technical-documentation problem, drawing on experience authoring S1000D-compliant
content professionally. All sample data modules in this repo are fictional and
non-proprietary.
MIT — see LICENSE.
Health-check tool: echoes a message back with a server tag.
Used to confirm the server is reachable and a tool call round-trips correctly, before real S1000D tooling is added.
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | hello from s1000d-mcp |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It states the tool echoes a message back with a server tag, implying no state changes or side effects. It also frames the tool as a temporary placeholder, which is useful behavioral context. It doesn't detail failure modes, but for a simple health-check ping, the behavior is transparent enough.
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 two sentences with no redundant phrasing. The first sentence front-loads the primary behavior, and the second adds the usage context. Every word earns its place, making it an example of concise yet informative documentation.
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 simple tool with one optional parameter, no annotations, and no sibling tools, the description covers purpose, usage, and behavior sufficiently. The presence of an output schema means return value explanation is unnecessary. The description even notes this is a precursor to future S1000D tooling, which gives the agent clear context on when to invoke it.
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 0%, so the description must compensate for the undocumented 'message' parameter. The phrase 'echoes a message back' directly relates the message parameter to the tool's function, adding some semantic meaning. However, it does not describe formatting, constraints, or the default value, and the parameter semantics are left mostly to inference from the parameter name and schema.
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 opens with 'Health-check tool' and specifies the exact behavior: 'echoes a message back with a server tag.' This clearly distinguishes it as a connectivity/round-trip verification tool, and the purpose is not lost in vague language. Even though there are no sibling tools to differentiate from, the description fully states what the tool does.
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 explicitly states when to use it: 'Used to confirm the server is reachable and a tool call round-trips correctly, before real S1000D tooling is added.' This gives a clear usage context. It does not mention alternatives, but with no sibling tools that would be unnecessary, so the guidance is adequate.
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.1.0pingScored across 1 tool
With only one tool, there is no possibility of confusion or overlap. The ping tool has a clearly distinct purpose as a health-check.
A single tool named 'ping' uses a clear, standard convention. There are no mixed styles or inconsistent patterns to penalize.
The server is named for S1000D but provides only a trivial ping placeholder. This is an extreme mismatch for the apparent domain scope.
No actual S1000D functionality is exposed; the description explicitly states the tool is a placeholder before real tooling is added. The surface is severely incomplete.
Preflight QA for AI-agent deliverables with structured verdicts and repair guidance.
Public agentic AI doctrine tools plus authenticated architecture, design, and spec validators.
Deterministic validation for AI-generated artifacts: JSON Schema, OpenAPI response, SQL syntax.
Versioned documentation registry and semantic search for AI tools and coding assistants.