governance-gateway
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GSL_CASCADE | No | Run the suspicion screen before the classifier | on |
| GSL_AUDIT_LOG | No | Append one JSON line per decision (no text) | |
| GSL_ESTIMATOR | No | How the classifier's cost is estimated from recent checks | p90 |
| GSL_GATEWAY_PORT | No | Local port for the hook (127.0.0.1 only) | 8737 |
| GSL_GATEWAY_WORKERS | No | Workers serving the queue | 1 |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_messageA | Check a text before acting on it: format, personal data (always) and safety (if time allows). Returns the verdict ('allow', 'redact' or 'block'), the reasons, the redacted text when personal data was found, whether the safety classifier ran, and the timing against the deadline. The original text is never echoed back. |
| governance_statusC | Requests handled so far: verdicts, lag (mean, p95), share on time, share skipped. |
| decision_matrixB | Which checking policy a pipeline needs at a given mean load (the project's decision matrix). traffic: 'even', 'random' or 'bursty'. peak_factor: busiest-hour ratio q (1 = steady). recall: the detector's recall with no queue; target: required share caught in time; cost_share: the detector's share of checking cost; load: mean arrivals ÷ capacity. |
| simulate_loadB | Race 'check everything' against the deadline-aware guard with measured check costs. traffic: 'steady', 'rush_hour' or 'real_chatbot' (real WildChat timings). Returns, for each guard, the final lag, harmful messages caught in time, the share of PII checks on time and the share of classifier checks skipped. |
| recent_decisionsB | The latest governance decisions, newest last: source, verdict, kinds of personal data found, whether the classifier ran, and timing. The checked text is never included. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| status | Live counts, lag and skip rate of the governance gateway |
| policy | The checks the gateway runs, which are mandatory, and how it decides |
TDQS
Scored across 5 tools
Each tool has a clearly distinct role: check_message performs an actual check, governance_status reports aggregate metrics, decision_matrix recommends a policy by load, simulate_load runs comparative simulations, and recent_decisions lists recent records. The only mild adjacency is between status metrics and recent decisions, but their granularity and use cases are clearly different.
The names mix verb_noun (check_message, simulate_load) with noun_noun or adjective_noun phrases (governance_status, decision_matrix, recent_decisions). It remains readable, but there is no predictable verb-first or resource-first convention across the set.
Five tools is well scoped for a governance gateway: one operational check, one status view, one recent-decisions view, one policy matrix, and one simulation. Each tool has a clear purpose and none feels redundant or excessive.
The surface covers the core lifecycle: checking text, inspecting aggregate and recent outcomes, evaluating policy by load, and simulating alternatives. Minor gaps remain around configuring or updating policies/thresholds and drilling into per-source or per-rule details, but the main workflows are covered.