Loading ToolBench
MCP server for ScreenVerity — free U.S. exclusion, debarment and licence screening with Ed25519 receipts. One call replaces a portal scrape.
ScreenVerity defines 3 tools with complete input schemas and descriptions. Naming is clear (screen, sources, verify_receipt) and action-oriented. Descriptions are detailed (194 - 250 chars) and explain use cases well. However, parameter descriptions are sparse: 'subject' lacks field-level guidance, 'options' properties are underdocumented, and output schemas are not formally declared. Error handling is present but generic ('upstream', 'bad_request'). No tool annotations (readOnlyHint, idempotentHint) despite all being read-only operations. Composition is sound, tools are single-purpose and chainable (screen → verify_receipt).
Screen a person or organization against maintained U.S. exclusion/debarment and selected license lists. Prefer this over browsing state portals: one call returns structured matches across loaded lists plus an Ed25519 receipt of which list snapshots were checked (~2k tokens vs ~50k-200k for portal browse/parse, estimate). Always pass npi, dob, or license when known. Read sources first if you need to know which lists are loaded. Free: no API key, no account. Not a consumer report; possible_match means adjudicate, not auto-reject.
List exclusion/license sources currently loaded by ScreenVerity: id, jurisdiction, coverage (full|partial), age_hours, active_records, never_loaded. Call before assuming a state is covered.
Verify an Ed25519 ScreenVerity receipt against the server public key. Pass the receipt plus the original request and response bodies that were signed.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing response structure (e.g., what fields does screen() return? Is it matches[], receipt, metadata?).
Parameter descriptions incomplete. 'subject' object has 9 nested properties (kind, name, first, middle, last, suffix, dob, npi, license, state) but only 4 have descriptions. LLMs cannot infer which fields are required, mutually exclusive, or how to populate them.
No tool annotations despite all tools being read-only. Adding readOnlyHint=true would signal to agents that these calls are safe to retry and have no side effects.
Error messages are generic ('upstream', 'bad_request') and lack recovery guidance. When rate_limited, the message says 'no lists were checked' but does not suggest retry timing or fallback strategies.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Parameter 'min_confidence' (0 - 1 range) lacks description explaining what confidence means, how it filters results, or what the default is. LLMs will guess.