Skip to main content
Glama
rilfi

token-optimizer-jev-mcp

by rilfi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Score against an ordered rubric

jev_score
Read-onlyIdempotent

Rate a state against an ordered rubric to get an expected score, confidence, and per-level probabilities. Split complex judgments into per-factor scores and combine them in your own code.

Instructions

Ask Jev to rate a state against an ordered rubric. Returns the expected score (which may fall between levels), its confidence, and — when asked — the probability of each level. Split a judgment that depends on several factors into one score per factor and combine them in your own code. 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.
levelsYesThe rubric, lowest level first, indexed from 0. Descriptions may be strings or null. At least 2 levels.
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.8/5.0
Behavior4/5

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

Annotations already provide readOnly/idempotent/destructive safety hints; the description reinforces this with an explicit 'Read-only: the request has no side effects.' It adds useful behavioral context beyond the annotations, such as the expected score possibly falling between levels and probabilities being returned only when requested. No contradiction with annotations.

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 deliver purpose, return behavior, and usage guidance without filler. The main action is front-loaded, and every sentence earns its place, including the concise decomposition tip and read-only note.

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

Completeness4/5

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

Despite the absence of an output schema, the description names the central return fields (score, confidence, probabilities) and the side-effect guarantee, which covers the most essential invocation context. Parameter-level details are handled by the schema's thorough descriptions. Minor omissions like error behavior or default model behavior are not critical for a correct call.

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?

All 10 parameters have descriptions in the schema (100% coverage), so the schema already carries most semantic weight. The description adds high-level context (e.g., ordered rubric, optional probabilities) but does not clarify per-parameter details beyond the schema, so the baseline 3 is appropriate.

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?

The description clearly states the action ('rate a state') and the resource ('an ordered rubric'), and it names the key outputs (expected score, confidence, probabilities). It does not explicitly differentiate from sibling tools like jev_choice or jev_noul, so the agent must infer distinctions from naming and schema rather than from the description.

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

Usage Guidelines3/5

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

The description gives a clear context for use (scoring against an ordered rubric) and offers an implementation guideline: split factor-dependent judgments into separate scores and combine them in code. However, it does not state when to use this tool instead of siblings, nor any exclusion conditions, so the guidance is implied rather than explicit.

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

Deploy Server

Other Tools