Loading ToolBench
Epistemic Warrant Protocol — deterministic boundary between agent memory and justified acceptance
EWP-MCP defines 7 domain-specific tools with clear epistemic warrant semantics. All tools have descriptions (avg 120 chars) and input schemas with typed parameters. However, schemas lack formal JSON Schema constraints (no enums, patterns, or minLength/maxLength), parameter descriptions are minimal (avg 45 chars), and output schemas are undocumented. Error handling uses custom McpError codes but provides limited recovery guidance. Tool names follow verb_noun convention (warrant_now, evidence_view_put) but are domain-jargon-heavy, risking LLM confusion. No tool annotations (readOnlyHint, destructiveHint) despite clear read/write semantics. Composition is sound, tools chain logically (view_put → warrant_now → may_act), but parameter naming inconsistencies (view vs view_id, proposition_id required in some, optional in others) create friction.
Record a single verification check (external test, human attestation, etc.) against a proposition.
Record a single evidence item (supporting or opposing) for a proposition.
Retrieve a stored EvidenceView by proposition_id and view_id.
Store an EvidenceView containing assertions, evidence items, and verification checks. Enforces ingest_attestation boundary for trusted origins.
Evaluate whether an agent may perform an action given warrant and risk policy. Returns MAY_ACT, REQUIRE_CONFIRMATION, or DENY.
Retrieve memory context for a proposition: current assertions, supporting/opposing evidence, and verification status.
Output schemas undocumented. No tool returns a documented schema, LLMs cannot predict response structure or plan downstream calls. tool_view_put returns {stored, proposition_id, view_id, assertions, checks} but this is inferred from code, not declared in tool definition.
Parameter descriptions are minimal (avg 45 chars). E.g., 'Proposition identifier' lacks context on format, length, or uniqueness. 'Policy identifier' does not explain what policies are available or how to discover them. LLMs cannot infer valid values.
No JSON Schema constraints (enums, patterns, minLength). Parameters like 'policy_id' accept free-form strings with no validation hints. 'view_id' defaults to 'mcp' but no enum of valid view IDs is declared. Invites hallucinated values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2025-06-18+ | v2 |
Compute warrant (epistemic justification) for a proposition given evidence, policy, and evaluation time. Returns normative axes: acceptance, conflict, verification, currency, sufficiency.
No tool annotations despite clear semantics. ewp_warrant_now and ewp_evidence_view_get are read-only; ewp_evidence_view_put, ewp_check_record, ewp_evidence_record are destructive writes. Missing readOnlyHint and destructiveHint annotations prevent LLMs from reasoning about safety and retry logic.
Error handling lacks recovery guidance. McpError codes (EWP_REFUSE_UNATTESTED_ORIGIN, EWP_MISSING_EVALUATED_AT) are domain-specific but do not suggest next steps. E.g., 'evaluated_at is required' does not explain format (ISO 8601) or how to obtain current time.