CSL-Core
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| 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 |
|---|---|
| verify_policyA | Verify a CSL policy for logical consistency using Z3 formal verification. Performs four-stage analysis:
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:
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:
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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| csl_expert | Load CSL-Core syntax reference and common patterns for writing policies. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| example_hello_world | Hello World — simplest possible CSL policy (1 rule). |
| example_age_verification | Age verification — multi-rule interaction with MUST BE / MUST NOT BE. |
| example_banking_guard | Banking transfer guard — tiered limits, sanctions, risk scoring. |
| example_agent_tool_guard | AI agent tool guard — RBAC, DLP, hard bans with ALWAYS. |
| example_dao_treasury_guard | DAO treasury guard — arithmetic expressions, escalating approvals. |
| example_tla_demo | TLA+ demo — all temporal safety properties hold (ENABLE_FORMAL_VERIFICATION: TRUE). |
| example_tla_demo_violation | TLA+ violation demo — TLC finds reachable safety violations with counterexample traces. |
TDQS
Scored across 6 tools
Each tool targets a distinct activity on CSL policies: generating a scaffold, explaining in Markdown, simulating against inputs, verifying with Z3, verifying with TLA+, and analyzing the state space. The descriptions clearly differentiate them, especially verify_policy vs tla_verify by specifying different verification scopes (logical consistency vs temporal safety).
Most tools follow a verb_noun pattern (explain_policy, scaffold_policy, simulate_policy, verify_policy), but tla_verify and universe_info deviate: tla_verify uses a proper noun prefix, and universe_info is noun_noun. This minor inconsistency prevents a perfect score.
With 6 tools, the server is well-scoped for a CSL policy toolkit. It covers creation, explanation, simulation, logical verification, temporal verification, and state-space analysis without being over- or under-populated.
The tool surface covers the essential policy lifecycle: generate (scaffold), understand (explain, universe_info), test (simulate), verify (verify_policy, tla_verify). No obvious missing functionality like editing or compilation, as verification already includes IR compilation.