openjev-mcp

Ask Jev (several questions)

jev_ask

Read-onlyIdempotent

Send one shared context with multiple independent questions to receive typed judgments—choice, score, or yes/no probabilities—instead of prose answers.

Instructions

Send one shared context and one or more independent questions to Jev (TypeSafe System One) and get typed judgments back — not prose.

How to design the call:

state carries the text and facts; instructions carries the judgment, in the question's own words.
Every question is answered independently against the same state. Order is not a sequence, and no question can use another's answer. Ask independent questions together in one call, including conditional ones whose answers you may ignore; make a second call only when an answer decides what to fetch or ask next.
One call judges one state as a whole. Packing several records into it, such as a list of tickets, yields one blended answer; use jev_batch to get an answer per record.
Prefer choice for a category, score for an ordered scale, and noul for a yes/no judgment. Use separate noul questions when several labels can apply at once, since a choice returns exactly one option.

Reading the result: answers come back under answers keyed by question id. Choice and score carry probabilities and confidence; confidence says how concentrated the distribution is, not how likely the answer is to be correct, so calibrate any threshold on your own labeled examples. Noul carries a single probability — near 1 yes, near 0 no, near 0.5 uncertain — and no confidence field.

Input Schema

Name	Required	Description
`model`	No	Model alias. Omit to use the server default (`openjev`).
`state`	Yes	The content the questions are judged against: text, an object of named fields, or an array of records. The state is judged as one whole, so an array of tickets gets one blended answer rather than one per ticket; to judge records one by one, use `jev_batch`. Reference a nested field from `instructions` with a dotted path in backticks, e.g. `account.plan`. Fetch external records first — a URL here is not a request to browse — and note that this API accepts no image, audio, or file uploads.
`questions`	Yes	Question id to question definition. Non-empty. Ids label the answers for your code.

Output Schema

Name	Required	Description
`hints`	No	Non-blocking advice about this request, when there is any.
`model`	No
`usage`	No
`answers`	Yes	One typed answer per requested question id.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.0Oct 14, 2026

changedInput schema / properties / state / description

Previous value: -"The content the questions are judged against: text, an object of named fields, or an array of records. Reference a nested field from `instructions` with a dotted path in backticks, e.g. `account.plan`. Fetch external records first — a URL here is not a request to browse — and note that this API accepts no image, audio, or file uploads."New value: +"The content the questions are judged against: text, an object of named fields, or an array of records. The state is judged as one whole, so an array of tickets gets one blended answer rather than one per ticket; to judge records one by one, use `jev_batch`. Reference a nested field from `instructions` with a dotted path in backticks, e.g. `account.plan`. Fetch external records first — a URL here is not a request to browse — and note that this API accepts no image, audio, or file uploads."

First observedv0.1.1Sep 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/openWorld annotations: it explains that state is judged as a single whole, that URLs are not browsed, that no image/audio/file uploads are accepted, and that questions are answered independently with no cross-contamination. Most valuably it de-mystifies the `confidence` field ('how concentrated the distribution is, not how likely the answer is to be correct') and the single noul probability's meaning.

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

Conciseness5/5

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

Front-loaded with the core purpose, then organized under 'How to design the call' and 'Reading the result' with dense, non-redundant bullets. Length is justified given the tool's genuine complexity; no sentence is filler.

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?

Covers call design, question-type selection, batching trade-offs, output keying, and confidence interpretation. With an output schema already present, the return-format explanation is bonus rather than necessity, and nothing an agent needs to invoke this correctly is missing.

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 coverage is 100% so the baseline is 3, but the description adds real semantic value on top: it separates the roles of `state` (text and facts) from `instructions` (the judgment, in the question's own words) and explains backtick dotted-path references like `account.plan`. It does not add much beyond the schema for `criteria` limits or `model`.

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

Purpose4/5

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

States a specific verb and resource: send a shared state plus one or more questions to Jev and receive typed judgments rather than prose. It names `jev_batch` as the alternative for per-record judging, but does not differentiate itself from the `jev_choice`/`jev_score`/`jev_noul` siblings, which appear to be the single-question counterparts of the same operation.

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?

Explicitly describes when one call is sufficient versus when a second call is warranted ('make a second call only when an answer decides what to fetch or ask next'), and directs multi-record work to `jev_batch`. It also gives selection guidance among question types (choice for a category, score for an ordered scale, noul for yes/no) and warns to use separate noul questions when multiple labels can apply.

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

Deploy Server