Loading ToolBench
Deterministic boolean logic verification engine with MCP server, REST API, and CLI. Evaluates boolean expressions, generates truth tables, synthesizes minimal forms using Quine-McCluskey algorithm, and audits logical contradictions in AI prompts, rules, and compliance policies.
Five tools with clear names and reasonable descriptions, but significant gaps in schema completeness and parameter documentation. All tools are READ_ONLY and domain-focused (boolean algebra), which is appropriate. However, input schemas lack proper JSON Schema type definitions for parameters, and output schemas are not formally documented. The `satisfiable` tool definition is truncated in the source, making full assessment impossible. Tool descriptions range from 80 - 180 chars (within baseline 34 - 392), but parameter descriptions are minimal or absent. No error handling guidance, no recovery paths, and no input validation constraints documented.
Check a set of boolean rules (e.g. from a system prompt) for contradictions, tautologies, and pairwise equivalences. Each rule should be a boolean expression using A-Z variables. Use consistent variable naming across rules (e.g. A=user_authenticated, B=is_admin).
Check whether two boolean expressions are logically equivalent. Two expressions are equivalent if they produce identical output columns for all possible input combinations.
Evaluate a boolean expression and return its full truth table.
Check whether a boolean expression is satisfiable. A satisfiable expression has at least one input combination that outputs 1. An unsatisfiable expression is a contradiction (always 0).
Simplify a boolean expression to its minimal sum-of-products form. Useful for finding redundant conditions, dead branches, or the canonical form of a complex expression.
Input schemas lack proper JSON Schema type definitions. Parameters are documented as strings with examples in descriptions, but no formal type, minLength, maxLength, pattern, or enum constraints are visible in the schema definitions.
Output schemas are not formally documented. Tool docstrings describe return dictionaries informally (e.g., 'Dictionary with keys: expression, variables, rows...'), but no JSON Schema is provided for LLM parsing or validation.
No error handling guidance. Tools do not document what happens on invalid input (e.g., malformed expression, unsupported operators, variable count exceeding 26). No recovery paths or actionable error messages are specified.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Parameter descriptions are minimal. The 'expression' parameter is described with an example ('A.(B+C)') but lacks constraints: no mention of variable range (A-Z only), operator precedence, parenthesis rules, or what happens with invalid syntax.
Tool 'satisfiable' definition is truncated in source (ends with 'def satisfiable(expression: str) -> dic'). Cannot verify schema, full description, or return type. Inferred tool, capped at 50.