Un lenguaje para protocolos de agentes de IA verificados.
Pruébalo en tu navegador -- no requiere instalación. Observa agentes de IA en vivo -- 3 agentes en un protocolo verificado.
Tus agentes de IA hablan entre sí, pero nada garantiza que sigan las reglas. Remitente incorrecto, orden de mensajes erróneo, pasos faltantes... y solo te enteras en producción.
Lingua Universale (LU) es un verificador de tipos para conversaciones de agentes de IA. Tú defines el protocolo, LU demuestra que es correcto y el tiempo de ejecución lo hace cumplir.
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 nextEl protocolo dice que el revisor es el siguiente. El tiempo de ejecución lo bloquea. No porque confíes en el código, sino porque el tipo de sesión lo hace imposible.
Related MCP server: edict-lang
pip install cervellaswarm-lingua-universaleO pruébalo primero: Playground (se ejecuta en tu navegador mediante 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 participateLuego verifícalo:
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.Prueba matemática. No es una prueba que pasa hoy y falla mañana.
Característica | Descripción |
Compilador completo | Tokenizador, analizador (64 reglas), AST, verificador de contratos, generación de código Python |
9 propiedades verificadas |
|
20 protocolos stdlib | IA/ML, Negocios, Comunicación, Datos, Seguridad -- listos para usar |
Linter + Formateador |
|
Servidor LSP | Diagnósticos, información al pasar el ratón, autocompletado, ir a definición, formato |
Extensión de VS Code | |
Chat interactivo |
|
Playground en navegador | Pruébalo ahora -- Comprobar, Lint, Ejecutar, Chat |
Puente Lean 4 | Generar y verificar pruebas matemáticas |
REPL |
|
Andamiaje de proyectos |
|
37 módulos. 3979 pruebas. Cero dependencias externas. Biblioteca estándar de Python pura.
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 serverAñade la verificación de protocolos a tu flujo de trabajo de GitHub Actions:
# .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/El código de salida es distinto de cero en caso de infracciones -- funciona con cualquier sistema de CI.
LU se basa en tipos de sesión multiparte (Honda, Yoshida, Carbone -- POPL 2008). Los tipos de sesión describen protocolos de comunicación como tipos: si dos procesos siguen el mismo tipo de sesión, no pueden bloquearse, los mensajes no pueden llegar en el orden incorrecto y la conversación siempre termina.
El flujo de trabajo:
.lu source → Tokenizer → Parser → AST → Spec Checker → Lean 4 Proofs → Python Codegen
↓
PROVED or VIOLATEDLU no reemplaza tu marco de trabajo de agentes de IA. Lo hace seguro. Como TypeScript para JavaScript: mantienes tus herramientas, añades garantías.
LU Debugger -- Aplicación web en vivo: 3 agentes de IA (Cliente, Almacén, Pago) se comunican bajo un protocolo OrderProcessing verificado. Haz clic en "Break" para ver una infracción de protocolo bloqueada en tiempo real. Código fuente.
Consulta el directorio examples/:
Orquestación de agentes -- 3 agentes de IA con elección anidada, 8/8 propiedades demostradas
Ejecutor en vivo -- Agentes reales de la API de Claude bajo un protocolo verificado
Biblioteca estándar -- 20 protocolos verificados en 5 categorías
O prueba el cuaderno de Colab interactivo -- 2 minutos, configuración cero.
Lingua Universale es el proyecto principal de CervellaSwarm. También publicamos estos paquetes de Python:
Paquete | Qué hace |
Comprensión de código basada en AST (tree-sitter, PageRank) | |
Ganchos de ciclo de vida para agentes de Claude Code | |
Plantillas de definición de agentes y configuración de equipos | |
Enrutamiento y validación determinista de tareas | |
Gestión de procesos multi-agente | |
Contexto de sesión persistente entre conversaciones | |
Registro de eventos inmutable y pista de auditoría | |
Verificaciones y puntuación de calidad automatizadas |
Todo bajo Apache 2.0, Python 3.10+, probado y documentado.
¡Damos la bienvenida a las contribuciones! Consulta CONTRIBUTING.md para conocer las directrices.
Informes de errores: GitHub Issues
Seguridad: Consulta SECURITY.md para la divulgación responsable
Licencia Apache 2.0 -- consulta LICENSE.
Copyright 2025-2026 Colaboradores de CervellaSwarm.
Lingua Universale -- Protocolos verificados para agentes de IA.
Playground | LU Debugger | PyPI | VS Code | Blog | Demo en Colab
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.
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.
Zero-trust gateway for AI agents: score tool calls, verify agent cards, enforce policy, audit.
