Loading ToolBench
Exposes the Verel agent framework to any MCP host (Cursor/Claude Code/etc.), providing grading, perception, memory, and tool-building capabilities
Verel MCP server has 11 tools with schemas and descriptions present, but quality is inconsistent. Tool names lack clear verb-noun structure (verel_gate, verel_sight, verel_recall are domain-specific but opaque to LLMs unfamiliar with Verel's architecture). Descriptions are present but often cryptic, referencing internal concepts (§3/§4, SSRF guard, scope lattice, point-in-time query) without explaining what the tool actually does for an agent. Parameter descriptions exist but are sparse (e.g., 'attestation mode' without explaining when to use 'auto' vs 'ed25519'). Output schemas are not documented, LLMs cannot predict what fields to expect. Error handling is absent from visible code. Security-sensitive tools (verel_remember, verel_build_tool) lack permission gates or audit trail documentation.
detect→scaffold→test→register a tool (needs an LLM key)
run the inner-loop CI stage on a repo → verdict + issues
RUN the graders on a repo → attested verdict + a verifiable receipt (§3/§4)
scan untrusted documents for hidden content / prompt injection before an LLM reads them
grade a terraform plan / K8s manifests offline → IaC drift + cloud-IAM risks
set-membership at a past instant — who held a predicate/value THEN (who was admin)
read the shared brain (scope lattice; token_budget=graded-first; as_of=point-in-time)
write to the shared brain — trust does NOT travel (candidate until attested)
Tool names lack clear action verbs. 'verel_gate', 'verel_sight', 'verel_recall' are domain-specific jargon that LLMs cannot parse without extensive context. Should use verb_noun pattern: 'grade_repository', 'render_url', 'query_memory'.
Descriptions reference internal concepts (§3/§4, SSRF guard, scope lattice, point-in-time query, attestation mode) without explaining what the tool does or when to use it. LLMs cannot infer intent from cryptic references. Descriptions should state: WHAT it does, WHEN to call it, WHAT it returns.
Output schemas are not documented in visible code. LLMs cannot predict what fields to expect from tool responses, forcing them to guess or make follow-up calls. Every tool must document its return type and key fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
extract facts from a conversation → only GRADED facts compound (LLM key)
render a URL → attested percept (bboxes + image_ref + receipt) — the eyes
verify a receipt with NO trust in its producer (ed25519 = public; §11)
Parameter descriptions are sparse and lack constraints. 'attestation mode: auto, ed25519, or hmac' is listed but not explained, when should an agent choose each? 'scope' parameter appears in multiple tools but is never defined. Enum values must be documented with guidance on when to use each.
Security-sensitive tools (verel_remember, verel_build_tool marked WRITE/IRREVERSIBLE) lack permission gates, audit trail documentation, or confirmation steps. No evidence of access control, logging, or dry-run support. Destructive tools must support confirmation before execution.