Skip to main content
Glama
thedv91
by thedv91

Judge (Choice / Noul / Score)

judge
Read-only

Get calibrated, structured decisions at a decision point by passing state and questions; receive typed answers with probabilities and confidence, not prose.

Instructions

Get fast, calibrated judgments from the Jev model at a decision point, instead of guessing in free text. Returns typed answers with probabilities. It never returns prose or reasoning, and it does not decide for you.

WHEN TO USE: you are about to pick between known options (which tool, route, plan, or file; allow/confirm/deny a risky action), check whether a condition holds (is the task complete, is there enough information to stop, does this need user confirmation), or grade something on a dimension you can describe (risk, relevance, severity). Do not use it for open-ended reasoning, arithmetic, exact lookups, or anything plain code or a tool can settle.

QUESTION TYPES:

  • choice: exactly one of a set of options you define.

  • noul: whether a condition holds. Use one noul per label when several labels may apply.

  • score: a position on ordered levels you describe.

HOW TO READ THE RESULT:

  • choice: "choice" is the top option, "probabilities" covers every option, "confidence" (0-1) says how concentrated that distribution is. Low confidence means no option clearly wins, which can also happen when two options are both acceptable.

  • noul: "noul" is the probability that the answer is yes. Near 1 is a strong yes, near 0 a strong no. Near 0.5 means the model cannot tell. It does NOT mean "medium" or "partly". If you want a degree, ask a score question.

  • score: "score" is the probability-weighted mean level, from 0 to "max_level", and can land between levels. Different distributions give the same score, so read "probabilities" and "confidence" with it.

  • "certainty" (high/medium/low) and the noul "verdict" (yes/no/uncertain) apply the thresholds to those numbers. "needs_escalation" lists every question id whose answer is low certainty or uncertain.

WHEN AN ANSWER IS FLAGGED: do not act on it as if it were settled. Escalate in whatever way fits your situation: gather the missing evidence and ask again, reason the point through yourself, or ask the user. Medium certainty means proceed with caution, and verify first if the action is hard to undo. High confidence describes the model's answer, not a guarantee of truth or permission to act.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateYesThe facts the judgment is about. Prefer an object with named fields (e.g. { user_request, plan_a, plan_b, test_output }) over one blob of text. Pass only what bears on the decision, and pass actual content (the log, the diff), not your summary of it: the model sees nothing else and knows nothing about your conversation.
questionsYesMap of question id -> question. Put every independent question about this state in the same call, including ones you may not need: they run in parallel and cannot see each other's answers.
thresholdsNoOverride the uncertainty thresholds for this call. Tighten them (e.g. confidence_high 0.9, noul_band [0.1, 0.9]) when acting on a wrong answer would be costly or irreversible.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYes
usageYes
answersYes
needs_escalationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds substantial behavioral context beyond that: it never returns prose or reasoning, it does not decide for you, it returns probabilities and confidence, low confidence can mean two options are both acceptable, noul near 0.5 means 'cannot tell' not 'medium', and flagged answers must not be acted on as settled. This is rich, non-obvious behavior that an agent must know before invoking. It loses one point only because it does not explicitly discuss rate limits or latency, which are minor for a read-only judgment tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every section earns its place: purpose, when-to-use, question types, result interpretation, and escalation behavior. It is front-loaded with the core purpose and the 'never returns prose' constraint. It loses one point because the result-reading section is dense and could be tightened; some sentences (e.g., the escalation paragraph) repeat the 'do not act on flagged answers' idea in slightly different forms. Still, for a tool with three question types and a rich output, this length is justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 question types, nested question objects, thresholds, rich output schema), the description is remarkably complete. It explains the three question types, how to interpret each result field, what the certainty/verdict/escalation fields mean, and how to handle flagged answers. The output schema exists, so return values need not be re-explained. The only minor gap is no explicit mention of rate limits or cost, but those are not essential for correct invocation. For a tool this complex, this is a model definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds real value beyond the schema: it explains how to read the result fields (choice/probabilities/confidence, noul, score, certainty, verdict, needs_escalation), which is not in the input schema. It also gives guidance on state ('pass actual content, not your summary') and questions ('put every independent question in the same call'). However, the description does not add much about the thresholds parameter beyond what the schema already says, and the question-type semantics are mostly carried by the schema's detailed per-type descriptions. So it is a solid 4, not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Get fast, calibrated judgments from the Jev model at a decision point') and immediately contrasts with free-text guessing. It names the three question types (choice, noul, score) and explicitly says what it never returns (prose/reasoning) and what it does not do (decide for you). This clearly distinguishes it from siblings like review_files or verify_claim, which are about reviewing or verifying rather than producing calibrated probabilistic judgments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO USE' section is explicit and actionable: it lists concrete decision scenarios (pick between known options, check a condition, grade on a dimension) and gives a 'Do not use' list (open-ended reasoning, arithmetic, exact lookups, plain code/tool-settable things). This is exactly the when/when-not guidance an agent needs to route correctly among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.