Skip to main content
Glama

check_entailment

Determine whether SMT-LIB premises entail a conclusion by testing unsatisfiability of premises plus negated conclusion in Z3 and cvc5, returning solver verdicts and caveats.

Instructions

Check whether a conclusion is logically entailed by a set of premises, by asking whether (premises AND NOT conclusion) is unsatisfiable, cross-checked in both Z3 and cvc5.

YOU (the calling model) are responsible for translating the user's prose question into declarations, premises, and conclusion. This server does NOT interpret English — it only runs the SMT-LIB you hand it. Pass the user's original wording in prose so the English and the formalization travel together in the evidence trail.

Before presenting the verdict to the user as an answer about their original English question, SHOW THEM THE FORMALIZATION (the declarations, premises, and conclusion, or the assembled smtlib_script) and get their agreement that it captures what they meant. A verdict from this tool is a fact about the formalization, not directly about the user's English — whether the formalization is a faithful translation of their intent is the user's call, not yours.

Report exactly what the solvers returned. Do not upgrade "both solvers said unsat under these bounds" into an unqualified "yes, this is true" — an ENTAILMENT_HOLDS verdict is bounded-unsat relative to the premises and declarations as written, not an unbounded proof about the world. Read the caveats list and pass its contents along; each one names a specific way the guarantee is weaker than it may sound (quantifiers, nonlinear arithmetic, uninterpreted sorts, or a bounded check). If status comes back DISAGREEMENT, that is the headline: tell the user the two solvers returned different verdicts and that the result must not be trusted, do not average or pick one to report.

declarations are full SMT-LIB forms, e.g. (declare-const x Int) or (declare-fun key (String) String). premises and conclusion are bare boolean terms, e.g. (> x 5) — this tool wraps each premise in (assert ...) for you (a premise that already starts with (assert is accepted as-is, not double-wrapped).

Worked example (propositional modus ponens): declarations = ["(declare-const p Bool)", "(declare-const q Bool)"] premises = ["(=> p q)", "p"] conclusion = "q" -> entailment holds (both solvers report the negated-conclusion script is unsatisfiable).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
logicNo
proseNo
premisesYes
conclusionYes
timeout_msNo
declarationsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses the dual-solver cross-check, the meaning of DISAGREEMENT, the caveats list, the bounded-unsat limitation, and the automatic (assert ...) wrapping of premises including the start-with-assert exception. This is unusually rich behavioral disclosure for a solver tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and mechanism are front-loaded in the first sentence, and the subsequent paragraphs on translation ownership, user confirmation, and verdict reporting each carry real decision-relevant content for a high-stakes tool. It is lengthy and could be tightened, but it is not padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With six parameters, no annotations, and no output schema, the description does the heavy lifting: it names the meaningful return fields (status, caveats, ENTAILMENT_HOLDS, DISAGREEMENT) and defines the negation/unsat semantics. What is missing is a fuller picture of the response shape and the role of the `logic` parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it explains the format-critical parameters well: declarations are full SMT-LIB forms with examples, premises/conclusion are bare boolean terms (with wrapping behavior), and prose is the original wording carried in the evidence trail. It leaves `logic` (which SMT logic to select) and `timeout_ms` (only visible as a default) unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a precise verb+resource (check entailment of a conclusion by premises) and pins down the exact mechanism (unsatisfiability of premises AND NOT conclusion, cross-checked in Z3 and cvc5). That mechanism uniquely separates it from check_satisfiability and run_smtlib, so an agent can route without opening the schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Strong contextual guidance: the calling model is told it owns the prose-to-SMT-LIB translation, must show the formalization to the user before presenting a verdict, and must treat DISAGREEMENT as untrusted. It does not, however, explicitly contrast when to reach for check_satisfiability or run_smtlib instead, so routing is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.