Skip to main content
Glama
rilfi

token-optimizer-jev-mcp

by rilfi

Pick one label from a set

jev_choice
Read-onlyIdempotent

Pick exactly one label from a defined set for routing, classification, or screening. Returns the selected label with calibrated confidence and optional per-label probabilities, with no side effects.

Instructions

Ask Jev to pick exactly one label from a defined set. Returns the selected label, the calibrated confidence in it, and — when asked — the probability of every label. Use it for routing, classification, and screening. Read-only: the request has no side effects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rawNoReturn the raw API result (every field, unformatted) instead of the compact answer set.
modelNoModel override, e.g. jev-latest, or a pinned version such as jev-1.13.0.
stateYesThe material to judge: a string, a JSON object, or an array of text values. Jev reads this once and evaluates every question against it in parallel. Non-text inputs (images, audio, binaries) must be converted to text or structured fields first.
optionsYesOption labels mapped to a description of what each label means, or null to leave it undescribed. At least 2 labels.
answer_nameNoKey this answer appears under in the response. Defaults to "answer".
instructionsYesThe question, as a string or structured JSON. Write it as a judgment a knowledgeable person makes in a second, not as a multi-step task.
include_usageNoInclude token usage. Default true.
include_legendNoInclude the score rubric legend echoed by the API. Off by default: you already sent the rubric.
confidence_thresholdNoAnswers below this confidence come back flagged (needs_review for choice/score, uncertain for noul). Default 0.6, or JEV_CONFIDENCE_THRESHOLD.
include_probabilitiesNoInclude the full probability table per answer. Off by default — it is the largest part of a response.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds output behavior details: returns selected label, calibrated confidence, and optionally probabilities. It also reiterates read-only, which is already in annotations, but the output details are new. No contradictions.

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?

Three sentences, each serving a purpose: purpose, return value, and use cases/read-only. Front-loaded with the core action. No fluff.

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

Completeness3/5

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

While the tool has 10 parameters and complex nested structures, the schema descriptions are comprehensive. The description provides a high-level summary but does not explain the full response structure (no output schema) or nuanced behaviors like parallel evaluation of multiple questions (though that is in the state parameter description). Given the tool's complexity, the description is adequate but not exhaustive.

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

Parameters3/5

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

Schema descriptions cover 100% of parameters, so baseline is 3. The description does not add parameter-specific guidance beyond the schema, but it does mention 'when asked' for probabilities, indirectly referencing include_probabilities. No additional semantics needed given full schema coverage.

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: 'Ask Jev to pick exactly one label from a defined set.' Clearly distinguishes from sibling scoring tools by focusing on single-label selection. Mentions use cases (routing, classification, screening) which further clarify intent.

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

Usage Guidelines4/5

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

Provides explicit context for when to use: 'Use it for routing, classification, and screening.' However, does not explicitly state when not to use it or name alternative tools, leaving the agent to infer distinctions from the tool name and context.

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