Runtime constitutional verification for AI answers with claim-level reasoning chains, formal ECS scoring, 7-angle red team (Glassbox Court), and deterministic audit logs.
Glass Box Framework MCP defines 6 tools with clear, domain-specific names (glassbox_*) and detailed descriptions (avg 180 chars). All tools are READ_ONLY and well-scoped. However, input schemas lack explicit type definitions and constraints for several parameters. Parameter descriptions are present but generic (e.g., 'Optional list of constitutional intents' lacks format/structure details). Output schemas are not documented in the tool definitions, responses are described narratively but not as structured JSON schemas. Error handling is minimal; no recovery guidance or actionable error messages visible. Tool composition is sound (each does one thing), but parameter validation rules are not explicit.
Run the full Glass Box Framework pipeline and export as an AuditRecord with deterministic log_id. Returns complete audit trail with all findings, scores, and reasoning.
Extract claims from an answer with reasoning chains, confidence scores, supporting evidence, and attack surface analysis for each claim.
Assemble a Trust Card from prebuilt parts: claims, red-team report, ECS report, and optional constitution report. Generates deterministic audit reference.
Run Glassbox Court: 7-angle adversarial red-team probes (fabrication, source manipulation, bias injection, context attack, overconfidence, underspecification, constitutional violation) against a question/answer pair.
Compute Epistemic Confidence Score (ECS) from prebuilt parts: groundedness, coherence, calibration, red-team resistance, and constitutional compliance. Supports arithmetic or geometric aggregation with custom weights.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Trust Card with verdict, ECS breakdown') but do not provide structured JSON schema definitions. LLMs cannot reliably extract fields from undocumented responses.
Parameter type constraints missing. 'intents' is described as 'Optional list of constitutional intents' but lacks format, length, or content constraints. 'weights' in glassbox_score_ecs is an object but has no schema for valid keys or value ranges (0-1?).
No error handling or recovery guidance. Tools lack descriptions of failure modes, retryability, or actionable error messages. If a tool fails, the LLM has no guidance on what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Run a question/answer pair through the entire Glass Box Framework: claim extraction → constitution compile + evaluate → Glassbox Court (red-team) → ECS → verdict. Returns a Trust Card with verdict, ECS breakdown, per-claim reasoning, all 7 red-team probes, and the deterministic audit reference.
Parameter descriptions lack actionable constraints. 'mode' in glassbox_score_ecs is described as 'Aggregation mode: arithmetic or geometric' but not as an enum constraint. LLMs may hallucinate other modes.
Tool composition risk: glassbox_verify_answer appears to be a wrapper around extract_claims + score_ecs + red_team + generate_trust_card. If the full pipeline is the common case, this is fine; but if users often need intermediate steps, the granular tools should be discoverable and their outputs chainable.