The lu-mcp-server provides tools for working with Lingua Universale (LU), a formal protocol verification language for AI agent communication.
Parse Protocol Definitions (lu_load_protocol): Load and parse .lu protocol text to extract structure including name, roles, steps, choices, and declared properties.
Verify Session Messages (lu_verify_message): Validate whether a message is correct at a given point in an ongoing session by replaying message history and checking the next intended message — catching violations like wrong sender, wrong turn, or incorrect message order.
Check Formal Properties (lu_check_properties): Statically verify declared safety properties such as always_terminates, no_deadlock, no_deletion, and all_roles_participate, with optional Lean 4 formal proof.
List Standard Library Templates (lu_list_templates): Browse 20 built-in verified protocol templates across 5 categories (communication, data, business, ai_ml, security), with optional category filtering.
A language for verified AI agent protocols.
Try it in your browser -- no install needed. Watch AI agents live -- 3 agents on a verified protocol.
Your AI agents talk to each other, but nothing guarantees they follow the rules. Wrong sender, wrong message order, missing steps -- and you only find out in production.
Lingua Universale (LU) is a type checker for AI agent conversations. You define the protocol, LU proves it's correct, and the runtime enforces it.
from cervellaswarm_lingua_universale import Protocol, ProtocolStep, MessageKind, SessionChecker, TaskRequest
# Define: who sends what, to whom, in what order
review = Protocol(name="Review", roles=("dev", "reviewer"), elements=(
ProtocolStep(sender="dev", receiver="reviewer", message_kind=MessageKind.TASK_REQUEST),
ProtocolStep(sender="reviewer", receiver="dev", message_kind=MessageKind.TASK_RESULT),
))
checker = SessionChecker(review)
checker.send("dev", "reviewer", TaskRequest(task_id="1", description="Review auth")) # OK
checker.send("dev", "reviewer", TaskRequest(task_id="2", description="Oops")) # ProtocolViolation!
# ^^^ wrong turn: reviewer must send nextThe protocol says reviewer goes next. The runtime blocks it. Not because you trust the code -- because the session type makes it impossible.
Related MCP server: edict-lang
pip install cervellaswarm-lingua-universaleOr try it first: Playground (runs in your browser via Pyodide).
protocol DelegateTask:
roles: supervisor, worker, validator
supervisor asks worker to execute analysis
worker returns result to supervisor
supervisor asks validator to verify result
when validator decides:
pass:
validator returns approval to supervisor
fail:
validator sends feedback to supervisor
properties:
always terminates
no deadlock
no deletion
all roles participateThen verify it:
lu verify delegate_task.lu [1/4] always_terminates ... PROVED
[2/4] no_deadlock ... PROVED
[3/4] no_deletion ... PROVED
[4/4] all_roles_participate ... PROVED
All 4 properties PASSED.Mathematical proof. Not a test that passes today and fails tomorrow.
Feature | Description |
Full compiler | Tokenizer, parser (64 rules), AST, contract checker, Python codegen |
9 verified properties |
|
20 stdlib protocols | AI/ML, Business, Communication, Data, Security -- ready to use |
Linter + Formatter |
|
LSP server | Diagnostics, hover, completion, go-to-definition, formatting |
VS Code extension | |
Interactive chat |
|
Browser playground | Try it now -- Check, Lint, Run, Chat |
Lean 4 bridge | Generate and verify mathematical proofs |
REPL |
|
Project scaffolding |
|
Zero external dependencies. Pure Python stdlib.
lu check file.lu # Parse and compile
lu verify file.lu # Formal property verification
lu run file.lu # Execute
lu lint file.lu # 10 style and correctness rules
lu fmt file.lu # Zero-config auto-formatter
lu chat --lang en # Build a protocol conversationally
lu demo --lang it # See the La Nonna demo
lu init --template NAME # Scaffold from stdlib templates
lu visualize file.lu # Generate Mermaid sequence diagram
lu mcp-audit --manifest t.json # Audit MCP server protocols
lu repl # Interactive REPL
lu lsp # Start LSP serverAdd protocol verification to your GitHub Actions workflow:
# .github/workflows/lu-check.yml
on:
push:
paths: ["**/*.lu"]
jobs:
lu-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v6
with:
python-version: "3.11"
- run: pip install cervellaswarm-lingua-universale
- run: lu lint protocols/
- run: lu verify protocols/Exit code is non-zero on violations -- works with any CI system.
LU is built on multiparty session types (Honda, Yoshida, Carbone -- POPL 2008). Session types describe communication protocols as types: if two processes follow the same session type, they cannot deadlock, messages cannot arrive in the wrong order, and the conversation always terminates.
The pipeline:
.lu source → Tokenizer → Parser → AST → Spec Checker → Lean 4 Proofs → Python Codegen
↓
PROVED or VIOLATEDLU doesn't replace your AI agent framework. It makes it safe. Like TypeScript for JavaScript -- you keep your tools, you add guarantees.
LU Debugger -- Live web app: 3 AI agents (Customer, Warehouse, Payment) communicate on a verified OrderProcessing protocol. Click "Break" to see a protocol violation blocked in real time. Source code.
See the examples/ directory:
Agent Orchestration -- 3 AI agents with nested choice, 8/8 properties proved
Live Runner -- Real Claude API agents on a verified protocol
Standard Library -- 20 verified protocols across 5 categories
Or try the interactive Colab notebook -- 2 minutes, zero setup.
Lingua Universale is the core project by CervellaSwarm. We also publish these Python packages:
Package | What it does |
AST-powered code understanding (tree-sitter, PageRank) | |
Lifecycle hooks for Claude Code agents | |
Agent definition templates & team configuration | |
Deterministic task routing & validation | |
Multi-agent process management | |
Persistent session context across conversations | |
Immutable event logging & audit trail | |
Automated quality checks & scoring |
All Apache 2.0, Python 3.11+, tested, documented.
We welcome contributions! See CONTRIBUTING.md for guidelines.
Bug reports: GitHub Issues
Security: See SECURITY.md for responsible disclosure
Apache License 2.0 -- see LICENSE.
Copyright 2025-2026 CervellaSwarm Contributors.
Lingua Universale -- Verified protocols for AI agents.
Playground | LU Debugger | PyPI | VS Code | Blog | Colab Demo
Verify the formal safety properties declared in a .lu protocol.
Runs the static property checker (Layer 1) on all protocols found in
the source. Optionally, if Lean 4 is installed, also runs formal
verification (Layer 2).
Args:
protocol_text: Full .lu protocol definition text including a
"properties:" block, e.g.:
" properties:\n"
" always terminates\n"
" no deadlock\n"
" all roles participate\n"
Returns:
JSON string with:
ok (bool), protocols (list of protocol results), summary (dict).
Each protocol result has: protocol_name, all_passed, results (list).
Each result has: kind, verdict, evidence, params.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol_text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses running the static checker on all protocols and the optional Lean verification, including the prerequisite of Lean installation. No contradictions or missing critical behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an intro, argument explanation, and return value specification. It is relatively concise and front-loaded, though slightly lengthy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description is complete. It explains the input format, optional behavior, and return structure in sufficient detail. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining the 'protocol_text' parameter in detail, including example format and requirement for a 'properties' block. This adds significant meaning beyond the schema which only defines it as a string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verifying formal safety properties in .lu protocols. It specifies static checking and optional Lean verification, distinguishing it from sibling tools like lu_list_templates, lu_load_protocol, and lu_verify_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to verify properties) and mentions optional Lean verification if installed. It does not explicitly exclude scenarios, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Lingua Universale standard library protocol templates.
The standard library contains 20 verified protocols across 5 categories:
communication, data, business, ai_ml, security.
Args:
category: Optional filter. One of: communication, data, business,
ai_ml, security. Leave empty to list all templates.
Returns:
JSON string with:
ok (bool), templates (list), category_filter (str), total (int).
Each template has: name, category, description.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the return structure (JSON with ok, templates, category_filter, total) and the number of templates and categories. It does not cover error handling or edge cases, but for a read-only list tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, each sentence adds value. It is concise yet complete, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list with optional filter), the description covers all necessary context: purpose, parameter usage, and return format. No additional information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by specifying the allowed values for the category parameter and explaining the default behavior (empty lists all). This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available Lingua Universale standard library protocol templates, specifying the resource and action. It distinguishes from sibling tools (check, load, verify) by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear guidance on using the optional category filter, including the list of allowed categories and that leaving it empty lists all. However, it does not explicitly state when not to use this tool versus alternatives, though the context of siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a Lingua Universale (.lu) protocol definition.
Accepts the full text of a .lu file and returns the parsed protocol
structure: name, roles, steps, choices, and declared properties.
Args:
protocol_text: Content of a .lu file, e.g.:
"protocol RequestResponse:\n"
" roles: client, server\n"
" client asks server to process request\n"
" server returns response to client\n"
" properties:\n"
" always terminates\n"
" no deadlock\n"
Returns:
JSON string with keys:
ok (bool), protocol_name (str), roles (list[str]),
steps (list), properties (list), error (str on failure).
| Name | Required | Description | Default |
|---|---|---|---|
| protocol_text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the operation is a parsing action with no side effects, includes error handling, and fully covers behavior since no annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, including a helpful example, though slightly lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple tool with one parameter and no output schema, covering input format and output keys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides a clear example and explains the input format (full text of .lu file), adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it parses a .lu protocol definition and returns the parsed structure, clearly differentiating from sibling tools like lu_check_properties and lu_list_templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for loading a protocol from text but lacks explicit guidance on when to use alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify whether a message is valid in the context of an ongoing session.
Replays the existing message history against the protocol, then checks
whether next_message is the expected next step.
Args:
protocol_text: Full .lu protocol definition text.
messages: List of already-sent messages, each a dict with keys:
sender (str), receiver (str), action (str).
Actions are LU action names: "asks", "returns", "sends",
"proposes", "tells". These match the verbs in .lu source files.
next_message: The message to validate, same format as above.
Returns:
JSON string:
On success: {"valid": true, "step": N, "next_expected": "..."}
On violation: {"valid": false, "violation": "...", "expected": "...", "got": "..."}
On error: {"valid": false, "error": "..."}
Example:
protocol_text = "protocol Ping:\n roles: a, b\n a asks b to ping\n b returns pong to a\n properties:\n always terminates\n"
messages = [{"sender": "a", "receiver": "b", "action": "asks"}]
next_message = {"sender": "b", "receiver": "a", "action": "returns"}
# Returns: {"valid": true, ...}
| Name | Required | Description | Default |
|---|---|---|---|
| protocol_text | Yes | ||
| messages | Yes | ||
| next_message | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the replay-and-check algorithm, parameter semantics, and full return format. It does not mention side effects, but as a verification tool, none are expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: purpose sentence, then detailed argument descriptions, return format, and example. Slightly lengthy due to example but front-loaded and each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 required nested parameters with 0% schema coverage and an output schema described in text, the description provides complete information: argument formats, valid actions, return types, and a concrete example. An agent can invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description fully compensates by explaining each parameter: protocol_text is .lu protocol text, messages list with required keys, next_message same format, with example action values. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies if a message is valid given a protocol and message history, using verbs like 'verify' and 'replays'. It is distinct from siblings that check properties, list templates, or load protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the context ('in the context of an ongoing session') and the process (replaying history, checking next step). It does not explicitly state when not to use or alternatives, but siblings are sufficiently different, making intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0lu_check_propertieslu_list_templateslu_load_protocollu_verify_messageScored across 4 tools
Each tool has a distinct purpose: parsing, message verification, property checking, and template listing. No overlap in functionality; agents can easily select the right tool for their task.
Names follow a consistent 'lu_' prefix and verb_noun pattern (load_protocol, verify_message, check_properties, list_templates). Minor deviation: 'load_protocol' could be 'parse_protocol' but still clear and consistent.
With only 4 tools, the server is slightly under the typical 3-15 range, but this is appropriate for a niche protocol validation domain. The tools cover the core needs without bloat.
The server covers parsing, verification, property checking, and template listing, but misses a 'simulate' or 'validate full session' tool. Gaps exist for agents needing end-to-end protocol simulation or editing, but core workflows are supported.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Public agentic AI doctrine tools plus authenticated architecture, design, and spec validators.
The team layer for AI coding agents: shared contracts, collision alerts, E2EE sessions.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
