openjev-mcp

Jev batch (many items)

jev_batch

Read-onlyIdempotent

Ask the same independent questions across many tickets, comments, or records and get typed answers, counts, and per-item errors.

Instructions

Put the same independent questions to each of many items — a queue of tickets, a page of comments, rows of records — and get typed answers per item.

How it runs: each item is its own request to Jev, carrying its state and every question, so an item costs what a jev_ask call with those questions costs. Requests go out a few at a time and are paced to the key's rate limit. Use jev_ask for a single item.

How to design the call:

items holds 1 to 100 records, each with its own state. Give every item an id — the record's own id, such as a ticket number — so its results map back without counting positions; without ids, items are labelled by position from "0".
questions follows the same rules as in jev_ask, and every item is judged against all of them, independently.

Reading the result: counts gives the totals. answers[item id][question id] holds an answered item's answers, shaped as in jev_ask; confidence says how concentrated a distribution is, not how likely the answer is to be correct. errors[item id] holds an item that failed, with its code and whether it is retryable. When the call ends early — a rejected key, a rate limit it cannot wait out, several failures in a row, or its time budget — stopped says why and not_sent lists the items never sent. Send those, and any retryable errors, in a later call, after retry_after_ms when it is given.

Input Schema

Name	Required	Description
`items`	Yes	The records to judge, 1 to 100 per call. Each is sent as its own request, with every question.
`model`	No	Model alias. Omit to use the server default (`openjev`).
`questions`	Yes	Question id to question definition, as in `jev_ask`. Non-empty. Every item is asked every question.

Output Schema

Name	Required	Description
`hints`	No	Non-blocking advice about this request, when there is any.
`model`	No
`usage`	No	Tokens summed over the answered items.
`counts`	Yes	How many items were answered, failed, or never sent.
`errors`	No	Item id to the failure of an item that was sent but not answered.
`answers`	Yes	Item id to that item's answers, keyed by question id as in `jev_ask`.
`stopped`	No	Present when the call ended before sending every item: why, and whether the unsent items can be sent again as they are.
`not_sent`	No	Ids of the items never sent because the call stopped early.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.0Oct 14, 2026

TDQS

A4.9/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 discloses the cost model (each item costs what a jev_ask call with those questions costs), concurrency and rate-limit pacing, partial-failure behavior, and the early-stop conditions (rejected key, un-waitable rate limit, consecutive failures, time budget). That is the operational context an agent needs before a 100-item call.

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 purpose sentence, then clearly headed sections (How it runs / How to design the call / Reading the result). Dense but every sentence carries actionable information about costs, ids, or failure handling.

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?

For a nested, 100-item-max batch tool with an output schema, the description covers cost, concurrency, id mapping, error/retry semantics, and partial completion. Nothing an agent needs to invoke this correctly appears 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 already 100%, so the schema documents items/questions/model in detail. The description still adds cross-cutting semantics the schema can't easily convey: the all-or-nothing id rule, positional labelling from "0" when ids are omitted, and that every item is judged against all questions independently. It largely restates rather than extends schema-level detail, so 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?

States a specific verb+resource with concrete instantiations ('a queue of tickets, a page of comments, rows of records') and explicitly frames the batch-vs-single distinction. It names the sibling jev_ask and says when to prefer it, so an agent can route between them without opening the schema.

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 says to use jev_ask for a single item, prescribes id assignment for result mapping, and gives concrete retry guidance (resend not_sent items and retryable errors after retry_after_ms). When-to-use, when-not-to-use, and recovery are all covered.

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

Deploy Server