Skip to main content
Glama
rmednitzer

aiops-mcp

by rmednitzer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

AIOps-MCP

praxis, the unified AI-operations MCP.

Ask DeepWiki

Documentation site (rendered from docs/): https://rmednitzer.github.io/aiops-mcp/

Status: v0, stdio default with an opt-in HTTP transport, single-operator, in iterative security hardening. make ci-success is green (ruff + mypy strict + pytest + the schema-drift guard + the dispatch eval gate) and each of the nine invariants has a passing test. The deep review (ADR-0015) found that several load-bearing controls were specified but not yet wired into the running server; the ADR-0016 enforcement wave and the waves through ADR-0042 closed those findings. The implemented backlog is resolved; the two open items are both forward-looking: BL-111 (first-class kubectl/helm actuation, gated on the ADR-0043 credential contract; nothing built yet) and BL-113 (re-confirm the EU AI Act high-risk dates against the Official Journal once the Digital Omnibus publishes, ADR-0044). Read "Maturity and honest limitations" below and LIMITATIONS.md for the known remaining boundaries before relying on it. The design reference is docs/architecture.md.

What it is

praxis is a self-contained, security-first, single-operator-operable, EU-sovereign unified AI-operations MCP server. It fuses three things into one control plane:

  1. A live bitemporal model of the fleet. Hosts, services, packages, storage, networks, identities, and alerts as typed vertices and edges, with every fact carrying four timestamps and never being deleted (corrections supersede). The source of truth.

  2. A drift engine. Observed host state vs desired state (IaC plan, config baseline, or an operator-blessed known-good snapshot), with structured drift findings and human-gated convergence.

  3. A tiered, audited actuator. A single execution path that classifies every action T0-T3, gates state-changing actions behind human confirmation, and wraps the right tool per host type (ssh/ansible/opentofu/runbooks/talosctl/redfish/ cloud) instead of reinventing it.

It is self-contained: no imports from, or runtime coupling to, any sibling fleet repository. Third-party libraries are kept minimal and license-vetted (pydantic for input validation; psycopg for the optional Postgres backend), and the execution core stays dependency-free (ADR-0001, ADR-0014).

Related MCP server: LUMINO MCP Server

Why

It is the engineered successor to a hand-run fleet gateway: graduated autonomy being made load-bearing in code (not just a design note), drift detection formalized out of manual markdown baselines into a queryable bitemporal store, scattered state unified, and flat skills given a real registry and router. Security-first by design and intended for real production deployments, with the gaps still on the way to that bar tracked openly (see below).

Maturity and honest limitations

v0 is real and tested, but it is a hardening-in-progress security project, not a finished product. The deep review in ADR-0015 (2026-06-08) verified the spine is sound (storage-layer append-only state, parameterised SQL, inert untrusted skill bundles, an option-injection-guarded SSH target, an RFC 6962 Merkle implementation, a robust SSRF filter) and that all nine invariants have a proving test; the ADR-0016 enforcement wave (2026-06-10) closed its P1 and wiring findings. The honest current state:

  • HTTP transport is implemented and opt-in (ADR-0041): a stdlib http.server with an Mcp-Session-Id session lifecycle, per-session isolation (each session has its own trifecta taint latch, approval nonces, budget, and consent ceiling), constant-time bearer-token auth, a request-body cap, and a per-client consent ceiling. It stays default-closed (token + non-loopback opt-in + SSRF egress, ADR-0006); stdio is still the default. Serving is concurrent (ADR-0042, BL-110): a ThreadingHTTPServer over a store that serialises on a per-instance lock, so a slow actuation does not block other clients while the bitemporal/append-only invariants hold.

  • The human-approval gate is human-binding (ADR-0016, BL-072): a gated dry run mints a server-generated, single-use, TTL-bound token surfaced on the operator console, out-of-band from the MCP channel. The token never appears in a tool response, so an automated caller cannot reproduce or replay it. Free-form shell actuation floors at T2 (BL-073).

  • Every registered tool, including the read tools and ingest_observation, runs through the single audited path (BL-017, BL-062, BL-085); reads that return observed facts arm the trifecta latch, enforced inside the path (BL-083).

  • Scoped credentials (opt-in via the first grant), per-session budgets, and an audited emergency_stop actuator with a durable kill-switch sentinel are wired (BL-049, BL-074, BL-075). With PRAXIS_AUDIT_PATH set, the server also produces runtime Merkle checkpoints over the trail (every N records and at shutdown) and an optional anchored high-water mark (PRAXIS_ANCHOR_PATH) that detects truncation of log plus evidence together (ADR-0019; BL-076, BL-050). The default checkpoint stamper is the keyless LocalStamper; a non-forgeable RFC 3161 TSA stamper is available opt-in (PRAXIS_TSA_URL plus PRAXIS_TSA_CERT, the TSA signing certificate in PEM, plus the tsa extra; BL-095, ADR-0030). With the default stamper, OS-level append-only storage remains the required control against an attacker who can rewrite the files. Audit records can also be forwarded best-effort to syslog for SIEM/journald visibility (PRAXIS_AUDIT_SYSLOG_ADDRESS, opt-in); the append-only file stays the authoritative, tamper-evident sink (BL-100, ADR-0037). Each record carries optional request_id / client_id correlation fields, set per request by the transport, so concurrent calls can be tied to their audit entries (BL-101, ADR-0038).

These and the rest are tracked as BL-NNN in docs/backlog.md with severities in ADR-0015. LIMITATIONS.md is the running list of what is specified but not yet delivered.

Quickstart

For a complete, task-oriented walkthrough of running the server and using every tool, see the how-to guide (also on the docs site).

praxis is self-contained: the default path is the SQLite store over stdio with no external services.

uv sync --extra dev          # add --extra postgres for the production store backend
make check                   # ruff + mypy strict + pytest
make ci-success              # the above plus the schema-drift guard and eval gate
python -m praxis             # serve over stdio (JSON-RPC 2.0); refuses unsafe HTTP binds

Configuration is PRAXIS_-prefixed and bound once at import (src/praxis/config.py). For the architecture and layout see docs/architecture.md; the nine non-negotiable invariants are in CLAUDE.md.

Layout

See docs/architecture.md for the full tree. The spine: src/praxis/execution/ (the single audited executor), src/praxis/store/ (the pluggable bitemporal store), src/praxis/drift/ (the drift engine), src/praxis/actuation/ (tool adapters), src/praxis/tools/ (the MCP surface), and docs/{adr,stpa}/ plus docs/backlog.md (governance-as-code).

Governance

  • Decisions: docs/adr/ (Architecture Decision Records).

  • Safety and security requirements: docs/stpa/ (System-Theoretic Process Analysis, including STPA-Sec).

  • Work tracking: docs/backlog.md (stable BL-NNN ids).

  • Compliance mapping: docs/governance/ (EU AI Act, NIS2/NISG, CRA, GDPR, ISO 27001).

License

Apache-2.0 (see LICENSE) and NOTICE.

Available Tools

5 tools
drift_scanB
Read-only

Compute drift findings: observed facts versus the known-good baseline.

ParametersJSON Schema
NameRequiredDescriptionDefault
subjectNoRestrict the scan to one subject.

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds minimal behavioral context beyond the concept of drift. It does not disclose how the baseline is determined, performance implications, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 10 words, front-loading the key action ('Compute drift findings'). No wasted words; every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should explain what a drift finding consists of or how results are presented. It does not. The simple structure (1 optional param, no nested objects) partially mitigates the need, but the lack of output context and no comparison to siblings leaves the agent underinformed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single 'subject' parameter, which is already described as 'Restrict the scan to one subject.' The tool description does not add any additional meaning or clarification beyond the schema, so baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'compute', the resource 'drift findings', and explains what drift findings are ('observed facts versus the known-good baseline'). It distinguishes from sibling tools like query_facts and fact_history by focusing on drift analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., query_facts, fact_history). It does not mention prerequisites, exclusions, or context for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fact_historyA
Read-only

Return the full recorded (bitemporal) history of facts for a subject.

ParametersJSON Schema
NameRequiredDescriptionDefault
subjectYes
predicateNo

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and non-destructive behavior. The description adds the 'bitemporal' aspect, clarifying it returns full history, which is useful context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, 10 words, front-loaded with key information. No redundant or unnecessary text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple retrieval tool with annotations covering safety, but lacks detail on return format, behavior for missing data, and how the predicate parameter affects results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description only explains the 'subject' parameter implicitly ('for a subject') but does not explain the optional 'predicate' parameter, leaving its filtering role unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Return', the resource 'full recorded (bitemporal) history of facts', and specifies the subject. It distinguishes from sibling tools like query_facts (current facts) and ingest_observation (adding data).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives such as query_facts for current data. The description implies use for historical data but does not state exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ingest_observationA

Parse captured host telemetry into observed facts.

ParametersJSON Schema
NameRequiredDescriptionDefault
collectorYes
subjectYes
predicateNo
rawYesRaw tool output captured by a T0 read.

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), so the description adds the context that it parses telemetry into facts. However, it does not disclose whether previous facts are overwritten, any authentication requirements, or error handling. The added value is moderate given the annotation baseline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that starts with the action verb. It contains no filler or redundancy, making it efficient for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, 3 required, and no output schema, the description is too minimal. It does not explain what 'observed facts' are, the format of the raw input, the effect of multiple ingests, or error conditions. This leaves significant gaps for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25% (only the 'raw' parameter has a brief description). The tool description provides no parameter-specific information, leaving 3 of 4 parameters (collector, subject, predicate) without semantic guidance. This is insufficient, especially for a tool with required parameters and an enum.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Parse') and resource ('captured host telemetry') and clearly states the output ('observed facts'). It distinguishes from sibling tools like query_facts (query existing facts) and run_action (perform actions), making the ingestion purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for ingesting telemetry but does not explicitly state when to use this tool versus alternatives (e.g., when to use drift_scan or query_facts). No exclusions or prerequisites are given, so the agent must infer usage context from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_factsA
Read-only

List active fleet-state facts; filter by subject and/or fact_type.

ParametersJSON Schema
NameRequiredDescriptionDefault
subjectNoFilter to one subject, e.g. host:axiom.
fact_typeNoFilter to observed/desired/drift/known_good.

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and destructiveHint. Description adds only 'active' context, which is minimal beyond annotations. No mention of pagination, limits, or other behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with action and resource, no wasted words. Perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with no output schema; description covers purpose and filter options adequately. Could be improved by explicitly distinguishing from 'fact_history' or noting only active facts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so description adds little beyond schema descriptions. It reinforces the two filter dimensions but no extra semantic depth.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states action ('list') and resource ('active fleet-state facts') with filtering options. While it implies a distinction from 'fact_history' via 'active', it does not explicitly differentiate from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies use for listing facts with optional filters, but provides no explicit guidance on when to use this tool versus alternatives like 'fact_history' or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_actionB
Destructive

Run a tier-gated actuation via an adapter (DRY_RUN, approve, execute).

ParametersJSON Schema
NameRequiredDescriptionDefault
adapterYes
hostYes
host_typeYes
actionYes
ssh_aliasNo
nodesNo
endpointsNo
dry_runNo
approval_tokenNo

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds the 'tier-gated' concept and the modes (DRY_RUN, approve, execute), which go beyond the annotations. However, it does not explain the gating mechanism, what each mode entails, or the nature of destructiveness beyond what annotations already indicate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence (17 words) that front-loads the verb and key concept. While very brief, it avoids fluff. However, it could include structured information without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 parameters, destructive, no output schema, tier-gating), the description is woefully incomplete. It lacks details about how gating works, when to set dry_run, what approval_token is, and the specific adapters. It needs much more context to be usable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and 9 complex parameters, the description fails to add any meaning to the parameters. It only mentions 'adapter' indirectly and does not explain host, host_type, action, approval_token, etc. This is a critical gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear verb 'Run' and specifies the resource 'tier-gated actuation via an adapter'. The parenthetical '(DRY_RUN, approve, execute)' further clarifies the modes. This clearly distinguishes it from sibling tools which are about scanning and fact queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool vs alternatives. It does not mention prerequisites, conditions, or warning about destructive impacts, which is needed given the destructiveHint annotation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.0.0
    • First observeddrift_scan
    • First observedfact_history
    • First observedingest_observation
    • First observedquery_facts
    • First observedrun_action
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a distinct purpose: ingest_observation creates facts, query_facts retrieves them, fact_history shows historical data, drift_scan computes differences, and run_action executes actuations. No overlap.

Naming Consistency4/5

All names use snake_case and are two-word phrases, but they mix verb_noun (e.g., ingest_observation, query_facts) and noun_noun (e.g., drift_scan, fact_history) patterns. Still consistent in style and readable.

Tool Count5/5

With 5 tools, the set covers the essential AIOps operations—observation ingestion, fact querying and history, drift detection, and action execution—without being excessive or sparse.

Completeness4/5

Covers the main lifecycle: ingest, query, history, drift, and action. Missing update/delete for facts or baseline management, but core workflows are supported.

Maintenance

ActivityActive
ResponsivenessSlow

Resources

Related MCP Connectors

Related MCP Servers

  • attestix

    VibeTensor
    A
    license
    Not graded
    quality
    B
    maintenance
    MCP server for compliance automation of AI agents, enabling EU AI Act compliance, verifiable credentials, and decentralized identity management with 47 tools across 9 modules.
    45 PyPI
    17
    Apache 2.0

  • LUMINO MCP Server

    spre-sre
    A
    license
    Not graded
    quality
    C
    maintenance
    An open source MCP server empowering SREs with intelligent observability, predictive analytics, and AI-driven automation across Kubernetes, OpenShift, and Tekton environments.
    25 PyPI
    11
    Apache 2.0

  • telecom-ai

    CSOAI-ORG
    A
    license
    B
    quality
    C
    maintenance
    MCP server for telecom AI with built-in EU AI Act compliance, part of the MEOK AI Labs ecosystem.
    1
    MIT