A
licenseNot graded
qualityC
maintenanceEnables AI agents to investigate backend incidents by executing runbooks that gather evidence from observability and storage systems.
5
9
MIT
Praxis
by Marc-Dvci
The server provides evidence-bound remediation for dbt schema drift incidents (e.g., renamed source fields). It allows you to:
Prepare a remediation: from a DataHub source URN and old/new field names, it generates minimal dbt compatibility patches, runs fail-closed verification, and returns a run ID with risk score.
Inspect remediation runs: retrieve full run records with evidence, artifacts (diffs, hashes), verification results, and a chained ledger.
Read generated artifacts: fetch the exact content, unified diff, and SHA-256 of any candidate file.
Record human approval or rejection: only explicit human decisions are accepted; upon approval, it re-verifies and publishes outputs to DataHub and/or GitHub.
Check integration status: see which integrations (DataHub, GitHub, dbt, target repo) are configured and optionally probe live connectivity.
Provides remediation for dbt projects by detecting schema-drift incidents against DataHub lineage, generating minimal dbt compatibility patches, and verifying them with dbt parse before human approval.
Allows publishing approved remediation bundles as a single Git tree, commit, and draft pull request on a GitHub repository using the Git database API.
Click on "Install 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., "@Praxisfix schema drift in the customers model"
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.
Praxis
The evidence-bound remediation agent for DataHub-governed data products.
Praxis takes one narrow but expensive incident all the way to a mergeable fix: a source field was renamed, a dbt model still projects the old field, and the break can propagate into a production ML path. It reads the exact DataHub schema and lineage, inspects the real dbt files, generates a minimal compatibility patch, verifies it in isolation, pauses for a named human decision, and publishes only confirmed outputs.
The differentiator is not another incident summary. It is a proof-carrying change set. Every candidate contains DataHub evidence URNs, before/after SHA-256 hashes, validation results, and a rollback instruction. Praxis re-reads the repository and repeats verification after approval, so a stale review can never be applied.
It runs three ways: a web UI for the human at the gate, an MCP server so an agent can drive it, and a DataHub Skill that composes DataHub's own MCP server for discovery with Praxis for the verified fix.
▶ Watch the 2-minute demo — one incident, from DataHub evidence to a verified change set at the human gate.
Three ways in
Command | Needs | |
Sandbox UI, no credentials |
| Python 3.10+ |
Live DataHub, one command |
| Docker |
As agent tools over MCP |
| an MCP-capable agent host |
Related MCP server: semley
Try it in 60 seconds
Python 3.10+ is the only requirement for the sandbox's structural verification path.
python -m praxisFor the same real dbt parse gate used in the Docker image:
pip install -r requirements-dbt.txt
python -m praxisOpen http://127.0.0.1:8787, select Resolve evidence & verify, inspect the Evidence and Candidate tabs, and approve or reject the bundle. No credentials are required.
The sandbox is not a prerecorded UI. The backend loads a packaged DataHub-shaped
incident fixture, reads the intentionally broken dbt project under
sandbox/dbt_project, generates new files, validates them, persists a chained
ledger, and serves the resulting artifacts. The source project is deliberately
left unchanged; the approved bundle is written under .runtime/artifacts.
Packaged incident in the intake form switches between three of them, so the engine can be judged on more than one input:
Incident | Blast radius | Outcome |
Encounters rename | dbt → Feast → MLflow → SageMaker → Looker | risk 95, |
Medications rename | dbt → dbt mart → Looker | risk 65 — the score is composed from evidence, not fixed |
Lab results rename | dbt → Looker | refused: the column is wrapped in a |
The third one is the point. Praxis stops before generating anything rather than guess which part of an expression to rewrite, and the UI reports it as stopped safely rather than as a result.
Docker is equally self-contained and includes the pinned DataHub SDK plus dbt/DuckDB parser. Sandbox needs no credentials; the same image supports live column-lineage and deployment evidence when DataHub is configured:
docker compose up --buildWhat the agent proves
The old source field is absent and its replacement is present.
At least one DataHub column-lineage path confirms downstream field impact.
DataHub entity lineage identifies the wider data/ML/dashboard blast radius.
The dbt repository contains exactly one safe projection to repair.
The candidate preserves every projected output in an enforced contract.
The SQL has no destructive operations and input hashes are still current.
dbt parsepasses when dbt is installed; otherwise the UI saysstructurally verifiedand records the skipped check.The exact candidate hashes still match immediately after human approval.
If any required proof is missing, Praxis stops before offering approval.
Outputs
Each successful sandbox run produces four inspectable artifacts:
a one-line dbt compatibility repair;
the existing dbt contract with enforcement enabled;
a provenance manifest with DataHub URNs and input/output hashes;
a complete verification report, including skipped checks.
The checked-in sample bundle is generated
from the same code path by examples/regenerate.py.
examples/README.md walks through each file and shows the
one-line diff, so the output can be judged without running anything.
What it looks like
|
|
The human gate: tier, external systems, rollback, named approver. | Exact DataHub schema, ownership, failed assertion, column path. |
|
|
Generated files, unified diffs, hashes, every verification check. | The SHA-256 chained ledger for the run. |
Every screenshot in docs/screenshots/ is produced by
demo-video/scripts/capture-ui.py, which drives the shipped server in a real
browser rather than being posed by hand.
Demo film
https://youtu.be/tqZr-XEIfV8 (2:13)
demo-video/ builds the submission film with
Remotion and Edge neural TTS. It is data-driven: demo-video/scripts/capture-trace.py
drives this engine headlessly and every number, URN, hash and generated line on
screen is read from that capture; the human-gate scene is a real screen
recording of the product, not a mock-up. Render it with
demo-video\render-final.ps1.
Live DataHub and GitHub
Install the official DataHub SDK only for live column-level lineage:
pip install -r requirements-datahub.txtSet the integrations you want:
PRAXIS_TARGET_REPO=/absolute/path/to/your/dbt-project
PRAXIS_DBT_COMMAND=dbt
DATAHUB_GMS_URL=http://localhost:8080
DATAHUB_TOKEN=...
DATAHUB_UI_URL=http://localhost:9002
GITHUB_REPOSITORY=owner/repository
GITHUB_TOKEN=...
GITHUB_BASE_BRANCH=main
# Required for live integrations on a public/non-loopback bind.
PRAXIS_APPROVAL_TOKEN=...In live mode Praxis uses DataHub GraphQL for the exact dataset schema,
ownership, description, and entity blast radius, and the official lineage SDK
for field paths. After approval it adds praxis.verified-impact only to URNs
that DataHub confirms and appends a hash-bound memory note to the source
dataset. It never reports an attempted write as a successful graph delta.
When GitHub is configured, Praxis creates one Git tree, one commit, and one draft pull request through the Git database API. Existing files are updated atomically; it does not make one commit per file. Without GitHub credentials, the local bundle remains the only repository output.
One command to a live graph
python setup/live_quickstart.pyInstalls the pinned SDK, brings up DataHub Core 1.6.0, waits for GMS to answer
GraphQL, and seeds a self-contained nine-entity graph: the post-rename source
schema, two-hop column lineage, three ML features, a production model, its model
group, its SageMaker deployment and a business-critical dashboard. No warehouse
and no datapack. --serve starts Praxis on it, --stop tears it down.
Quickstart publishes GMS on host port 8080, which is a popular port. If something else already holds it the script says so in seconds rather than failing several minutes into container startup, and moves DataHub out of the way on request:
python setup/live_quickstart.py --gms-port 58080The equivalent by hand:
datahub docker quickstart --version v1.6.0
DATAHUB_GMS_URL=http://localhost:8080 python setup/seed_ml_lineage.pySee credential boundaries before connecting a
non-disposable deployment. In particular, the Quickstart datahub:datahub login
is not a DataHub API token.
Drive it from an agent (MCP)
Praxis is also an MCP server, so an agent can resolve an incident, read the diff and the verification result, and put the decision in front of a human:
python -m praxis.mcp # stdio JSON-RPC; --list-tools to inspectFive tools: praxis_prepare_remediation, praxis_get_run, praxis_get_artifact,
praxis_approve_remediation, praxis_integration_status.
.mcp.json registers Praxis alongside DataHub's own MCP server,
which is the intended pairing — DataHub does discovery and lineage, Praxis does the
part a conversational surface cannot: generate a change and refuse to hand it over
unverified.
The agent cannot approve. praxis_approve_remediation requires a named human
identity and an explicit human_approved flag that an agent is instructed never to
set on a person's behalf. A refused approval leaves the run in waiting with
nothing applied, and the tests assert it.
contrib/skills/datahub-verified-remediation/
is a DataHub Skill in the upstream datahub-skills layout that drives this whole
workflow, plus an RFC for the append-only
agent-memory aspect DataHub currently lacks. See contrib/.
References:
Truth matrix
Mode | Reads | Writes after approval | Never does |
Sandbox | Packaged evidence + local dbt project | Local review bundle | DataHub, GitHub, or source-repo mutation |
Live DataHub | Exact DataHub schema + lineage + local dbt project | Confirmed DataHub tags/note; local bundle | Production traffic changes |
Live + GitHub | Same as live | One atomic draft PR plus confirmed DataHub writes | Automatic merge or deployment |
Agent over MCP | Same as the mode it is configured for | Nothing — an agent may prepare and inspect only | Approve on a human's behalf |
Test and audit
python -m compileall -q praxis tests
python -m unittest discover -s tests -v
node --check praxis/public/app.jsThe tests cover the DataHub 1.6 GraphQL schema, two approval races (at worker handoff and during the preparation slot release), restart-safe state, rejection safety, candidate generation, verification, path traversal, API authorization, SQLite migration, connector truthfulness, tamper detection, and the MCP surface — protocol handshake, stdio framing, path redaction, and the refusal that stops an agent approving its own work. See the architecture and contest audit for the detailed boundaries and remaining deployment checks.
Apache 2.0 licensed.
Available Tools
5 toolspraxis_approve_remediationRecord a human decisionA
Record an approval or rejection for a run that passed verification. APPROVAL IS A HUMAN ACT: you must not call this on your own judgement. Only call it when a person has seen the diff and the verification result and told you their decision, and pass the identity they gave you. On approval Praxis re-reads the repository, re-verifies, compares the candidate hashes, and publishes only outputs an external system confirms.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | Run identifier. | |
| approver | Yes | Identity of the human who decided. Recorded in the ledger. | |
| decision | Yes | The human's decision. | |
| human_approved | Yes | Must be true, and only a human may cause it to be true. Set it solely to relay a decision a person actually made. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description goes beyond by detailing what happens on approval: re-reads repository, re-verifies, compares candidate hashes, and publishes only outputs confirmed by an external system. This adds significant behavioral context beyond the annotations.
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 somewhat lengthy but every sentence provides necessary context. It front-loads the purpose and then adds behavioral details. Minimal redundancy; could be slightly trimmed but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (human decision recording, multiple required parameters, no output schema), the description is thorough. It explains the full workflow, constraints, and the role of each parameter, leaving no gaps for an AI agent to misunderstand the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds meaning beyond schema descriptions: it explains that 'human_approved' must be true and only set by a human, and that 'approver' is the identity recorded in the ledger. This adds value over the basic parameter names and schema descriptions.
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 explicitly states the tool records an approval or rejection for a run that passed verification, using the verb 'record' and the resource 'decision'. It distinguishes itself from siblings like praxis_prepare_remediation and praxis_get_run by emphasizing it is a human decision action, not an automated operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly says 'you must not call this on your own judgement' and 'only call it when a person has seen the diff and the verification result and told you their decision'. It provides clear context for when to use the tool, but does not explicitly mention when not to use it relative to other tools, though the sibling list helps infer that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
praxis_get_artifactRead generated file contentARead-onlyIdempotent
Exact content of one generated candidate file, with its unified diff against what is in the repository today and its SHA-256. Use this to show a reviewer the change rather than describing it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Artifact path as reported by praxis_get_run, e.g. models/staging/stg_encounters.sql. Omit to list the paths. | |
| run_id | Yes | Run identifier. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, indicating safe read operation. Description adds that the tool returns content, diff, and SHA, and notes omitting path lists existing paths. Does not mention rate limits or authentication, but annotations reduce burden.
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?
Two sentences: first states what the tool returns (content, diff, SHA), second gives explicit usage guidance. No redundant words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 2 parameters (one optional), read-only, idempotent, and no output schema, the description is complete. Covers purpose, what is returned, and usage instructions. No missing critical details for the tool's simple function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining the path parameter's format (e.g., 'models/staging/stg_encounters.sql') and the optional behavior (omit to list paths). This clarifies usage beyond schema definitions.
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?
Description clearly states it returns exact content, unified diff, and SHA-256 of a generated candidate file. Specifies use case: showing a reviewer the change. Distinguishes from sibling tools like praxis_get_run (lists artifacts) and praxis_prepare_remediation (generates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool 'to show a reviewer the change rather than describing it.' Implicitly contrasts with other tools but does not explicitly list when not to use or alternative tools. Guidance is clear for primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
praxis_get_runRead a remediation runARead-onlyIdempotent
The full record for a run: DataHub evidence with URNs, the blast radius, repository input hashes, every generated artifact with its unified diff and SHA-256, the verification result including skipped checks, and the chained ledger. Operator filesystem paths are removed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | No | Run identifier. Omit for the most recent run. | |
| include_events | No | Include the chained ledger events. Defaults to true. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, so the description doesn't need to re-state safety. It adds value by noting that operator filesystem paths are removed, which is a behavioral trait not obvious from annotations. No contradictions.
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 efficiently lists all key return fields without extraneous words. It is front-loaded with the purpose and provides immediate clarity.
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?
Given no output schema, the description provides a good overview of the returned data. It covers all major components (evidence, artifacts, verification, ledger) and mentions removal of paths. It is sufficiently complete for an agent to understand the tool's scope, though some structural details are omitted.
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?
Both parameters are fully described in the input schema (run_id and include_events), so schema coverage is 100%. The description does not add additional meaning beyond what the schema provides, meeting the baseline expectation.
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 it returns 'the full record for a run' and enumerates specific data fields (URN evidence, blast radius, artifacts, verification result, ledger). This distinguishes it from sibling tools like praxis_get_artifact which is for single artifacts.
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 does not explicitly state when to use this tool versus alternatives. While the intent is clear (get comprehensive run data), there are no when-to-use or when-not-to-use guidelines, leaving the agent to infer context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
praxis_integration_statusReport configured integrationsARead-onlyIdempotent
Whether DataHub, GitHub, the target repository and dbt are configured, and therefore which evidence modes and outputs are available. Call this before choosing 'live' mode.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| probe | No | Actually contact DataHub and GitHub instead of reporting configuration only. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral context: that the tool checks configuration and that the 'probe' parameter triggers actual contact with servers. This goes beyond the annotations without contradicting them.
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 two sentences, clearly structured. The first sentence defines the tool's output, the second gives a usage directive. No unnecessary words; every sentence adds value.
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?
The description explains what the tool reports (configuration status) and why it matters (which modes/outputs are available). It lacks a detailed return structure, but since there is no output schema, the description provides enough high-level context for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% description coverage for the single parameter. The description adds meaning by explaining that 'probe' means actually contacting the services, which enhances understanding. The tool description itself does not repeat parameter details but adds context.
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 tool checks configuration of DataHub, GitHub, target repository, and dbt, and indicates which evidence modes and outputs are available. It uses specific verbs and resources, distinguishing it from sibling tools like praxis_prepare_remediation or praxis_get_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this before choosing 'live' mode,' providing clear when-to-use guidance. It does not explicitly mention when not to use or alternatives, but the context is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
praxis_prepare_remediationPrepare a verified remediationARead-only
Resolve DataHub evidence for a schema-drift incident, generate the smallest safe dbt compatibility patch against the real repository, and run fail-closed verification. Returns the run id, the risk score, the verification tier and every check. Blocks on nothing and mutates nothing: the target repository, DataHub and GitHub are untouched. Waits for the run to reach its human gate before returning.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'live' reads the real DataHub configured by DATAHUB_GMS_URL. 'sandbox' uses the packaged fixture and accepts only its one incident. | |
| model_path | No | Repo-relative path to the dbt .sql model, e.g. models/staging/stg_encounters.sql. | |
| source_urn | Yes | Exact DataHub dataset URN, e.g. urn:li:dataset:(urn:li:dataPlatform:snowflake,clinical.encounters,PROD). Praxis does not search; resolve the URN first. | |
| source_field | Yes | The field the dbt model still projects but the source no longer has. | |
| contract_path | No | Repo-relative path to the dbt contract .yml for that model. | |
| replacement_field | Yes | The field observed in the source schema in its place. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that the tool mutates nothing (aligned with readOnlyHint=true), waits for a human gate, and runs fail-closed verification. It adds valuable behavioral context beyond annotations, such as waiting behavior and the fact that it blocks on nothing external.
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?
Three concise sentences front-load key actions and return values, with no wasted words. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers return values, behavioral traits (non-mutation, waiting for gate, fail-closed), and required inputs. It provides a complete picture for a complex tool with 6 parameters.
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 parameters are well-defined in the schema. The description adds minor guidance (e.g., 'resolve the URN first') but does not significantly expand on parameter meaning beyond what the schema already provides.
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 it resolves DataHub evidence, generates a dbt compatibility patch, runs verification, and returns specific outputs (run id, risk score, verification tier, checks). It distinguishes itself from sibling tools by describing a unique preparation step that blocks on a human gate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly sets context as the preparation step for schema-drift incidents, with no explicit when-not or alternatives. However, it clearly indicates the tool's role in the workflow, and sibling tools like praxis_approve_remediation are naturally distinct. A slight lack of explicit guidance keeps it from a 5.
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. Dates show when Glama detected each change.
5 tool updates
v0.2.0- First observed
praxis_approve_remediation - First observed
praxis_get_artifact - First observed
praxis_get_run - First observed
praxis_integration_status - First observed
praxis_prepare_remediation
TDQS
A4.4/5.0
Disambiguation5/5
Each tool has a clearly distinct role: initiating remediation, retrieving run records, fetching artifact diffs, approving/rejecting, and checking integration status. No overlap in functionality.
Naming Consistency5/5
All tool names follow the consistent pattern 'praxis_verb_noun' using snake_case, e.g., praxis_prepare_remediation, praxis_get_run. No deviations.
Tool Count5/5
Five tools is well-scoped for a remediation workflow server covering initiation, status retrieval, artifact access, approval, and integration checks. Each tool earns its place.
Completeness4/5
Covers the core workflow end-to-end (prepare, retrieve, approve, check status). Minor gap: no listing or searching runs; agents must know the run ID, but this is acceptable for the focused domain.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Human-in-the-loop review and approval for AI agents. Audit trail, approval policies, native MCP.
Verified AI-agent outcomes: secret scanning, JSON cleanup, dedupe, anomaly and schema checks.
Preflight QA for AI-agent deliverables with structured verdicts and repair guidance.
Runtime AI governance: decision gates, human approval, hash-chained audit, compliance mapping.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables autonomous SRE incident investigation by allowing users to describe incidents in natural language. The agent follows a governed state machine to gather read-only evidence and produce grounded conclusions.MIT
- FlicenseNot gradedqualityBmaintenanceAn MCP-native AI incident response system that empowers agents to investigate production incidents, collect evidence, hypothesize root causes, and drive controlled remediation and recovery verification.1-
- AlicenseAqualityBmaintenanceEnables AI agents to safely inspect and execute version-controlled operational runbooks with policy checks, dry-run planning, and out-of-band approvals.3MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Marc-Dvci/praxis-datahub'
If you have feedback or need assistance with the MCP directory API, please join our Discord server