Praxis
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | GitHub personal access token. | |
| DATAHUB_TOKEN | No | DataHub API token for authentication. | |
| DATAHUB_UI_URL | No | URL of the DataHub UI. | |
| DATAHUB_GMS_URL | No | URL of the DataHub GMS server. | |
| GITHUB_REPOSITORY | No | GitHub repository in 'owner/repository' format. | |
| GITHUB_BASE_BRANCH | No | Base branch for the GitHub pull request. | |
| PRAXIS_DBT_COMMAND | No | Command to run dbt (e.g., 'dbt'). | |
| PRAXIS_TARGET_REPO | No | Absolute path to the dbt project repository. | |
| PRAXIS_APPROVAL_TOKEN | No | Token required for live integrations on a public/non-loopback bind, used for human approval. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| praxis_prepare_remediationA | 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. |
| praxis_get_runA | 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. |
| praxis_get_artifactA | 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. |
| praxis_approve_remediationA | 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. |
| praxis_integration_statusA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
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.
All tool names follow the consistent pattern 'praxis_verb_noun' using snake_case, e.g., praxis_prepare_remediation, praxis_get_run. No deviations.
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.
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.