MCP server de LiquidJava
Commit 26 oct 2026Expone las herramientas de verificación de LiquidJava a agentes LLM para ejecutar verificaciones, obtener diagnósticos estructurados y consultar el solver.
También conocido como liquid-java/liquidjava-mcp
- Stars
- 1
- Herramientas
- 8
- Descargas, 30 días
- —
- Última versión
- —
- Último commit
- 26 oct 2026
- Licencia
- MIT
¿Qué es LiquidJava MCP?
LiquidJava es un MCP server. Expone las herramientas de verificación de LiquidJava a agentes LLM para ejecutar verificaciones, obtener diagnósticos estructurados y consultar el solver. Expone 8 herramientas, como verify, get_diagnostics, get_locals.
Resumen generado a partir del README del proyecto
Acerca del MCP server de LiquidJava
Los ingenieros de software y los agentes de IA pueden realizar la verificación formal de código Java usando liquidjava-mcp. Este servidor se conecta a un cliente MCP a través de stdio, lo que permite a un agente ejecutar las herramientas de LiquidJava directamente sobre archivos Java locales. Ofrece una forma de ir más allá de la simple verificación basada en texto al proporcionar datos estructurados y legibles por máquina que un LLM puede procesar sin necesidad de un análisis manual.
Los usuarios pueden ejecutar la herramienta verify para obtener la salida estándar o usar get_diagnostics para recibir arrays detallados de errores y advertencias que contienen refinamientos y contraejemplos. El servidor también permite una inspección profunda del programa mediante herramientas como get_locals para el alcance de las variables, get_globals para alias y estados, y get_contracts para las especificaciones de los métodos. Para pruebas de lógica avanzada, se puede consultar el solver a través de check_validity y check_satisfiability para probar suposiciones y conclusiones personalizadas. El sistema incluye caché integrada para acelerar las solicitudes repetidas de los mismos archivos fuente.
Qué puedes hacer con él
- 1Analizar errores de verificación estructuradosUn agente de IA puede recuperar arrays de errores detallados que incluyen refinamientos y contraejemplos en lugar de analizar texto plano de la terminal.
- 2Inspeccionar refinamientos de variables en el scopeUn desarrollador puede pedirle a un agente que encuentre los predicados de refinamiento específicos para variables en una línea y columna determinadas.
- 3Verificar suposiciones lógicas personalizadasPuedes usar el solver para comprobar si un conjunto específico de suposiciones implica lógicamente una conclusión deseada.
- 4Extraer protocolos de typestateUn agente puede analizar un archivo Java para mapear los estados y las transiciones definidos por las anotaciones de LiquidJava.
Escrito a partir del README del proyecto. Cada caso de uso se verifica con una cita del mismo.
Herramientas de LiquidJava MCP 8
Detectado desde el READMEverifyget_diagnosticsget_localsget_globalsget_contractsget_state_machinecheck_validitycheck_satisfiability
| verify | — | |
| get_diagnostics | — | |
| get_locals | — | |
| get_globals | — | |
| get_contracts | — | |
| get_state_machine | — | |
| check_validity | — | |
| check_satisfiability | — |
Verificaciones automáticas
Ejecutado 14 nov 2026Informe completo →Aún no verificado. Un servidor necesita una puntuación de 80, ningún hallazgo grave y suficientes datos para que podamos revisarlo. Cómo funcionan las verificaciones · Qué corregir para obtener más puntos
- Repositorio de origen vinculado y accesibleliquid-java/liquidjava-mcp is public and reachablegithub.com/liquid-java/liquidjava-mcp ↗Aprobado
- El paquete indica este repositorio como su origenNo verificado
- Procedencia de la compilación (atestación de Sigstore)No verificado
- Licencia de código abierto (OSI)MITspdx.org/licenses/MIT.html ↗Aprobado
- Commit o lanzamiento en el último añoLast commit or release 2026-10-26github.com/liquid-java/liquidjava-mcp ↗Aprobado
- OpenSSF ScorecardNo verificado
- El nombre del paquete no es similar a un paquete popularNo verificado
- No hay avisos críticos en el paquete ni en sus dependenciasNo verificado
- Sin instrucciones ocultas para el modelo8 tool descriptions and the README read; no override phrases, credential paths or hidden charactersAprobado
- Las herramientas destructivas están etiquetadasNo tool named like delete, drop or execAprobado
- El endpoint remoto responde al handshake de MCPNo verificado
README
Ver en GitHubLiquidJava MCP
A Java MCP server that exposes LiquidJava verification tools to LLM agents over stdio.
It allows agents to run the LiquidJava verification, retrieve structured diagnostics, inspect the verification context, and query LiquidJava's solver with custom assumptions and conclusions. It also comes with a skill that guides agents on how and when to use the MCP tools.
Installation
Build the project with mvn package and then point your MCP client at the resulting jar:
{
"servers": {
"liquidjava-mcp": {
"type": "stdio",
"command": "java",
"args": [
"-jar",
"/path/to/liquidjava-mcp/target/liquidjava-mcp.jar"
]
}
}
}
Tools
Overview
| Tool | Purpose | Input | Output |
|---|---|---|---|
verify |
Run the verification and get human-readable output (same as the CLI) | path, debug? |
standard LiquidJava output |
get_diagnostics |
Run the verification and get more detailed structured diagnostics | path |
errors and warnings arrays (type, severity, location, message, refinements, hints, counterexamples) |
get_locals |
Inspect verification context (variables in scope) at a specific source position | path, file?, line, column |
variables (name, internal name, type, refinement, location) |
get_globals |
Inspect global definitions (aliases, ghosts, states) available in the program | path, file? |
aliases, ghosts, states |
get_contracts |
Inspect method and constructor contracts | path, className?, signature? |
contracts (qualified signature, parameters, return refinement, state transitions, location) |
get_state_machine |
Parse a Java file's LiquidJava typestate protocol | path |
stateMachine with states and transitions |
check_validity |
Check if assumptions imply a conclusion via the solver | variables, ghosts, assumptions, conclusion |
status (valid, invalid, or unknown), counterexample (for invalid results) |
check_satisfiability |
Check if constraints are satisfiable via the solver | variables, ghosts, constraints |
status (sat, unsat, or unknown), assignment (for satisfiable results) |
The verify, get_diagnostics, get_locals, get_globals, and get_contracts tools reuse cached analysis when the input path, source hash, and debug option match. Requests time out after 60 seconds, including time waiting for another analysis, and return a verifier error with any captured output.
verify
Runs the LiquidJava verification and returns the same output normally shown to developers.
Allows agents to inspect verification conditions, their simplifications, and solver results using the debug flag.
Input: File or directory path, with optional debug flag.
Output: Verification status and the standard LiquidJava verification output.
{
"path": ".../Example.java",
"debug": false
}
{
"success": false,
"output": "Running LiquidJava on: .../Example.java\n\nRefinement Error: input >= 0 && #ret¹ == input is not a subtype of #ret¹ > 0\n..."
}
get_diagnostics
Runs the LiquidJava verification and exposes diagnostics in a machine-readable format, avoiding the need for agents to parse terminal output.
Input: File or directory path.
Output: Verification status and errors and warnings arrays of structured diagnostics, including type, severity, location, message, refinements, VCs, details, hints, and counterexamples when available.
{
"path": ".../Example.java"
}
{
"success": false,
"errors": [
{
"refinements": {
"expected": "#ret_1 > 0",
"found": "input >= 0 && #ret_1 == input"
},
"vc": {
"expected": "#ret_1 > 0",
"found": "∀input:int, input >= 0 => \n∀#ret_1:int, #ret_1 == input",
"history": [
{
"implication": "∀input:int, input >= 0 => \n∀#value_0:int, #value_0 == input => \n∀#ret_1:int, #ret_1 == #value_0"
},
{
"implication": "∀input:int, input >= 0 => \n∀#ret_1:int, #ret_1 == input",
"simplification": "Substitution"
}
]
},
"type": "RefinementError",
"severity": "error",
"counterexample": [
{"variable": "input", "value": "0"},
{"variable": "#ret_1", "value": "0"}
],
"declarationLocation": {
"file": ".../Example.java",
"startColumn": 9,
"endLine": 14,
"endColumn": 5,
"startLine": 11
},
"location": {
"file": ".../Example.java",
"startColumn": 9,
"endLine": 13,
"endColumn": 21,
"startLine": 13
},
"message": "input >= 0 && #ret¹ == input is not a subtype of #ret¹ > 0"
}
],
"warnings": []
}
get_locals
Exposes the verification context available at a specific point in the program.
Input: A path to the Java source file or directory to verify, plus line and column identifying the source position to inspect. An optional file parameter specifies a different file for filtering variables. When omitted, path is used instead. Lines and columns are one-based.
Output: variables. Each variable includes its source name, verifier internalName, Java type, refinement predicate, and source location (inclusive ends). Entries include declarations and refinement instances recorded before the position in enclosing scopes. Internal names preserve relationships between predicates. Positions outside recorded scopes return an empty array. This exposes source-filtered verifier history; synthesized branch-merge instances can carry the original declaration location, so it does not reconstruct the exact solver state at the cursor.
{
"path": ".../Example.java",
"line": 13,
"column": 20
}
{
"variables": [
{
"name": "input",
"internalName": "input",
"location": {
"file": ".../Example.java",
"startColumn": 41,
"endLine": 11,
"endColumn": 45,
"startLine": 11
},
"type": "int",
"refinement": "input >= 0"
},
{
"name": "value",
"internalName": "#value_0",
"location": {
"file": ".../Example.java",
"startColumn": 13,
"endLine": 12,
"endColumn": 26,
"startLine": 12
},
"type": "int",
"refinement": "#value_0 == input"
},
{
"name": "value",
"internalName": "value",
"location": {
"file": ".../Example.java",
"startColumn": 13,
"endLine": 12,
"endColumn": 26,
"startLine": 12
},
"type": "int",
"refinement": "true"
},
{
"name": "ret",
"internalName": "#ret_1",
"location": {
"file": ".../Example.java",
"startColumn": 9,
"endLine": 13,
"endColumn": 21,
"startLine": 13
},
"type": "int",
"refinement": "#ret_1 == #value_0"
},
{
"name": "this#Example",
"internalName": "this#Example",
"location": {
"file": ".../Example.java",
"startColumn": 9,
"endLine": 13,
"endColumn": 21,
"startLine": 13
},
"type": "com.example.Example",
"refinement": "true"
}
]
}
get_globals
Provides global definitions available in the program.
Input: A path to the Java source file or directory to verify, optionally with a file identifying which source file's ghosts and states to return.
Output: aliases, ghosts, and states. Aliases include parameter names, parameter types, and predicates; ghosts and states include qualified names, return types, parameter types, and their defining refinements when available.
{
"path": ".../Example.java"
}
{
"aliases": [
{
"predicate": "v >= 0",
"parameterTypes": ["int"],
"parameters": ["v"],
"name": "Positive"
}
],
"ghosts": [
{
"qualifiedName": "com.example.Example.size",
"file": ".../Example.java",
"name": "size",
"parameterTypes": ["com.example.Example"],
"returnType": "int"
}
],
"states": [
{
"qualifiedName": "com.example.Example.closed",
"refinement": "state1(_) == 1",
"file": ".../Example.java",
"parameterTypes": ["com.example.Example"],
"returnType": "boolean",
"name": "closed"
},
{
"qualifiedName": "com.example.Example.open",
"refinement": "state1(_) == 0",
"file": ".../Example.java",
"parameterTypes": ["com.example.Example"],
"returnType": "boolean",
"name": "open"
}
]
}
get_contracts
Returns the method and constructor contracts registered during verification. This includes source contracts and external refinement contracts.
Input: A path to the Java source file or directory to verify. className optionally filters by an exact qualified target class name. signature optionally filters by an exact complete qualified method or constructor signature, including parameter types.
Output: Each contract includes its target class, signature, return type and refinement, refined parameters, paired state transitions, and declaration location.
{
"path": ".../Example.java",
"className": "com.example.Example",
"signature": "com.example.Example.requirePositive(int)"
}
{
"contracts": [
{
"className": "com.example.Example",
"signature": "com.example.Example.requirePositive(int)",
"returnType": "void",
"parameters": [
{"name": "input", "type": "int", "refinement": "input > 0"}
],
"returnRefinement": "true",
"stateTransitions": [],
"location": {
"file": ".../Example.java",
"startLine": 10,
"startColumn": 5,
"endLine": 11,
"endColumn": 6
}
}
]
}
get_state_machine
Parses a Java source file and returns the LiquidJava typestate protocol declared by its @StateSet and @StateRefinement annotations. The result describes the possible states, initial states, and method transitions. A transition's fromCondition and toCondition contain any non-state conditions such as cond ? state1 : state2 or cond && state1.
Input: path, an existing Java source file. Directories are not accepted because the parser returns the state machine for one source file at a time.
Output: An object containing a stateMachine value with the qualified class name, states, initial transitions, and method transitions. stateMachine is null when the file does not declare a state machine.
{
"path": ".../File.java"
}
{
"stateMachine": {
"className": "example.File",
"states": [
"open",
"closed"
],
"transitions": [
{
"from": "open",
"to": "closed",
"label": "close",
"fromCondition": null,
"toCondition": null
},
{
"from": "open",
"to": "open",
"label": "read",
"fromCondition": null,
"toCondition": null
}
],
"initialTransitions": [
{
"to": "open",
"toCondition": null
}
]
}
}
check_validity
Checks whether custom assumptions imply one conclusion using LiquidJava's solver, without verifying Java files. Declared ghost functions are translated as LiquidJava uninterpreted functions. Aliases, source constants, and implicit receiver/return/old-state bindings are not supported.
Input: variables (map of names to primitive or reference types), ghosts (map of names to uninterpreted function declarations with parameter types and a return type), assumptions (array of boolean predicate strings), and conclusion (boolean predicate string).
Output: status (valid, invalid, or unknown). Invalid results include a counterexample.
{
"variables": {"x": "int"},
"ghosts": {},
"assumptions": ["x >= 0"],
"conclusion": "x > 0"
}
{
"status": "invalid",
"counterexample": [{"variable": "x", "value": "0"}]
}
check_satisfiability
Checks whether custom constraints have a satisfying assignment using LiquidJava's solver. It returns sat, unsat, or unknown; sat results include the solver's assignment when available.
Input: variables (map of names to primitive or reference types), ghosts (map of names to uninterpreted function declarations with parameter types and a return type), and constraints (array of boolean predicate strings).
Output: status (sat, unsat, or unknown). Satisfiable results include an assignment.
{
"variables": {"x": "int"},
"ghosts": {},
"constraints": ["x > 0", "x < 2"]
}
{
"status": "sat",
"assignment": [{"variable": "x", "value": "1"}]
}
Preguntas sobre LiquidJava MCP
¿Qué herramientas proporciona LiquidJava MCP?
Expone 8 herramientas, incluidas verify, get_diagnostics, get_locals, get_globals, get_contracts.
¿Cómo instalo el MCP server de LiquidJava?
Compila el proyecto usando mvn package y apunta tu cliente MCP al archivo jar resultante utilizando el transporte stdio.
¿Puedo obtener informes de errores legibles por máquina en lugar de la salida de la terminal?
Sí, la herramienta get_diagnostics proporciona diagnósticos estructurados que incluyen errores y advertencias en arrays, lo que evita que los agentes tengan que analizar la salida de la terminal.
¿El servidor admite caché?
Sí, varias herramientas como verify, get_diagnostics y get_locals reutilizan el análisis en caché cuando coinciden la ruta de entrada, el hash del código fuente y la opción de depuración.
¿Existe un tiempo de espera para las solicitudes?
Sí, las solicitudes caducan tras 60 segundos, lo que incluye el tiempo de espera si se está ejecutando otro análisis.