pAIchart MCP Hub MCP server

pAIchart — high-level design in, reviewed low-level design out

— source-available: self-host, modify, redistribute; not as a hosted service to third parties.

Across network devices, Terraform, Kubernetes, and observability stacks (Prometheus / Grafana / OpenTelemetry) — on an open MCP hub. Give pAIchart a requirements.md and a topology.json at any fetchable location — and it returns a reviewed low-level design: per-device config, the exact commands that prove it worked, and a rollback. Your team applies it, idempotently and out of band. pAIchart designs and reviews the change; it never applies it.

The LLD is the bottleneck it removes. Producing one today means a senior engineer reading live state across every box, writing config in each vendor's language, and hand-reconciling the values that cross domains. pAIchart does that work as a graph of specialist agents, checks it in three tiers, and hands you one reviewed result to approve. You stop authoring across every system and start approving one package.

The directed acyclic graph (DAG) coordinates agents

Other solutions give you a DAG of tasks. pAIchart gives you a DAG of reviewed changes.

Every node is a domain pipeline of agents harvest live state → design → author → review and every edge carries a value that did not exist until runtime. Legs with no edge between them run in parallel; a dependency edge forces order and hands the real derived value forward.

┌──▶ [firewall leg] ──┐
[network leg] ──────┼──▶ [cloud leg] ─────┼──▶ [integration review] ──▶ release gate
                    └──▶ [k8s leg] ───────┘
     derived range                              checks all legs against
     exists only after                          the one shared contract
     this leg runs

That's the difference between a graph and a script: the cloud leg authorises exactly the address range the network leg derived, because the cloud leg reads the content the network leg created. There are no pre-defined values in the high level design.

• multiple legs, parallel or sequenced, with context chaining and dependencies
• Four infrastructure domains today — network devices, Terraform, Kubernetes, observability config (Prometheus / Grafana / OpenTelemetry) — plus artifact synthesis, and the shape is extensible: the observability domain was added as a configuration exercise (a protocol, four role templates, a read-only service descriptor), not an engine change
• The graph is declared with the work, in a single PIPELINE task, not in a separate scheduler you also have to operate
• Approval gates release from your AI client or the web UI, over one common code path
• Live state comes from your devices, harvested read-only through per-device MCP servers

How correctness is checked using three tiers, and a lower one can't be overruled

Tier 1 — arithmetic, in code. Where appropriate pAIchart uses code to do a deterministic check rather than an LLM reviewer's confidence. Every derived value is tagged with a kind, and the engine runs the arithmetic for that kind against the harvested evidence — never against the package's restated copy of it:

• cidr — does the derived range cover exactly its declared members? Catches too wide (an already-allocated address swept in) and too narrow (a claimed member falling outside).
• asn — is the AS number inside the private range, and does the harvested state authorize it? The relation deliberately inverts here: the harvest is the allowlist — an AS number the design sets must be one the devices already run, or one the objective explicitly names.

Shortened. The full README is on GitHub.