Adding an MCP Server to NeuralWikis.com with UAIX Guidance

Full report

On this page

Executive summary

UAIX does not currently publish a UAIX-branded, general-purpose MCP server that you can simply install on a website. Its public record says the currently published implementation lanes are a WordPress Publication Track and a .NET Bridge Track, while a public SDK, CLI, standalone source repository, and general-purpose reference server are explicitly not yet published. UAIX also defines MCP in the ordinary Model Context Protocol sense: MCP owns local or host-bound tool, resource, and prompt sessions, while UAI-1 owns the portable, citable exchange/evidence record that can sit beside MCP, A2A, OpenAPI, and other runtime systems. In other words, UAIX guidance is about how to publish, document, constrain, validate, and evidence an MCP-backed surface, not about installing an official UAIX “MCP product.”

NeuralWikis already exposes a substantial agent-facing surface: human-readable agent docs, machine-readable manifests, public JSON endpoints, a public agent card, and a dedicated MCP Control Surface page that describes “a JSON-RPC surface for public resources and authenticated tools.” Its agent docs also say new agents should read /llms.txt, /ai-router.json, /.well-known/openapi.yaml, /api/schemas, and /api/exchange, and that protected mutation routes require operator-issued credentials. That means NeuralWikis is not a greenfield MCP effort; the more likely task is to make the documented MCP surface operationally solid, externally reachable, and aligned with UAIX’s publication, fallback, security, consent, and evidence rules.

The strongest public hosting signal for NeuralWikis is that its IP resolves to 66.29.148.170, whose PTR is server55-1.shared.spaceship.host, announced by Namecheap ASN; search results tie neuralwikis.com to that same IP. Separately, ecosystem-maintainer documents repeatedly describe related sites as deploying WordPress theme packages plus separate root-static discovery files, and include NeuralWikis in that broader WordPress-oriented ecosystem checklist. The highest-confidence conclusion is therefore: likely shared hosting on Namecheap/Spaceship, with a moderate probability that the site itself is WordPress-based or at least managed in a similar packaged WordPress/root-static model. That said, public evidence does not disclose the exact account plan, SSH availability, reverse-proxy support, or whether long-running app processes are permitted on the current host.

Because UAIX separates runtime execution from publication/evidence, the safest deployment pattern for NeuralWikis is usually this: keep the existing site as the public documentation + discovery + read-only JSON layer, and run the actual MCP server as either a sidecar process on a VPS or a containerized service on separate infrastructure, then expose it via mcp.neuralwikis.com or a reverse-proxied /api/mcp path. If the current hosting account turns out to be strict shared hosting without SSH daemons, reverse proxy, Passenger, Node/Python app support, or container support, the best path is not to force the MCP process onto that account, but to host MCP elsewhere and update the site’s manifests/docs to point at it. That recommendation fits UAIX’s published boundary that runtimes execute elsewhere while the standards/publication surface carries the reviewed communication, trust, evidence, and handoff boundary.

UAIX guidance and published requirements

The primary UAIX pages that matter for this work are Get Started, Standards Fit, UAIX vs MCP vs Webhooks, Capability-Adaptive Web Interaction, Chatbot Access, Minimal Access Tier, GET-Action Security, API Reference, Validator, Policy and Security, WordPress Publication Track, .NET Bridge Track, and .NET NuGet Package. Those are the authoritative pages for scope, implementation boundaries, route patterns, security headers, capability levels, fallback behavior, and currently published package versions.

A concise reading of UAIX’s official position is this: use MCP when the problem is session-local access to tools, resources, prompts, or application context; use UAI-1/UAIX when the thing you need is a portable, reviewable, citable record with validation, provenance, trust posture, and release evidence; and use both together when runtime action must later become durable evidence. UAIX’s own wording is explicit that UAI-1 records portable exchange evidence while adjacent protocols keep their runtime jobs, and that a runtime/tool/event layer can do the work while UAIX carries the reviewable boundary as evidence.

The most important operational constraint is that UAIX does not publish an official “reference server” or broad runtime-support catalog today. What it does publish is a public launch surface composed of canonical pages, machine-readable routes, schemas, registry entries, examples, validator output, OpenAPI, conformance packs, and named implementation tracks. That means any deployment plan for NeuralWikis must distinguish clearly between your MCP runtime and the UAIX-aligned publication/evidence surface that documents and constrains it.

Published requirements matrix

UAIX does not publish exact requirements for OS version, Linux distribution, container base image, CPU/RAM minimums, database engine, certificate vendor, specific inbound port numbers beyond HTTPS expectations, or mandatory service account names. It also does not publish a universal runtime assurance or managed trust service. The exact published requirement is instead: keep HTTPS, security headers, .well-known delivery, sitemap/delivery behavior, and machine-facing route behavior aligned before widening support claims.

For config-like artifacts, UAIX’s public record most strongly emphasizes discovery files and machine-readable records: .well-known manifests, route catalogs/discovery, schemas, registry, examples, validator, OpenAPI export, adoption kit, conformance pack, and capability manifests. In repo-local handoff scenarios it also publishes AGENTS.md and .uai/* files, but those are durable memory/handoff records, not hosted runtime endpoints.

NeuralWikis environment audit

NeuralWikis publicly presents itself as an agent-facing exchange rather than a human guide site, and its homepage exposes a long list of machine-readable files and APIs including /.well-known/neuralwikis-agent.json, /.well-known/agent-card.json, /trust-policy.json, /api/kb/catalog, /api/kb/context, /api/ask, schema routes, validation tools, compatibility tools, workspace status routes, and an “Agent API” page. Its homepage also explicitly says “MCP-ready control plane,” and its protocol section says NeuralWikis presents MCP as the normalized control-plane concept for tool and context access.

The site’s own machine manifest says public discovery endpoints are unauthenticated, while write/review routes require configured bearer tokens and CSRF controls where browser-origin writes apply. The same manifest lists many public machine-readable endpoints, trust gates, and safety boundaries such as “No blind imports” and “No direct production memory mutation from public intake.” That aligns tightly with a split between read-only public discovery/resources and authenticated, operator-controlled tools, which is also how UAIX recommends capability escalation.

The Agent API page is especially important. It says AI clients should use its quickstart order first, then machine-readable endpoints for routing, payloads, schemas, previews, metrics, and MCP. It names /api/mcp in the core endpoints list, and the dedicated /docs/mcp page describes an MCP Control Surface as “a JSON-RPC surface for public resources and authenticated tools,” with public resources under neuralwikis://exchange, neuralwikis://schemas, and neuralwikis://profiles, and authenticated preview/quarantine actions that are audit logged. Public pages therefore indicate that an MCP concept and public control-surface design already exist on the site.

Public infrastructure findings

What the public record does not disclose is the exact origin OS, web server stack, whether Cloudflare or another edge sits in front of the origin, whether SSH is enabled, whether the plan includes Node/Python/Passenger app hosting, or whether /api/mcp is fully live behind the documented route name. Those are the main account-level unknowns that must be checked before finalizing the deployment method.

To discover the missing facts without guesswork, the maintainer should check the hosting dashboard for: the document root path; whether the account has SSH/Terminal; whether SFTP/FTP is enabled; whether the plan supports long-running app processes, Passenger, Node, Python, or reverse proxy; whether SSL is managed at the host or CDN; whether DNS is hosted by the registrar, the hosting provider, or a third party; and whether the site currently runs under WordPress admin/theme deployment, a Git deployment pipeline, or direct file upload. Those checks are necessary precisely because the public web only proves shared-hosting signals and public routes, not operator privileges.

Fit-gap analysis and target architecture

The central fit-gap is straightforward. UAIX wants a system that clearly separates public read-only discovery, bounded low-capability fallback, POST-first authenticated action surfaces, consent/audit controls, and portable evidence/public record. NeuralWikis already has most of that conceptually: public manifests, public KB/search/context endpoints, protected mutation language, and MCP docs. The main remaining work is to make the MCP execution layer operational, documented, and hardened in a way that stays inside UAIX’s claimed scope.

A practical way to think about the target state is: WordPress/static site or existing web layer stays the publication and discovery plane; a sidecar MCP service becomes the runtime plane; UAIX-aligned manifests, headers, and evidence wrap around both. That is exactly the layering UAIX describes when it says runtimes execute while UAI/UAIX records the reviewed communication, trust, evidence, and handoff boundary.

flowchart LR
    A[Agent client] --> B[Public discovery pages and manifests]
    A --> C[Authenticated MCP service]
    B --> D[llms.txt and well-known manifests]
    B --> E[Agent API docs and schema catalog]
    C --> F[Read-only resources]
    C --> G[Authenticated tools]
    G --> H[Consent and audit controls]
    G --> I[Quarantine and preview workflow]
    C --> J[Health and metrics]
    B --> K[UAIX-aligned evidence and policy surface]

The diagram above reflects the split that UAIX publishes between read-only/public capability floors, POST-first richer clients, and externally executing runtimes, and it also reflects NeuralWikis’ own published split between public resources and authenticated tools.

Requirement-to-site mapping

UAIX does not publish CPU/RAM/disk budgets, so the following are engineering estimates, not standards requirements. For a read-mostly remote MCP endpoint with public resources and a small number of authenticated tools, a conservative starting point is 1 vCPU, 1 GB RAM, 10 GB SSD. If the same service also performs preview generation, compatibility checks, or more expensive search/index tasks, start at 2 vCPU, 2 GB RAM, 20 GB SSD. Disk growth should mostly track logs, cached artifacts, and audit history rather than HTML content. These estimates are driven by NeuralWikis’ publicly documented surface area and UAIX’s audited/evidence-bearing posture, not by any UAIX-published sizing guidance.

Public network exposure should be limited to HTTPS. UAIX’s published posture is explicit about HTTPS, HSTS, host/edge redirects, and security headers, but it does not prescribe a fixed app port or certificate vendor. In practice, expose 443 publicly, keep the app on an internal port such as 8080, and optionally expose 80 only to redirect to HTTPS. If the MCP server is moved to a sidecar or subdomain, add either an A/AAAA record for mcp.neuralwikis.com or a CNAME to a managed app endpoint, then update the public docs/manifests so clients do not guess.

flowchart TD
    A[Confirm actual host capabilities] --> B{Can current host run a long-lived app and reverse proxy it?}
    B -- Yes --> C[Deploy MCP sidecar on same host or same VM]
    B -- No --> D[Deploy MCP on separate VPS, container host, or Kubernetes]
    C --> E[Expose via /api/mcp or mcp.neuralwikis.com]
    D --> E
    E --> F[Update agent docs and well-known manifest]
    F --> G[Apply TLS, security headers, and auth]
    G --> H[Run health, route, header, and policy tests]
    H --> I[Publish evidence and rollback package]

Deployment blueprints

The playbooks below use one explicit assumption: the MCP runtime is a custom ASP.NET Core 8 service called NeuralWikis.Mcp.Server, and the existing website remains the public docs/discovery layer. That assumption is reasonable because UAIX’s closest public runtime lane is a .NET bridge/package path, while UAIX still does not publish a general-purpose server. If your actual runtime is Node or another stack, the hosting mechanics stay the same: only the app startup commands change.

Ubuntu or Debian server via SSH

This is the cleanest single-host option if you control a VPS or dedicated Linux host with SSH and reverse-proxy access. It is also the simplest way to keep the MCP app on an internal port and publish only HTTPS externally, which matches UAIX’s host/edge security posture.

Create a service account and directories:

sudo adduser --system --group --home /opt/neuralwikis-mcp neuralwikis-mcp
sudo mkdir -p /opt/neuralwikis-mcp/app /etc/neuralwikis-mcp /var/log/neuralwikis-mcp
sudo chown -R neuralwikis-mcp:neuralwikis-mcp /opt/neuralwikis-mcp /var/log/neuralwikis-mcp

Publish and copy the app:

dotnet publish src/NeuralWikis.Mcp.Server/NeuralWikis.Mcp.Server.csproj -c Release -o ./publish
sudo rsync -av ./publish/ /opt/neuralwikis-mcp/app/
sudo chown -R neuralwikis-mcp:neuralwikis-mcp /opt/neuralwikis-mcp/app

Create the environment file at /etc/neuralwikis-mcp/neuralwikis-mcp.env:

ASPNETCORE_ENVIRONMENT=Production
ASPNETCORE_URLS=http://127.0.0.1:8080
MCP_PUBLIC_BASE_URL=https://mcp.neuralwikis.com
MCP_ROUTE_BASE=/api/mcp
MCP_AUTH_MODE=Bearer
MCP_PUBLIC_RESOURCES_ENABLED=true
MCP_PUBLIC_TOOLS_ENABLED=false
MCP_AUDIT_LOG_ENABLED=true
MCP_REQUIRE_EXPLICIT_CONSENT=true
MCP_REQUIRE_IDEMPOTENCY=true
MCP_METRICS_ENABLED=true
MCP_HEALTH_PATH=/healthz

Create a systemd unit at /etc/systemd/system/neuralwikis-mcp.service:

[Unit]
Description=NeuralWikis MCP Server
After=network.target

[Service]
Type=simple
User=neuralwikis-mcp
Group=neuralwikis-mcp
WorkingDirectory=/opt/neuralwikis-mcp/app
EnvironmentFile=/etc/neuralwikis-mcp/neuralwikis-mcp.env
ExecStart=/usr/bin/dotnet /opt/neuralwikis-mcp/app/NeuralWikis.Mcp.Server.dll
Restart=always
RestartSec=5
KillSignal=SIGINT
SyslogIdentifier=neuralwikis-mcp

[Install]
WantedBy=multi-user.target

Enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable neuralwikis-mcp
sudo systemctl start neuralwikis-mcp
sudo systemctl status neuralwikis-mcp

Add Nginx as the TLS and reverse-proxy layer. If you want a dedicated subdomain, create /etc/nginx/sites-available/mcp.neuralwikis.com.conf:

server {
    listen 80;
    server_name mcp.neuralwikis.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name mcp.neuralwikis.com;

    ssl_certificate     /etc/letsencrypt/live/mcp.neuralwikis.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mcp.neuralwikis.com/privkey.pem;

    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "accelerometer=(), browsing-topics=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Content-Security-Policy "frame-ancestors 'self'" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    proxy_hide_header X-Powered-By;
    server_tokens off;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Request-Id $request_id;
    }
}

Enable the site and obtain a cert:

sudo ln -s /etc/nginx/sites-available/mcp.neuralwikis.com.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d mcp.neuralwikis.com

If you need to keep the visible URL at https://neuralwikis.com/api/mcp, reverse-proxy only that path from the existing web tier to the sidecar app, and leave the rest of the site untouched. Then update the public docs and manifest entries so the MCP location is explicit and no client has to infer it. That matches UAIX’s rule that docs should explain while machine routes execute and that automation should resolve the live route inventory from published records.

Docker container

If you already build artifacts in CI/CD, Docker makes rollback and reproducibility easier than a raw systemd-only host. The UAIX-side lesson still applies: keep the app runtime separate from the publication/evidence surface.

A minimal multi-stage Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish src/NeuralWikis.Mcp.Server/NeuralWikis.Mcp.Server.csproj -c Release -o /out

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /out .
ENV ASPNETCORE_URLS=http://0.0.0.0:8080
EXPOSE 8080
ENTRYPOINT ["dotnet", "NeuralWikis.Mcp.Server.dll"]

Build and run:

docker build -t neuralwikis-mcp:1.0.0 .
docker run -d \
  --name neuralwikis-mcp \
  --restart unless-stopped \
  --env-file /opt/neuralwikis-mcp/.env \
  -p 127.0.0.1:8080:8080 \
  neuralwikis-mcp:1.0.0

A simple Compose file at /opt/neuralwikis-mcp/docker-compose.yml:

services:
  neuralwikis-mcp:
    image: neuralwikis-mcp:1.0.0
    container_name: neuralwikis-mcp
    restart: unless-stopped
    env_file:
      - .env
    ports:
      - "127.0.0.1:8080:8080"
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://127.0.0.1:8080/healthz"]
      interval: 30s
      timeout: 5s
      retries: 3

Start it:

cd /opt/neuralwikis-mcp
docker compose up -d
docker compose ps

Use the same Nginx reverse-proxy configuration shown above for TLS, HSTS, and header hardening. That is important because UAIX explicitly assigns redirect/HSTS/static-file parity and version-header suppression to the host or edge, not to application code alone.

cPanel shared hosting

For NeuralWikis specifically, this is the most likely current environment and also the least attractive place to run a production MCP daemon. The public evidence points to shared hosting at shared.spaceship.host, and shared hosting often leaves long-lived processes, reverse proxying, and custom server config uncertain until you inspect the account. The safest cPanel plan is therefore usually hybrid: keep the website on cPanel, move the MCP runtime to a VPS/container host, and publish it on a subdomain.

The cPanel-side steps are then:

1. Create a subdomain such as mcp.neuralwikis.com.
2. Point it either directly to the VPS IP (A/AAAA) or to a managed app hostname (CNAME).
3. Upload or regenerate discovery files under the document root, typically:

• /home/<cpanel-user>/public_html/.well-known/neuralwikis-agent.json
• /home/<cpanel-user>/public_html/llms.txt
• /home/<cpanel-user>/public_html/llms-full.txt

1. Update the site’s /agent-api and /docs/mcp pages so they name the final MCP endpoint instead of leaving it implicit.
2. If the site is WordPress-backed, deploy theme-routed changes and root-static discovery files together, because adjacent ecosystem docs repeatedly describe those as separate deployment artifacts.

If the cPanel account includes Terminal/SSH, a quick file deployment looks like this:

mkdir -p ~/public_html/.well-known
cp ./neuralwikis-agent.json ~/public_html/.well-known/neuralwikis-agent.json
cp ./llms.txt ~/public_html/llms.txt
cp ./llms-full.txt ~/public_html/llms-full.txt

If your plan supports Passenger or an application manager, you can attempt to run a small app behind the cPanel-managed runtime, but that capability is not inferable from the public web and must be confirmed in-account first. If it does not support a long-running process, do not try to fake MCP with a brittle PHP shim. Use a dedicated MCP host and keep cPanel limited to docs, manifests, and read-only JSON. That is the cleanest way to preserve UAIX’s publication/runtime separation and to avoid making support claims the host cannot actually honor.

Kubernetes

Kubernetes is appropriate only if NeuralWikis already has a cluster or if the MCP service is part of a broader operator platform. It is the most flexible path for horizontal scaling, secrets management, and controlled rollouts, but it is excessive for a small read-mostly MCP endpoint. UAIX does not require Kubernetes; this is purely an infrastructure choice.

Namespace, secret, config map, deployment, service, and ingress:

apiVersion: v1
kind: Namespace
metadata:
  name: neuralwikis

---
apiVersion: v1
kind: Secret
metadata:
  name: neuralwikis-mcp-secrets
  namespace: neuralwikis
type: Opaque
stringData:
  MCP_BEARER_ISSUER: "neuralwikis-operator"
  MCP_BEARER_AUDIENCE: "neuralwikis-mcp"

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: neuralwikis-mcp-config
  namespace: neuralwikis
data:
  ASPNETCORE_ENVIRONMENT: "Production"
  ASPNETCORE_URLS: "http://0.0.0.0:8080"
  MCP_PUBLIC_BASE_URL: "https://mcp.neuralwikis.com"
  MCP_ROUTE_BASE: "/"
  MCP_AUDIT_LOG_ENABLED: "true"
  MCP_REQUIRE_EXPLICIT_CONSENT: "true"
  MCP_REQUIRE_IDEMPOTENCY: "true"

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: neuralwikis-mcp
  namespace: neuralwikis
spec:
  replicas: 2
  selector:
    matchLabels:
      app: neuralwikis-mcp
  template:
    metadata:
      labels:
        app: neuralwikis-mcp
    spec:
      containers:
        - name: neuralwikis-mcp
          image: registry.example.com/neuralwikis-mcp:1.0.0
          ports:
            - containerPort: 8080
          envFrom:
            - configMapRef:
                name: neuralwikis-mcp-config
            - secretRef:
                name: neuralwikis-mcp-secrets
          readinessProbe:
            httpGet:
              path: /readyz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 15
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 20
            periodSeconds: 20
          resources:
            requests:
              cpu: "250m"
              memory: "512Mi"
            limits:
              cpu: "1"
              memory: "1Gi"

---
apiVersion: v1
kind: Service
metadata:
  name: neuralwikis-mcp
  namespace: neuralwikis
spec:
  selector:
    app: neuralwikis-mcp
  ports:
    - port: 80
      targetPort: 8080

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: neuralwikis-mcp
  namespace: neuralwikis
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "256k"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      add_header X-Content-Type-Options "nosniff" always;
      add_header Referrer-Policy "strict-origin-when-cross-origin" always;
      add_header Permissions-Policy "accelerometer=(), browsing-topics=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()" always;
      add_header X-Frame-Options "SAMEORIGIN" always;
      add_header Content-Security-Policy "frame-ancestors 'self'" always;
      add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
spec:
  ingressClassName: nginx
  tls:
    - hosts: ["mcp.neuralwikis.com"]
      secretName: neuralwikis-mcp-tls
  rules:
    - host: mcp.neuralwikis.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: neuralwikis-mcp
                port:
                  number: 80

Apply it:

kubectl apply -f neuralwikis-mcp.yaml
kubectl -n neuralwikis rollout status deploy/neuralwikis-mcp
kubectl -n neuralwikis get ingress,svc,pods

Validation, monitoring, and operations

UAIX’s own API surface teaches the right operational pattern: resolve discovery first, keep machine routes separate from human citation pages, prefer POST for execution, and use typed problem responses for failures. NeuralWikis should mirror that discipline by keeping public docs/pages stable, JSON endpoints predictable, and failure output machine-readable.

Post-deployment tests

Start with these four smoke checks:

# Public site still loads
curl -I https://neuralwikis.com/

# Public manifest still parses
curl -s https://neuralwikis.com/.well-known/neuralwikis-agent.json

# Agent API page still describes the intended endpoint
curl -s https://neuralwikis.com/agent-api

# MCP runtime health
curl -s https://mcp.neuralwikis.com/healthz

If you expose the MCP service at the root of the subdomain:

curl -i https://mcp.neuralwikis.com/
curl -i -X POST https://mcp.neuralwikis.com/ \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":"ping-1","method":"ping","params":{}}'

If you expose it at /api/mcp on the main site:

curl -i https://neuralwikis.com/api/mcp
curl -i -X POST https://neuralwikis.com/api/mcp \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":"ping-1","method":"ping","params":{}}'

Then validate the public-read floor and the agent docs:

curl -s https://neuralwikis.com/llms.txt
curl -s https://neuralwikis.com/.well-known/agent-card.json
curl -s https://neuralwikis.com/api/kb/catalog
curl -s https://neuralwikis.com/api/kb/context?q=memory
curl -s https://neuralwikis.com/docs/mcp

Because UAIX’s minimal public contract is extremely strict, any low-capability discovery endpoint you add should return only code and url, with no hidden auth assumptions, no mutation, and no query-string secrets. If you publish any GET-triggered fallback, verify idempotency, rate limiting, audit logging, and the presence of a matching POST path for richer clients.

Monitoring and troubleshooting checklist

Recommended monitoring set:

Use these runtime-specific log commands:

# systemd
journalctl -u neuralwikis-mcp -f

# Docker
docker logs -f neuralwikis-mcp

# Kubernetes
kubectl -n neuralwikis logs -f deploy/neuralwikis-mcp

Common failure patterns and the first fix to try:

The policy-specific rows above are not arbitrary. They come directly from UAIX’s published Minimal Access, Progressive Access, Advanced Agent Support, and GET-Action Security rules, and they also match NeuralWikis’ own auth/audit language for protected routes.

Security, rollback, scenario comparison, and budget

The best hardening pattern for NeuralWikis is a direct combination of UAIX’s public guidance and NeuralWikis’ own trust posture: keep public resources read-only; keep privileged tools authenticated and role-bound; require explicit human consent for publication, account changes, repository writes, destructive actions, durable memory writes, or regulated contexts; never place secrets, keys, tokens, account IDs, or regulated identifiers in query strings; enforce rate limits and crawler protection on any GET fallback; log audit-safe evidence; and preserve a clear no-blind-import / quarantine-first posture.

A sensible backup and rollback plan has two layers. The site/publication layer should back up document-root discovery files, theme or deployed site files, and any CMS database before changes to manifests, docs, or routes. The runtime layer should back up the deployed artifact, environment file, reverse-proxy config, and any audit/idempotency store before enabling new tools or auth flows. On rollback, restore the previous app artifact or container tag, reload the reverse proxy, and then restore the prior .well-known / docs pages if the public endpoint contract changed. This mirrors both UAIX’s evidence discipline and NeuralWikis’ own emphasis on reversible commits and rollback-aware adoption.

Hosting scenario comparison

Timeline and minimal budget

These are engineering estimates, not UAIX-published requirements. UAIX publishes the standards/publication/evidence surface, but not runtime sizing or infrastructure pricing.

Open questions and limitations

The public web leaves a few material questions unanswered.

• Whether the current NeuralWikis account has SSH, Terminal, Passenger/App Manager, reverse-proxy, or container support is unknown from public evidence alone.
• The site documents /api/mcp, but the captured public evidence here confirms the documentation more strongly than the live MCP runtime behavior itself.
• A WordPress-style deployment model is probable, especially given the ecosystem-wide packaged-theme/root-static evidence, but not directly self-declared by neuralwikis.com.
• UAIX does not publish exact runtime requirements for OS, CPU, RAM, cert vendor, or a universal MCP server package, so deployment must be finalized from the actual host capabilities rather than by trying to match a non-existent “official UAIX server install guide.”

The highest-confidence recommendation is therefore: keep NeuralWikis’ current public site as the discovery/documentation/evidence plane; run the MCP runtime on a VPS or containerized sidecar unless the current host positively proves long-lived app and reverse-proxy support; and align the final surface with UAIX’s published capability tiers, POST-first action model, consent/audit controls, HTTPS/header posture, and explicit public evidence boundaries.