This is an MCP server for working with REMUS Jet (.rem) databases, offering CRUD, tracing, validation, XML transfer, and document rendering.
Project management: open, close, list projects; create new projects from templates; clone projects.
Entity operations: list, get, create, update, and delete entities of many REMUS types (actors, requirements, use cases, etc.).
Tracing: add/remove traces, get traces for an oid, and generate traceability matrices.
Validation & quality: validate projects and inspect change logs with undo support.
XML import/export: export project data/XML and import XML with merge/replace strategies and dry-run.
Rendering: render requirement/defect/change-request documents to HTML or PDF via Wine msxml3.
Transport & auth: run as stdio or Streamable HTTP/SSE with optional Bearer token authentication.
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., "@remus-mcp List the tables in the current REMUS Jet database."
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.
MCP server for REMUS Jet databases — stdio + Streamable HTTP/SSE, 100% Jet-compatible (mdbtools + Jackcess fallback).
cd mcp && uv sync
uv run remus-mcp --rem ../base/remus_base_empty_english.rem # stdio (Claude Desktop)
uv run remus-mcp --http --port 3000 --auth-token secret # HTTP http://127.0.0.1:3000/mcp
curl -H "Authorization: Bearer secret" http://127.0.0.1:3000/healthRelated MCP server: mudbase-mcp-server
Dockerfile at repo root (and mcp/Dockerfile — same content, repo-root context):
python:3.11-slim-bookworm + mdbtools + default-jre-headless + wine64 + winetricks + xvfb + wkhtmltopdf + uv.
Bakes mcp/, xml/remus.dtd, xslt/, base/*.rem, jars/, assets/transform.vbs.
Wine prefix at /opt/wine (WINEARCH=win32) lazy-initializes at container start (docker-entrypoint.sh → xvfb-run wineboot + winetricks -q msxml3, falls back to lxml if offline).
Containers run as the host user (user: "${UID:-1000}:${GID:-1000}" in compose) so files written to /data remain owned by the user, enabling direct editing with the original desktop app.
docker-compose.yml (repo root) — two services, one image, different transports:
Service | Transport | How to run | Port | Auth |
| stdio (local) |
| — | no auth |
| Streamable HTTP (remote, SSE fallback via SDK) |
|
|
|
| alias to http |
| 3000 | same |
# Build & run HTTP (recommended for Inspector / remote agents)
docker compose up --build remus-mcp-http
curl -H "Authorization: Bearer secret" http://127.0.0.1:3000/health # {"status":"ok"}
curl -H "Authorization: Bearer secret" http://127.0.0.1:3000/mcp | head # MCP handshake
curl http://127.0.0.1:3000/mcp | head # 401 {"error":"UNAUTHORIZED"} (when token set)
# stdio — attaches your terminal's stdin to the MCP stdio transport
mkdir -p data && cp base/remus_base_empty_english.rem data/project.rem
docker compose run --rm remus-mcp-stdio
# or manual:
docker build -t remus-mcp . # from repo root
docker run --rm -i --user $(id -u):$(id -g) -v ./data:/data remus-mcp uv run remus-mcp --rem /data/project.rem
# or from mcp/ (repo-root context required):
docker build -f mcp/Dockerfile -t remus-mcp .Data mounts: ./data:/data (your .rem files), ./base:/app/base:ro etc. are optional — the image already bakes base/ for project_create.
stdio via docker:
{"mcpServers":{"remus":{"command":"docker","args":["run","--rm","-i","--user","1000:1000","-v","/abs/path/to/data:/data","remus-mcp","uv","run","remus-mcp","--rem","/data/project.rem"]}}}HTTP (remote):
{"mcpServers":{"remus-http":{"url":"http://127.0.0.1:3000/mcp","headers":{"Authorization":"Bearer secret"}}}}SSE alias is identical (SDK negotiates streamable_http → SSE fallback automatically).
cd mcp && docker compose up --build remus-mcp-http # uses context: .. dockerfile: mcp/DockerfileClose a project
Inputs: project_id (required).
Export XML
Inputs: project_id (required), document, filter_ids, filter_type.
Get change log
Inputs: project_id (required), limit.
Get traces for oid
Inputs: oid (required), project_id (required), direction.
Import XML
Inputs: project_id (required), xml, dry_run, strategy, +3 more.
List open projects
Inputs: no named parameters.
Open a .rem project file
Inputs: path (required).
Clone project
Inputs: project_id (required), target_path (required).
Create new project from template
Inputs: name (required), template (required), target_path (required).
Create entity
Inputs: data (required), type (required), project_id (required).
Delete entity
Inputs: oid (required), type (required), project_id (required), cascade.
Get entity by oid
Inputs: oid (required), type (required), project_id (required).
List entities of a type
Inputs: type (required), project_id (required), limit, offset, +5 more.
Update entity
Inputs: oid (required), type (required), patch (required), project_id (required).
Render HTML/PDF via Wine msxml3
Inputs: document (required), project_id (required), lang, output.
Add trace
Inputs: project_id (required), source_oid (required), target_oid (required), checked.
Trace matrix
Inputs: project_id (required), source_type (required), target_type (required), document.
Remove trace
Inputs: project_id (required), source_oid (required), target_oid (required).
Undo last mutation
Inputs: project_id (required).
Validate project
Inputs: project_id (required).
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 20 tools
Each tool maps to a distinct action on a distinct resource: entities, traces, projects, or files. Even similar tools like get_traces and trace_matrix differ clearly in scope (per-entity vs. matrix-level), and the CRUD operations for entities and traces are unambiguous.
Naming mixes multiple patterns: rem_ prefix for entity operations, trace_ prefix for some trace operations (but get_traces and trace_matrix deviate), project_ prefix for some project tools (but open_project, close_project, list_projects don't follow). Generic verbs like validate_project, export_xml, undo_last break the prefix pattern. While still readable, the inconsistency is noticeable.
With 20 tools, the set is on the heavier side but each tool addresses a specific requirement in a comprehensive project/traceability management system. No redundant or dead-weight tools; the count is justified by the domain's complexity.
The tool surface covers the core lifecycle: project create/open/close/list/clone, entity CRUD, trace management, validation, import/export, history (undo/change log), and rendering. A notable gap is the lack of project deletion or explicit project update, but agents can work around this by cloning and closing projects.
MCP server for interacting with the Supabase platform
Project management shared by people and AI agents, with persistent project state through MCP.
Read and write shared BitsWeave context, projects, tasks, and work sessions through MCP.
An MCP server for search and retrieval over a local LanceDB database
