LiquidJava MCP server
2026년 10월 26일 커밋LiquidJava 검증 도구를 LLM agent에 노출하여 검증을 실행하고, 구조화된 진단 데이터를 가져오며, solver를 쿼리할 수 있습니다.
다른 이름 liquid-java/liquidjava-mcp
- 스타
- 1
- Tools
- 8
- 다운로드, 30일
- —
- 최신 버전
- —
- 마지막 커밋
- 2026년 10월 26일
- 라이선스
- MIT
LiquidJava MCP란?
LiquidJava은(는) MCP server입니다. LiquidJava 검증 도구를 LLM agent에 노출하여 검증을 실행하고, 구조화된 진단 데이터를 가져오며, solver를 쿼리할 수 있습니다. 8개 도구를 제공합니다. 예: verify, get_diagnostics, get_locals.
프로젝트 README에서 생성된 요약
LiquidJava MCP server 정보
소프트웨어 엔지니어와 AI agent는 liquidjava-mcp를 사용하여 Java 코드의 형식 검증(formal verification)을 수행할 수 있습니다. 이 server는 stdio를 통해 MCP client에 연결되어, agent가 로컬 Java 파일에서 LiquidJava 도구를 직접 실행할 수 있도록 합니다. 단순한 텍스트 기반 검증을 넘어, LLM이 수동 파싱 없이 처리할 수 있는 구조화된 기계 판독 가능 데이터를 제공합니다.
사용자는 표준 출력을 위해 verify 도구를 실행하거나, refinement 및 counterexample이 포함된 상세 에러 및 경고 배열을 받기 위해 get_diagnostics를 사용할 수 있습니다. 또한 이 server는 변수 범위를 위한 get_locals, 별칭 및 상태를 위한 get_globals, 메서드 명세를 위한 get_contracts와 같은 도구를 통해 프로그램에 대한 심층적인 검사를 지원합니다. 고급 로직 테스트를 위해 check_validity 및 check_satisfiability를 통해 solver를 쿼리하여 사용자 정의 가정과 결론을 테스트할 수 있습니다. 시스템에는 동일한 소스 파일에 대한 반복적인 요청 속도를 높이기 위한 내장 캐싱 기능이 포함되어 있습니다.
활용 사례
- 1구조화된 검증 에러 분석AI agent는 가공되지 않은 터미널 텍스트를 파싱하는 대신 refinement 및 counterexample이 포함된 상세 에러 배열을 가져올 수 있습니다.
- 2범위 내 변수 refinement 조사개발자는 agent에게 특정 라인과 컬럼에 있는 변수에 대한 구체적인 refinement predicate를 찾아달라고 요청할 수 있습니다.
- 3사용자 정의 논리 가정 검증solver를 사용하여 특정 가정 세트가 원하는 결론을 논리적으로 함의하는지 확인할 수 있습니다.
- 4typestate 프로토콜 추출agent는 Java 파일을 파싱하여 LiquidJava 어노테이션에 정의된 상태와 전이(transition)를 매핑할 수 있습니다.
프로젝트의 README를 바탕으로 작성되었습니다. 모든 활용 사례는 해당 내용의 인용문과 대조하여 확인합니다.
LiquidJava MCP 도구 8
README에서 감지됨verifyget_diagnosticsget_localsget_globalsget_contractsget_state_machinecheck_validitycheck_satisfiability
| verify | — | |
| get_diagnostics | — | |
| get_locals | — | |
| get_globals | — | |
| get_contracts | — | |
| get_state_machine | — | |
| check_validity | — | |
| check_satisfiability | — |
자동 검사
2026년 11월 14일에 실행됨전체 보고서 →아직 인증되지 않았습니다. 서버는 80점 이상의 점수, 심각한 결함 없음, 그리고 검사에 충분한 데이터를 갖추어야 합니다. 검사 방식 · 점수를 높이기 위해 수정할 항목
- 소스 저장소 연결 및 접근 가능liquid-java/liquidjava-mcp is public and reachablegithub.com/liquid-java/liquidjava-mcp ↗통과
- 패키지가 이 저장소를 소스로 명시검사되지 않음
- 빌드 출처(Sigstore 증명)검사되지 않음
- 오픈 소스 라이선스 (OSI)MITspdx.org/licenses/MIT.html ↗통과
- 최근 1년 내 커밋 또는 릴리스Last commit or release 2026-10-26github.com/liquid-java/liquidjava-mcp ↗통과
- OpenSSF Scorecard검사되지 않음
- 패키지 이름이 인기 패키지와 유사하지 않음검사되지 않음
- 패키지 및 해당 종속성에 중요한 보안 권고 없음검사되지 않음
- 모델에 대한 숨겨진 지침 없음8 tool descriptions and the README read; no override phrases, credential paths or hidden characters통과
- 파괴적인 도구에 라벨 표시됨No tool named like delete, drop or exec통과
- 원격 엔드포인트가 MCP 핸드셰이크에 응답검사되지 않음
README
GitHub에서 보기LiquidJava 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"}]
}
LiquidJava MCP 질문
LiquidJava MCP는 어떤 도구를 제공하나요?
8개 도구를 제공합니다. 예: verify, get_diagnostics, get_locals, get_globals, get_contracts.
LiquidJava MCP server를 어떻게 설치하나요?
mvn package를 사용하여 프로젝트를 빌드한 후, stdio transport를 통해 MCP client가 생성된 jar 파일을 가리키도록 설정하십시오.
터미널 출력 대신 기계가 읽을 수 있는 에러 보고서를 받을 수 있나요?
네, get_diagnostics 도구를 통해 에러와 경고가 배열 형태로 포함된 구조화된 진단 데이터를 제공하므로, agent가 터미널 출력을 직접 파싱할 필요가 없습니다.
서버에서 캐싱을 지원하나요?
네, verify, get_diagnostics, get_locals와 같은 여러 도구는 입력 경로, 소스 해시 및 디버그 옵션이 일치할 경우 캐시된 분석 결과를 재사용합니다.
요청에 대한 타임아웃이 있나요?
네, 요청은 60초 후에 타임아웃되며, 이 시간에는 다른 분석을 기다리는 시간이 포함됩니다.