Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
verify_policyA

Verify a CSL policy for logical consistency using Z3 formal verification.

Performs four-stage analysis:

  1. Syntax validation (parser)

  2. Semantic validation (scope, types, function whitelist)

  3. Z3 logic verification (reachability, internal consistency, pairwise conflicts, policy-wide conflicts)

  4. IR compilation

Returns verification result with actionable error details if any issues are found.

Args: csl_content: The complete CSL policy source code as a string.

simulate_policyA

Simulate a CSL policy against one or more JSON inputs.

Compiles the policy, then runs the runtime guard against the provided context. Returns ALLOWED or BLOCKED with full violation details.

Supports batch simulation: pass a JSON array of objects to test multiple inputs.

Args: csl_content: The complete CSL policy source code as a string. context_json: JSON object (single input) or JSON array (batch) to test. dry_run: If true, evaluates all rules but never blocks. Useful for shadow testing.

explain_policyA

Parse a CSL policy and return a structured Markdown summary.

Shows: domain name, all variables with types/ranges, all constraints with triggers and actions, and configuration settings. Does NOT compile or verify — use verify_policy for that.

Args: csl_content: The complete CSL policy source code as a string.

scaffold_policyA

Generate a CSL policy scaffold from a description.

Returns a ready-to-edit .csl template with CONFIG, DOMAIN, VARIABLES, and placeholder constraints.

Common CSL patterns: WHEN amount > 1000 THEN role MUST BE "ADMIN" WHEN risk_score > 0.8 THEN action MUST NOT BE "TRANSFER" ALWAYS True THEN tool MUST NOT BE "DELETE" WHEN user_age < 18 AND category == "ALCOHOL" THEN allowed MUST BE "NO"

Variable types: amount: 0..100000 (integer range) role: {"ADMIN", "USER"} (enum / string set) score: 0..1 (numeric range)

Args: domain_name: Name for the policy domain (e.g., "PaymentGuard", "AgentSafety"). description: Plain-English description of what the policy should enforce. variables: Optional comma-separated variable hints (e.g., "amount, role, risk_score").

tla_verifyA

Run TLA+ formal verification (real TLC model checking) on a CSL policy.

Performs exhaustive state-space exploration to verify temporal safety properties. Unlike Z3 (which checks static logical consistency), TLA+ checks ALL possible state transitions over time.

Returns:

  • Whether all safety properties hold

  • Number of states explored / distinct states

  • Counterexample traces for any violations

  • TLC identity proof (version, PID, workers)

  • Automated fix suggestions for violations

  • Generated TLA+ spec (for transparency)

Use verify_policy for quick Z3 consistency checks. Use tla_verify when you need exhaustive temporal verification.

Args: csl_content: The complete CSL policy source code as a string. timeout: TLC subprocess timeout in seconds (default: 60). use_mock: If true, use Python BFS fallback instead of real TLC.

universe_infoA

Analyze the state space "universe" of a CSL policy.

Returns structural information about the policy's state space:

  • All variables with their domains, TLA+ set representations, and cardinalities

  • Total state space size (product of all variable cardinalities)

  • All constraints with their conditions and actions

  • Constraint coverage analysis (which variables are constrained vs unconstrained)

  • State space breakdown visualization

Essential for understanding the "universe" an agent lives in, planning Evolving Universe experiments, and estimating TLC verification cost before running tla_verify.

Args: csl_content: The complete CSL policy source code as a string.

venom_inventoryB

Summary of the AI agents Venom discovered on this machine: kind, state, tool count, riskiest tool class, guard status, coverage and top findings. Redacted: no credential values, no prompt text.

Args: workspace: Venom workspace folder (default: CSL_VENOM_WORKSPACE or the server's folder).

venom_agentA

One agent in detail: its tools with parameters and risk classes, triggers, guard status and the agent key to use in policies. No secrets, no prompt text.

Args: agent_id: agent id, name or key (from venom_inventory). workspace: Venom workspace folder.

venom_policy_contextA

Everything needed to draft or revise a policy for one agent: the active policy (or a deterministic starting draft on first install), its findings, vocabulary drift and the rules a valid draft must follow.

Args: agent_id: agent id, name or key. workspace: Venom workspace folder.

venom_save_draftA

Verify a CSL draft (parse, validate, Z3) and, only if it passes, save it to the workspace's .csl/venom/drafts/. Never activates anything: the operator reviews and activates drafts with the cslcore CLI.

Args: agent_id: the agent the draft is for. csl_content: complete CSL policy source. note: one line explaining the draft (kept as a comment). workspace: Venom workspace folder.

venom_propose_exemptionB

Propose that an agent (scope "agent") or one tool (scope "tool") be exempted from guarding. Always recorded as proposed; only the operator can approve it in the CLI.

Args: agent: agent id (or "*" with scope "tool"). scope: "agent" or "tool". reason: why it can be trusted. tool: tool name when scope is "tool". workspace: Venom workspace folder.

Prompts

Interactive templates invoked by user choice

NameDescription
csl_expertLoad CSL-Core syntax reference and common patterns for writing policies.
venom_draft(0.6) Draft a CSL policy for one discovered agent and save it for review.

Resources

Contextual data attached and managed by the client

NameDescription
example_hello_worldHello World — simplest possible CSL policy (1 rule).
example_age_verificationAge verification — multi-rule interaction with MUST BE / MUST NOT BE.
example_banking_guardBanking transfer guard — tiered limits, sanctions, risk scoring.
example_agent_tool_guardAI agent tool guard — RBAC, DLP, hard bans with ALWAYS.
example_dao_treasury_guardDAO treasury guard — arithmetic expressions, escalating approvals.
example_tla_demoTLA+ demo — all temporal safety properties hold (ENABLE_FORMAL_VERIFICATION: TRUE).
example_tla_demo_violationTLA+ violation demo — TLC finds reachable safety violations with counterexample traces.

TDQS

A3.8/5.0

Scored across 11 tools

Disambiguation4/5

Most tools are clearly distinct, especially the verification tools which have explicit guidance on when to use which (verify_policy vs tla_verify vs simulate_policy). The venom_* tools form a coherent workflow, though venom_inventory and venom_agent share the inspection space—inventory gives all agents, agent gives one—but the distinction is clear from descriptions. No major overlap or misselection risk.

Naming Consistency3/5

Mixed naming conventions: venom_* tools use a clear prefix, but the rest are a mix of verb_noun (explain_policy, scaffold_policy), verb_verb (verify_policy, simulate_policy), and noun_verb (tla_verify, universe_info) patterns. While readable, there is no single consistent verb_noun pattern across the set.

Tool Count5/5

11 tools are well-scoped for a CSL policy management and verification server. Each tool covers a distinct facet: inventory, agent inspection, policy context, drafting, exemptions, explanation, scaffolding, simulation, TLA+ verification, universe analysis, and Z3 verification. No tool feels redundant or missing.

Completeness4/5

The surface covers the full lifecycle of CSL policy work: inspection, drafting, verification, simulation, formal analysis, and exemption handling. One potential gap is direct activation or deployment of policies, but the descriptions explicitly state that activation is done via CLI by the operator, which aligns with the tool's design. No critical dead ends for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessSlow