The prolog-reasoner server enables LLMs to perform logical reasoning by executing SWI-Prolog code and managing reusable rule bases.
execute_prolog: Run arbitrary SWI-Prolog facts, rules, and queries. Supports CLP(FD) (for scheduling, optimization, puzzles), negation-as-failure (\+), recursion, and all standard SWI-Prolog built-ins. Returns capped result sets (configurable via max_results) with optional trace and error diagnostics. Execution is stateless, making results reproducible. Saved rule bases can be referenced to automatically prepend domain rules to the execution context.
save_rule_base: Save (or overwrite) a named collection of Prolog rules with syntax validation, description, and tags for later reuse.
list_rule_bases: List all saved rule bases with their metadata (name, description, tags).
get_rule_base: Retrieve the source code of a specific saved rule base.
delete_rule_base: Delete a saved rule base.
Prolog code acts as an auditable, inspectable intermediate representation, enabling multi-step inference, transitive reasoning, deduction chains, and exhaustive search with guaranteed correctness.
Enables running the Prolog reasoner in a containerized environment with bundled SWI-Prolog, allowing deployment without local Prolog installation.
Provides natural language to Prolog translation capabilities for OpenAI models, enabling logical reasoning and constraint solving through Prolog execution with self-correction loops.
SWI-Prolog as a "logic calculator" for LLMs — available as an MCP server and a Python library. Eliminate the black box from LLM logical reasoning.
LLMs excel at natural language but struggle with formal logic. Prolog excels at logical reasoning but can't process natural language. prolog-reasoner bridges this gap by exposing SWI-Prolog execution to LLMs.
On the built-in 30-problem logic benchmark:
Pipeline | Accuracy |
LLM-only ( | 22/30 (73.3%) |
LLM + prolog-reasoner | 27/30 (90.0%) |
The gap concentrates in constraint satisfaction and multi-step reasoning — the combinatorial territory LLMs are weak on and Prolog is strong on. Full breakdown below.
Related MCP server: MCP Solver
LLMs pattern-match; Prolog actually searches and solves. When the LLM writes its problem down as Prolog, two things happen at once:
Prolog handles the combinatorial work LLMs are weak on — constraint satisfaction, multi-step inference, exhaustive search.
The reasoning exists as code you can read, re-run, and debug. When it goes wrong, you see the exact Prolog that failed and why.
MCP server — Claude (or any MCP client) calls it as a logic solver during conversation. Rule bases let the LLM save stable domain rules once and reference them by name per call.
Python library — full NL→Prolog pipeline with self-correction. Requires OpenAI or Anthropic.
MCP tools: execute_prolog for arbitrary SWI-Prolog execution, plus list_rule_bases / get_rule_base / save_rule_base / delete_rule_base for reusable named rule bases (v14)
Rule bases: save stable Prolog rules once (e.g. chess move rules, legal axioms) and reference them by name from execute_prolog so the LLM only writes the situation-specific facts per call
Transparent intermediate representation: the Prolog code is the audit trail — inspect, modify, or verify before execution
CLP(FD) support: constraint logic programming for scheduling and optimization
Negation-as-failure, recursion, all standard SWI-Prolog features
Library mode: NL→Prolog translation with self-correction loop (OpenAI / Anthropic)
Python ≥ 3.10
SWI-Prolog installed and on PATH (≥ 9.0)
API key for OpenAI or Anthropic — only for library mode, not for the MCP server
# MCP server only (no LLM dependencies)
pip install prolog-reasoner
# Library with OpenAI
pip install prolog-reasoner[openai]
# Library with Anthropic
pip install prolog-reasoner[anthropic]
# Both providers
pip install prolog-reasoner[all]The MCP server exposes five tools — execute_prolog runs Prolog code written by the connected LLM, and four rule-base tools manage named, reusable Prolog modules. It does not call any external LLM API, so no API key is required.
{
"mcpServers": {
"prolog-reasoner": {
"command": "uvx",
"args": ["prolog-reasoner"]
}
}
}Or, if prolog-reasoner is installed directly:
{
"mcpServers": {
"prolog-reasoner": {
"command": "prolog-reasoner"
}
}
}Use Docker if you don't want to install SWI-Prolog locally:
docker build -f docker/Dockerfile -t prolog-reasoner .{
"mcpServers": {
"prolog-reasoner": {
"command": "docker",
"args": ["run", "-i", "--rm", "prolog-reasoner"]
}
}
}execute_prolog(prolog_code, query, rule_bases=None, max_results=100, trace=False)
prolog_code — Prolog facts and rules (string)
query — Prolog query to run, e.g. "mortal(X)" (string)
rule_bases — optional list of saved rule base names to prepend to prolog_code (in order). Use this to reuse stable domain rules across calls without re-sending them
max_results — cap the number of solutions returned (default 100)
trace — when True, attach a structured proof tree per solution to metadata.proof_trace. Opt-in sub-feature; has performance overhead and does not support CLP(FD), higher-order predicates, or assert/retract.
Returns a JSON object with success, output, query, error, and metadata.
On success, metadata includes execution_time_ms, result_count, truncated, and rule_bases_used. When rule bases were requested, rule_base_load_ms is also attached (disk I/O timing). On failure, metadata also includes error_category (one of syntax_error, undefined_predicate, unbound_variable, type_error, domain_error, evaluation_error, permission_error, timeout, trace_mechanism_error, unknown) and error_explanation — a natural-language hint for the connected LLM (or human) to decide how to fix the Prolog code.
Rule base tools — manage named, reusable Prolog modules under PROLOG_REASONER_RULES_DIR (defaults to ~/.prolog-reasoner/rules/). Names are restricted to [a-z0-9_-], length 1–64.
save_rule_base(name, content) — write or overwrite a rule base. Content is syntax-validated (parse-only) before the write; failures surface as RULEBASE_003. Returns {"success": true, "name": ..., "created": bool} where created is true on first write, false on overwrite. Files over max_rule_size are rejected with RULEBASE_005.
list_rule_bases() — return all saved rule bases with name, description, and tags. Metadata is extracted from leading % description: / % tags: comments in each file.
get_rule_base(name) — return the raw Prolog source of a saved rule base.
delete_rule_base(name) — remove a saved rule base.
For name/size/existence errors, the tools return {"success": false, "error": "...", "error_code": "RULEBASE_001"|"RULEBASE_002"|"RULEBASE_003"|"RULEBASE_005"} rather than raising. I/O failures (RULEBASE_004) are propagated as infrastructure errors.
Rule base conventions — start each rule base file with leading comments that double as list_rule_bases metadata:
% description: Chess piece movement rules
% tags: chess, games
piece_move(knight, (X1,Y1), (X2,Y2)) :- ...Then reference from execute_prolog:
{
"rule_bases": ["chess_moves"],
"prolog_code": "position(knight, (4,4)).",
"query": "piece_move(knight, (4,4), Target)"
}Rule bases also serve as the foundation for domain-specialized forks: ship a curated set (legal axioms, game rules, tax scenarios, etc.) bundled via BUNDLED_RULES_DIR as a ready-to-use reasoning package.
The library exposes PrologExecutor (Prolog-only, no LLM) and PrologReasoner (NL→Prolog pipeline, needs an LLM API key).
import asyncio
from prolog_reasoner.config import Settings
from prolog_reasoner.executor import PrologExecutor
async def main():
settings = Settings() # no API key needed
executor = PrologExecutor(settings)
result = await executor.execute(
prolog_code="human(socrates). mortal(X) :- human(X).",
query="mortal(X)",
)
print(result.output) # mortal(socrates)
asyncio.run(main())import asyncio
from prolog_reasoner import PrologReasoner, TranslationRequest, ExecutionRequest
from prolog_reasoner.config import Settings
from prolog_reasoner.executor import PrologExecutor
from prolog_reasoner.translator import PrologTranslator
from prolog_reasoner.llm_client import LLMClient
async def main():
settings = Settings(llm_api_key="sk-...") # from env or explicit
llm = LLMClient(
provider=settings.llm_provider,
api_key=settings.llm_api_key,
model=settings.llm_model,
timeout_seconds=settings.llm_timeout_seconds,
)
reasoner = PrologReasoner(
translator=PrologTranslator(llm, settings),
executor=PrologExecutor(settings),
)
translation = await reasoner.translate(
TranslationRequest(query="Socrates is human. All humans are mortal. Is Socrates mortal?")
)
print(translation.prolog_code)
result = await reasoner.execute(
ExecutionRequest(prolog_code=translation.prolog_code, query=translation.suggested_query)
)
print(result.output)
asyncio.run(main())All settings via environment variables (prefix PROLOG_REASONER_):
Variable | Default | Required for |
|
| library ( |
|
| library only — leave unset for MCP |
|
| library |
|
| library |
|
| library |
|
| both |
|
| both |
|
| both (where user-saved rule bases live) |
| unset | both (optional — synced into |
|
| both (per-file save cap; |
|
| library only (total budget for the "Available rule bases" prompt section; truncated with a marker when exceeded) |
|
| both |
benchmarks/ contains 30 logic problems across 5 categories (deduction, transitive, constraint, contradiction, multi-step) to compare LLM-only reasoning vs LLM+Prolog reasoning. The benchmark exercises the library path (translator + executor), since it requires the NL→Prolog step.
Measured on anthropic/claude-sonnet-4-6, single run over 30 problems:
Pipeline | Accuracy | Avg latency |
LLM-only | 22/30 (73.3%) | 1.7s |
LLM + Prolog | 27/30 (90.0%) | 3.8s |
Per-category breakdown:
Category | LLM-only | LLM + Prolog |
deduction | 6/6 | 6/6 |
transitive | 6/6 | 5/6 |
constraint | 3/7 | 6/7 |
contradiction | 4/4 | 3/4 |
multi-step | 3/7 | 7/7 |
The gap is concentrated in constraint (SEND+MORE, 6-queens, knapsack, K4 coloring, Einstein-lite) and multi-step (Nim game theory, 3-person knights-and-knaves, TSP-4, zebra puzzle) — exactly the combinatorial/search-heavy territory where symbolic solvers outperform pattern completion. On purely deductive or transitive questions the LLM is already strong and Prolog adds latency without accuracy gains.
All 3 LLM+Prolog failures were Prolog execution errors from malformed LLM-generated code (missing predicate definitions, unbound CLP(FD) variables) rather than reasoning errors — addressable via prompt tuning. Notably, every failure is inspectable: you can see the exact Prolog that failed and why, rather than a wrong natural-language answer with no explanation.
docker run --rm -e PROLOG_REASONER_LLM_API_KEY=sk-... \
prolog-reasoner-dev python benchmarks/run_benchmark.pyResults are saved to benchmarks/results.json.
Several Prolog MCP servers exist, each with different design choices. prolog-reasoner is intentionally stateless and spot-use — Prolog is a calculator you call when logic matters, not the backbone of your agent's memory.
prolog-reasoner | Stateful Prolog MCPs | |
Prolog's role | Per-call reasoning tool | Project-wide knowledge base |
State | Stateless execution (each call independent); optional named rule bases for reusable static rules, no inter-call session memory | Persistent sessions / layered KBs |
Reproducibility | Same input (incl. same rule bases) → same output, always | Depends on accumulated state |
Integration effort | Use where logic matters, skip where it doesn't | Architectural commitment |
A/B testable vs LLM-only | Yes (each call is a controlled experiment) | Structurally not comparable |
This is also why accuracy benchmarks are published here and not elsewhere: statelessness is what makes a side-by-side comparison possible.
If you need persistent agent memory, hallucination-safeguarded fact storage, or a full neuro-symbolic substrate, other projects may fit better:
adamrybinski/prolog-mcp — Trealla WASM with save/load sessions
umuro/prolog-mcp — layered KB with file-backed persistence
vpursuit/model-context-lab — SWI-Prolog with security sandboxing
dr3d/prolog-reasoning — neuro-symbolic memory with write-path safety
We're the spot-use option.
# Build dev image
docker build -f docker/Dockerfile -t prolog-reasoner-dev .
# Run tests (no API key needed — LLM calls are mocked)
docker run --rm prolog-reasoner-dev
# With coverage
docker run --rm prolog-reasoner-dev pytest tests/ -v --cov=prolog_reasoner
# Or via docker compose
docker compose -f docker/docker-compose.yml run --rm testMIT
Delete a saved rule base by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It indicates a destructive action but lacks details on reversibility, permissions, or error handling. The bare statement is insufficient for an agent to anticipate consequences.
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 a single, short sentence that is front-loaded with the key action. While extremely concise, it contains no unnecessary words. It is appropriately sized for a simple tool but could benefit from minor structural improvements.
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 simplicity of the tool and presence of an output schema, the description is adequate for basic differentiation from siblings. However, it omits behavioral context such as confirmation or side effects, leaving gaps for a complete understanding.
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?
With 0% schema description coverage, the description must add meaning to the 'name' parameter beyond the type. It merely repeats 'by name' without explaining format, constraints, or examples, providing no additional semantics.
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 action ('Delete') and the resource ('saved rule base') with the identifying mechanism ('by name'). It unambiguously distinguishes from siblings like 'get_rule_base' or 'list_rule_bases'.
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?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or caveats. The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute Prolog code and return reasoning results.
Write Prolog facts and rules, then run a query against them. Supports CLP(FD) constraints, negation-as-failure, and all standard SWI-Prolog features.
| Name | Required | Description | Default |
|---|---|---|---|
| prolog_code | Yes | Prolog code (facts and rules). | |
| query | Yes | Prolog query to execute (e.g. "mortal(X)"). | |
| rule_bases | No | Names of previously saved rule bases to include. Rules are prepended to ``prolog_code`` in the specified order. Use this for domain-specific rules (e.g. game mechanics, legal rules) that should be reused across queries. | |
| max_results | No | Maximum number of results (prevents infinite loops). | |
| trace | No | When True, include structured proof trees per solution in metadata.proof_trace. Adds meta-interpreter overhead; opt-in. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It mentions supported features (CLP(FD), etc.) but omits behavioral traits such as side effects, safety, error handling, or permissions. As an execution tool, it should disclose whether it modifies state or is read-only.
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?
Three concise sentences, each serving a distinct purpose: purpose, usage, and capabilities. No wasted words; front-loaded with key 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 complexity (5 params, output schema exists), description is largely complete for the core function. It does not mention the rule_bases parameter or trace behavior, but these are well-documented in the schema. With output schema present, return values are covered.
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 100%, so description adds some value by summarizing supported Prolog features, which is relevant to the prolog_code and query parameters. However, it does not elaborate on parameter semantics beyond what the schema already provides.
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?
Description clearly states the verb (execute) and resource (Prolog code) and result (reasoning results). It distinguishes from sibling tools which manage rule bases, making the purpose unambiguous.
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?
No explicit guidance on when to use this tool vs. siblings (e.g., save_rule_base, delete_rule_base). The description does not mention alternatives or provide pre/post conditions, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the Prolog source of a saved rule base.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only mentions retrieval. Does not disclose read-only nature, error handling (e.g., behavior when rule base not found), or any side effects.
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?
Single concise sentence with no unnecessary words. Could be improved with structured formatting but appropriate for the information provided.
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?
Output schema exists so description needn't detail returns, but lacks mention of error conditions, prerequisites, or behavior when rule base doesn't exist.
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?
Single parameter 'name' has no description in schema and the tool description adds no explanation of what 'name' refers to (e.g., name of the rule base). Minimal value 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?
Description clearly states the action 'Retrieve' and the resource 'Prolog source of a saved rule base', distinguishing it from siblings like 'delete_rule_base' and 'execute_prolog'.
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?
No guidance on when to use this tool versus siblings. Does not specify prerequisites (e.g., rule base must exist) or context where listing or executing would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all saved rule bases with description and tags.
Returns {"rule_bases": [{"name": str, "description": str, "tags": list[str]}, ...]} sorted by name. Metadata is extracted
from the leading % description: / % tags: comments of each
rule base file (see §4.10).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that results are sorted by name and describes the metadata extraction process from file comments. This adds behavioral context beyond the empty schema.
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 two sentences plus a return format, front-loaded with the core purpose. Every sentence adds value without extraneous content.
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 no parameters and an output schema, the description fully explains the return structure, sorting, and metadata source. It provides sufficient context for use alongside sibling tools.
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?
The tool has no parameters, and schema coverage is 100%. Per guidelines, the baseline is 4. The description adds no parameter info, which is appropriate.
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 explicitly states 'List all saved rule bases', which is a specific verb and resource. This clearly distinguishes it from sibling tools that delete, execute, get, or save rule bases.
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 clearly indicates that this tool lists all rule bases, implying it is for reading/listing purposes. While no explicit when-not or alternatives are given, the context of siblings makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a named rule base containing Prolog rules that can be reused
across execute_prolog calls.
Use this for stable, reusable knowledge (e.g. piece_moves for
chess piece movement rules). For one-time facts, include them
directly in prolog_code instead.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| content | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It states 'Save' but does not disclose whether this overwrites existing rule bases, if any permissions are needed, or what the side effects are. The behavioral context is insufficient for a mutation tool.
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?
Two sentences front-load the action and scope, then provide a usage example and contrast. Every sentence adds value; no fluff.
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 covers purpose and usage guidelines adequately, but lacks behavioral transparency and parameter semantics. Given the existence of an output schema (which presumably documents return values), completeness is moderate but not comprehensive.
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 description coverage is 0%, and the description adds minimal parameter detail. It mentions 'name' and 'content' but does not explain expected formats, constraints, or what constitutes valid Prolog rules. The parameters are left almost entirely to schema interpretation.
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: 'Save a named rule base containing Prolog rules that can be reused across execute_prolog calls.' It uses a specific verb and resource, and distinguishes usage from including rules directly in prolog_code.
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?
Explicit guidelines are given: use for stable, reusable knowledge (e.g., chess piece movement rules), and for one-time facts, include them directly in prolog_code instead. This provides clear when-to-use and when-not-to-use advice.
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.
v0.1.1delete_rule_baseexecute_prolog2 fields changedInput schema / properties / rule_basesAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Names of previously saved rule bases to include. Rules\nare prepended to ``prolog_code`` in the specified order. Use\nthis for domain-specific rules (e.g. game mechanics, legal\nrules) that should be reused across queries."
+}Input schema / properties / traceAdded value: +{
+ "default": false,
+ "description": "When True, include structured proof trees per solution in\nmetadata.proof_trace. Adds meta-interpreter overhead; opt-in.",
+ "type": "boolean"
+}get_rule_baselist_rule_basessave_rule_basev0.1.0execute_prologScored across 5 tools
Each tool targets a distinct action: delete, execute, get, list, or save rule bases, with no overlap in functionality.
All tool names follow a clear verb_noun pattern with snake_case (e.g., delete_rule_base, execute_prolog), maintaining uniformity.
Five tools is well-scoped for a Prolog reasoning server, covering rule base CRUD and execution without excess or deficiency.
Core operations are present (CRUD for rule bases plus execution), but missing an explicit update tool; users must delete and re-save to modify a rule base.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Long-term memory for AI agents: semantic facts, episodic events, and procedural workflows
Memory that reasons: continual learning for stateful agents. Better context, fewer tokens.
Jailbreak-proof AI guardrails. Automated Reasoning SMT solver, not an LLM. ZK proofs included.
