jev-mcp
Related Servers
Alternatives to jev-mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to submit a state and typed questions and receive structured judgments such as yes/no probabilities, named choices, and rubric scores, with no text generation or parsing.MIT
- AlicenseAqualityCmaintenanceProvides agents with fast, typed, calibrated decision tools for classification, scoring, yes/no checks, and gating risky tool calls.5320 npm3MIT
- AlicenseNot gradedqualityAmaintenanceProvides coding agents with typed classification, yes/no checks, scoring, ranking, and question-answering tools that return calibrated probabilities for fast, reliable decisions.055MIT
- AlicenseNot gradedqualityAmaintenanceEnables coding agents to send natural language and JSON application state to a judge tool that returns typed judgments (yes/no probability, choice, or score) with model and usage metadata, and fails gracefully without blocking workflows.12 npm5Apache 2.0
- AlicenseNot gradedqualityAmaintenanceEnables typed decisions (yes/no, choice, score) with transparent preflight checks, honest confidence reporting, and health monitoring.65 npmApache 2.0
- AlicenseAqualityCmaintenanceEnables agents to call typed code-review and content-moderation decision tools, returning structured verdicts, probabilities, and confidence-gated actions.2MIT
TDQS
Scored across 3 tools
The three tools split cleanly along orthogonal axes: jev_ask (one state, many questions), jev_batch (many items, one question set), and jev_status (health/housekeeping, no judgments). Descriptions explicitly include 'Not for' clauses that steer agents away from the wrong tool (e.g., 'For many items use jev_batch', 'Not for several questions about one state').
All names follow a single predictable pattern: the shared `jev_` prefix plus a short snake_case noun (ask, batch, status). No mixed conventions or verb-style drift.
Three tools is on the lean side, but each occupies a distinct role (single judgment, batched judgment, meta/ops) and nothing feels redundant. A slightly larger surface (e.g., a recipe-listing tool) might round it out, but the current set is well-scoped.
The surface covers the full judgment lifecycle: single calls, concurrent batch calls, offline validation, threshold presets, feedback labeling, and calibration. Minor gaps exist — no dedicated tool to list or inspect past decisions/history, and recipe discovery is only implied through the `recipe` arg rather than being a first-class operation.