tibet-pol-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TIBET_POL_TEMPLATES | No | Templates directory | /srv/jtel-stack/tibet-pol-processes |
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pol_checkA | Run a process integrity check against a template. Executes all steps defined in the template, respecting dependency chains and critical flags. Returns structured results with:
Args: template: Template name or path (e.g., "humotica_full_stack", "p520_machine.json", or full path) output_json: Return raw JSON (default: true) Returns: Check results with summary, step details, and TIBET provenance |
| pol_templatesA | List available process check templates. Shows all .json templates in the templates directory with their process ID, name, step count, and critical step count. |
| pol_template_infoC | Get detailed info about a template — all steps, dependencies, and intents. Args: template: Template name or path Returns: Full template structure with steps, dependency graph, and success criteria |
| pol_diffA | Compare two check runs to see what changed. Shows checksum changes, status changes, and step-level differences. Useful for tracking infrastructure drift over time. Args: result_a: Path to first result JSON result_b: Path to second result JSON Returns: Diff showing what changed between runs |
| pol_reportA | Generate an HTML report from check results. Creates a formatted HTML file with summary, step table, and collapsible TIBET token chain. Args: result_path: Path to check result JSON output: Output HTML file path (default: auto-generated) Returns: Path to generated HTML report |
| pol_quick_healthA | Quick health summary — just the checksum and status. Runs a full check but returns only the summary: percentage, checksum (passed/total), status, and any failed steps. Args: template: Template name (default: humotica_full_stack) Returns: Quick summary with health percentage and failed step names |
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 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.