OpenXnet Server

OpenXnet is SynapXnet's enterprise AI employee collaboration and governance platform. This repository contains its server-side MCP gateway, stable tool contracts, workspace-scoped evidence resources, approval controls, and auditable action records.

XnetAIOps, XnetDataOps, and XnetMLOps are product capabilities of the same SynapXnet ecosystem. They are connected through governed MCP adapters; they are not presented here as unrelated third-party products.

This public branch is the hardened GOAI competition server component. The full desktop experience lives in synapxnet/OpenXnet.

End-to-end role

flowchart LR
    Input["Enterprise task input<br/>alert · ticket · data · model"] --> Team["AgentTeams<br/>role orchestration and state tracking"]
    Team --> Skill["OpenXnet Skills<br/>reusable task capability"]
    Skill --> Gateway["OpenXnet Server<br/>MCP gateway and governance"]
    Gateway --> AIOps["XnetAIOps<br/>service and infrastructure evidence"]
    Gateway --> DataOps["XnetDataOps<br/>quality, lineage and workflow evidence"]
    Gateway --> MLOps["XnetMLOps<br/>model, probe and deployment actions"]
    AIOps --> Evidence["Evidence chain and shared context"]
    DataOps --> Evidence
    MLOps --> Evidence
    Evidence --> Decision["Neural-symbolic decision<br/>rules · risk · confidence · constraints"]
    Decision --> Approval["Human approval for high-risk actions"]
    Approval --> Verify["Independent verification · audit · rollback"]
    Verify --> Memory["Review, memory and Skill evolution"]

The separation is intentional: AgentTeams coordinates roles, Skills describe reusable capabilities, MCP connects external tools, and OpenXnet enforces workspace, permission, approval, evidence, and audit boundaries.

Related MCP server: nice

What this repository implements

Governed tool surface

The frozen 1.0.0 manifest exposes ten tools:

The high-risk rollback path requires an approval created by one subject and approved by another, plus expectedResourceVersion, reason, dryRun, idempotencyKey, and a matching parameter digest.

Repository layout

openxnet_mcp_gateway/   MCP protocol, security, registry, adapters and stores
contracts/              Canonical schemas, tool manifest and MCP fixtures
docs/goai-competition/  Handoff, test report and reproducible E2E trace sample
tests/                  Gateway protocol, governance and security tests
GOAI-RELEASE.md         Release component boundary and shared suite contract
SECURITY.md             Vulnerability reporting and secret-handling policy

Quick start

Requirements: Python 3.12 and uv.

git clone https://github.com/synapxnet/openxnet-server.git
cd openxnet-server
git switch GOAI-Competition
uv sync --python 3.12
uv run python -m openxnet_mcp_gateway

The gateway fails closed when signing secrets or the internal control token are absent. Supply credentials through the runtime secret manager, never through committed .env files. Adapter endpoints and all supported environment keys are documented in the implementation handoff.

Verification

uv run python -m unittest tests.test_openxnet_mcp_gateway -v

The gateway suite covers protocol versioning, scopes, origins, header/body confusion, token non-forwarding, single-tool delegation, approval separation, workspace isolation, SSE, response limits, timeouts, Dry Run, resource versions, parameter digests, idempotency, and process recovery. See the test report for passed checks and remaining production gates.

SynapXnet ecosystem

Release and security

• Release: OpenXnet GOAI Competition Suite goai-v1.1.0

• Component manifest: GOAI-RELEASE.md

• Security policy: SECURITY.md

• Third-party inventory: CycloneDX SBOM

• License: GNU Affero General Public License v3.0

The competition fixtures are reproducible samples and must not be represented as live production execution. External OIDC/JWKS rotation, shared transactional storage, browser integration tests, controlled real rollback, and performance sampling remain deployment acceptance gates.