tibet-pol-mcp
# tibet-pol-mcp
**MCP server for tibet-pol — machine & process health monitoring with TIBET provenance.**
Run infrastructure integrity checks via JSON templates. Every step is verified, dependency-chained, and signed with [TIBET](https://datatracker.ietf.org/doc/draft-vandemeent-tibet/) tokens. Like htop meets audit trail.
Part of the [TIBET ecosystem](https://humotica.com) by [HumoticaOS](https://github.com/Humotica).
## Install
```bash
pip install tibet-pol-mcp
```
## Claude Code / Claude Desktop Config
```json
{
"mcpServers": {
"pol": {
"command": "tibet-pol-mcp",
"env": {
"TIBET_POL_TEMPLATES": "/path/to/your/templates"
}
}
}
}
```
## Available Tools
| Tool | Description |
|------|-------------|
| `pol_check` | Run health check against a template |
| `pol_templates` | List available check templates |
| `pol_template_info` | Get template details and steps |
| `pol_diff` | Compare two runs — track infrastructure drift |
| `pol_report` | Generate HTML report from results |
| `pol_quick_health` | One-shot health percentage + failed steps |
## How It Works
Define infrastructure checks as JSON templates:
```json
{
"process_id": "my_stack",
"name": "My Infrastructure",
"steps": [
{
"id": "api_health",
"name": "API responds",
"check": "curl -sf http://localhost:8000/health",
"critical": true,
"intent": "Core API must be reachable"
},
{
"id": "db_connected",
"name": "Database connection",
"check": "pg_isready -h localhost",
"dependencies": ["api_health"],
"critical": true
}
]
}
```
Then check via MCP:
```python
pol_check("my_stack")
# → 100% health, all steps valid, TIBET token chain
pol_quick_health("my_stack")
# → {"health": "100%", "checksum": "2/2", "failed_steps": []}
```
## Step Statuses
| Status | Meaning |
|--------|---------|
| `valid` | Check passed |
| `drift` | Was passing, now failing (state change) |
| `broken` | Check failed |
| `blocked` | Dependency failed, step skipped |
| `pending` | Not yet checked |
## Template Features
- **Dependencies:** Steps can depend on other steps (topological sort)
- **Critical flags:** Critical failures block dependent steps
- **Remediation:** `on_failure` commands for auto-fix
- **Intents:** Document WHY each check exists
- **Success criteria:** Min percentage, all-critical rules
- **Alerts:** Commands on critical failure or threshold breach
## Environment Variables
| Variable | Default | Description |
|----------|---------|-------------|
| `TIBET_POL_TEMPLATES` | `/srv/jtel-stack/tibet-pol-processes` | Templates directory |
## Related TIBET Packages
- [`tibet-audit`](https://pypi.org/project/tibet-audit/) — Core TIBET provenance
- [`tibet-pol`](https://pypi.org/project/tibet-pol/) — CLI/Python API (dependency)
- [`tibet-triage-mcp`](https://pypi.org/project/tibet-triage-mcp/) — Process triage MCP server
- [`tibet-phantom-mcp`](https://pypi.org/project/tibet-phantom-mcp/) — Cross-device AI sessions
- [`tibet-ipoll-mcp`](https://pypi.org/project/tibet-ipoll-mcp/) — AI-to-AI messaging
## License
MIT — HumoticaOS
TDQS
Scored across 6 tools
Each tool has a clearly distinct purpose: running full checks, quick health summaries, comparing results, generating HTML reports, viewing template details, and listing templates. The only similar pair is pol_check and pol_quick_health, but the latter is explicitly a simplified subset, so no ambiguity.
All tools follow the consistent pattern 'pol_<descriptive_name>', using lowercase with underscores (snake_case). The verbs and nouns are clear and predictable (check, diff, quick_health, report, template_info, templates).
With 6 tools, the count is well-scoped for a process checking server. Each tool serves a distinct function without being redundant or excessive.
The tool surface covers the full workflow: running checks (full and quick), comparing runs, generating reports, and exploring templates. There are no obvious missing operations for the server's stated purpose of process integrity verification.