Loading ToolBench
Deterministic evidence-packet linter for claim-backed AI output with support for sanctions screening, deal-risk triage, and agent output verification.
This STDIO-only MCP server implements 16 validation and schema-discovery tools for an Agenda Intelligence system. Tool naming follows verb conventions (validate_*, get_*, list_*, check_*, audit_*, create_*, append_*, verify_*, source_*, score_*), which is strong. Most tools have descriptions, though they vary in quality and length. Input schemas are present for all tools, typically declaring object or array parameters with basic type info. However, parameter-level descriptions are sparse or missing in most tools, only a few param descriptions are substantive (e.g. 'brief_json' in validate_brief: 'The brief object to validate'). Output schemas are not documented anywhere in the source code, which violates a critical pattern. Error handling is minimal, no recovery guidance, no categorization. The tools are read-only (low risk), but descriptions lack actionable context about when/why to call them, which limits LLM tool selection. The descriptions range from adequate (check_evidence_packet, get_schema) to minimal (list_source_categories has no description). No tool annotations (readOnlyHint) are visible, though all tools are genuinely read-only. The server is transport-capped at 50 due to STDIO-only design.
Deterministic assembly of evidence pack from caller-supplied fields, validated on every call. Returns the document to the caller and writes nothing to disk.
Validate a claim-level evidence-audit dict against evidence-audit.schema.json and report a small summary: distribution of `support_level`, orphan evidence_id refs, and the count of explicitly listed `unsupported_claims`. Honest scope: schema-level only. Does not verify factual truth.
Run the primary evidence-packet preflight over caller-supplied text. The result reports packet completeness, quote mismatches, lexical-support gaps, and unmatched numbers. It does not retrieve sources or assess factual truth, and every result still requires human review.
Schema validity plus post-hoc evidence-readiness quality guardrails for Agenda memos.
Deterministic assembly of a brief from caller-supplied fields, validated on every call. Returns the document to the caller and writes nothing to disk.
Output schemas are not documented. Tools like verify_quotes, list_lenses, and get_schema return data, but there is no declared output structure visible in the source. LLMs cannot plan downstream operations or extract fields without knowing the response shape.
Parameter-level descriptions are minimal or missing. Most input parameters (e.g. 'brief_json', 'packet_json', 'name', 'lens_type', 'lens_id', 'category', 'output', 'quotes', 'sources', 'evidence', 'memo', 'fields') lack substantive descriptions explaining what values are expected, format constraints, or valid ranges. This forces LLMs to infer intent from the parameter name alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2025-06-18+ | v2 |
Return a specific lens.
Return the requested protocol markdown.
Return a packaged JSON Schema so an agent can construct a valid payload. ``name`` accepts the manifest schema key (e.g. ``agenda_brief``), the file name (``agenda-brief.schema.json``), or the bare stem (``agenda-brief``). Call with no ``name`` to list the available schema keys. The schema registry is read from ``agent-manifest.json`` (ADR 0013: the manifest is the authoritative schema registry), so the set never drifts from the packaged ``schemas/v1/`` files. Contract discovery only: it does not validate data, fill in a template, or verify factual truth.
List available lenses.
List available source categories.
Heuristic before/after marker rubric for output scoring.
Return source coverage indicators for a category.
Return source requirements for a category.
Validate an agenda-brief dict against agenda-brief.schema.json.
Validate an evidence-pack dict against evidence-pack.schema.json.
Check that cited quote fragments appear in caller-supplied source texts. Local-text only; does not make outbound network requests.
No tool annotations present. All 16 tools are genuinely read-only (no state mutations), but none declare this via readOnlyHint. This prevents clients from optimizing for safe, idempotent calls and forces conservatism in caching and retry logic.
Error handling and recovery guidance are absent. Tools validate JSON against schemas but provide no guidance on what to do if validation fails, no categorization of errors (retryable vs. user-fixable), and no suggestions for recovery. For example, validate_brief could suggest 'If validation fails, call get_schema("agenda-brief") to see the required structure.'
list_source_categories has no description. Per the hard-scoring rule, any tool without a description scores 0 on that dimension. This tool's description is missing entirely.
Composition clarity is weak. Tools like get_schema and list_lenses are discovery tools meant to help construct payloads for validate_* tools, but the descriptions do not explain the dependency chain. A better description for get_schema might be: 'Use this to discover required fields before calling create_brief or validate_brief. Returns a JSON Schema that describes the structure needed.' Similarly, list_lenses should explain 'Call this first to see available lens types, then pass a lens_id to get_lens().'