A
licenseB
qualityD
maintenanceProvides Claude with 44 tools for confidence gating, typed outputs, hallucination detection, and constraint enforcement during conversations.
51
1
MIT
jev-mcp
by rashedInt32
The server exposes TypeSafe Jev as typed judgment tools that return answers plus calibrated probabilities, confidence, and gating actions.
jev_classify – Pick exactly one option from a fixed set you define; returns the choice, per-option probabilities, confidence, and an
act/review/abstainaction.jev_score – Rate the state on an ordered scale you define; returns a probability-weighted score, level distribution, confidence, and action.
jev_check – Answer a yes/no question with the probability of yes and a
yes/no/uncertainverdict.jev_ask – Ask many independent classification, scoring, and check questions about the same state in one batched call, with answers keyed by your IDs.
jev_models – Verify the API key works and list available model ids.
Every tool returns structured MCP content, including the full probability distribution, model/usage info, and latency; failures come back as classified errors with retryability hints.
The server reads the API key from environment or config file, never from tool arguments, and keeps all non-JSON-RPC output on stderr.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@jev-mcpScore how likely this lead is to buy on a scale of 1-5: 'Requested a demo twice.'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
jev-mcp
An MCP server that exposes TypeSafe Jev as typed judgment tools.
Jev is a System One model. It returns a typed answer and a calibrated probability distribution, never prose. These tools surface that faithfully rather than hiding it behind a label.
Install
Requires Node 20.12+ and a TypeSafe API key from console.typesafe.ai.
Claude Code plugin
One marketplace add, one install. This registers the server and the agent skill together, so there is no separate skill step.
/plugin marketplace add rashedInt32/jev-mcp
/plugin install jev@jev-mcpThe plugin runs the published package through npx -y jev-mcp@<version>, so nothing
needs building. The first launch downloads the package, so allow a few seconds before
the server shows as connected in claude mcp list.
Any MCP client
claude mcp add --scope user jev -- npx -y jev-mcpOr in a client's JSON config:
{
"mcpServers": {
"jev": { "command": "npx", "args": ["-y", "jev-mcp"] }
}
}Do not register the server directly and install the plugin. Two servers named
jev will otherwise both register.
The key
The server reads the key from TYPESAFE_API_KEY in its environment, then from
JEV_API_KEY, then from ~/.config/typesafe/key. It is never a tool argument, so it
cannot land in a transcript or in a model's context.
The key file is the most reliable source, because some MCP clients strip the environment before spawning servers:
mkdir -p ~/.config/typesafe
printf '%s' "ts_..." > ~/.config/typesafe/key
chmod 600 ~/.config/typesafe/keyIf you prefer the variable, put it in ~/.zshenv rather than in any repo, and make
sure it is exported. Without export the variable exists only in the shell that
read it, and every server Claude Code spawns fails with a missing-key error.
Plugin internals
The server is declared inline under mcpServers in .claude-plugin/plugin.json.
There is no .mcp.json anywhere in the repo, and that is deliberate.
A .mcp.json at the plugin root is auto-discovered by the plugin loader, so it works.
But any session opened in this directory also reads that same file as a project
config, where ${CLAUDE_PLUGIN_ROOT} is undefined. The result is a missing-variable
warning and a scope conflict on the same server name. The inline form has exactly one
loader and produces neither. Verify with claude mcp list: the server appears as
plugin:jev:jev and the diagnostics section stays empty.
One trap. claude plugin details jev reports MCP servers (0) for an inline
declaration even while the server is connected and working. That is a gap in the
inventory count, not a failure. Trust claude mcp list over plugin details here.
The plugin deliberately ships no env block. Naming the key there would expand to
an empty string when the variable is unset, and an empty string is not nullish, so it
would shadow the ~/.config/typesafe/key fallback and turn a working setup into a
missing-key error. Leaving env out keeps all three key sources live.
Related MCP server: jev-mcp
Tools
Tool | Primitive | Use when |
| Choice | The answer is one of a fixed set you define |
| Score | The answer is a degree on an ordered scale |
| Noul | The answer is yes or no, and you want the probability |
| all three | You have several questions about the same state |
| — | Confirm the key works and find a model id |
Every tool returns the full probability distribution alongside the answer, plus
confidence for Choice and Score. Results come back as MCP structured content, so a
client gets typed data rather than a JSON string to re-parse.
Prefer jev_ask
Jev prefills the state once and scores every question in a single forward pass, so extra questions add almost no latency or cost. TypeSafe's own measurement on a document-dominated workload puts one batched call at 12.2x cheaper and 10.0x faster than one call per question, with no change in the answers.
Questions in one request cannot see each other's answers. State any speculative premise explicitly and let your own code decide which answers apply.
Design rules
The caller owns the option set.
jev_classifyrequires options from you, so the model can pick the wrong one but can never invent one. A selector cannot choose a candidate the enumerator dropped. This is the single most common way these integrations fail.Probabilities are always returned. Not just the winner.
The key lives in the environment. Never in an argument.
Nothing is silently dropped, overwritten, or truncated. A request that cannot be honoured exactly fails with a reason instead of quietly changing meaning.
Only JSON-RPC reaches stdout. Logs go to stderr, always.
Every answer is checked against the question sent. A choice that was never offered, a distribution over the wrong options, a legend that does not match the levels, or a missing answer in a batch is an error of kind
malformed_response, never a result. A caller that trusted the label alone would otherwise execute something it never proposed.
The no-match option
Each selecting tool adds a none option by default so the model can decline rather
than being forced to pick. Turn it off with add_none: false when one option must
always apply.
If you already use the name none for an option of your own, the added option takes
a different key instead of overwriting yours, and the response reports which key
carries the no-match meaning in none_option. Your option and its probability always
survive intact.
Confidence gating
Choice and Score answers include an action of act, review, or abstain, derived
from confidence and the thresholds you pass in act_above and review_above
(defaults 0.8 and 0.5). jev_check returns a verdict of yes, no, or uncertain
from yes_at_or_above and no_at_or_below (defaults 0.7 and 0.3).
These defaults are starting points, not universal rules. Calibrate them on your own data and on what it costs to be wrong; a destructive action deserves a higher bar than a read-only one. Confidence describes how concentrated the distribution is. It is not a claim that the answer is correct.
A Noul near 0.5 means yes and no are close to equally likely, not that the answer is
"medium", which is why the middle band reports uncertain rather than rounding.
Errors
Failures come back with isError and a classified body: kind, retryable, and
where available status, requestId, and a hint. A rejected key (authentication,
never retryable) is distinguishable from a rate limit (rate_limit, retryable) and
from a malformed question (invalid_request) and from an answer that fails validation
against the question (malformed_response, retryable, nothing to act on). The SDK
already retries 408, 429, and 5xx with backoff before an error surfaces here.
Every judgment result also carries latency_ms for the API round trip, so calibration
notes can record cost alongside confidence.
Limits
A Choice question accepts at most 255 options, which is an API limit; past that, search in two passes, one question picking a window and a second ranking within it. Question count and state size are local caps that bound cost on a single call, and both are configurable. Oversized state is rejected rather than truncated, because truncating silently changes the material the judgment rests on.
Agent skill
skills/jev/SKILL.md teaches an agent when to reach for these tools and how to shape
the call. It is a bridge, not a tutorial. Primitive semantics, state design, and
composition patterns live in TypeSafe's own typesafe-ai skill and in the docs, so
this one deliberately does not repeat them.
Its first section is a three-way test: answer it yourself, call a tool, or write SDK code. That test follows the same line as When not to reach for this below, so an agent loading the skill does not end up arguing with this README.
Point your client at the directory, or copy the file to ~/.claude/skills/jev/.
Configuration
Variable | Effect |
| Required. |
| Model id. Defaults to |
| Per-attempt timeout. Defaults to 15000. |
| Questions per |
| Largest state accepted. Defaults to 200000. |
| SDK verbosity. Safe at any level; all output goes to stderr. |
An unusable value for any numeric setting falls back to the default and warns on
stderr, rather than becoming NaN and disabling the limit it was meant to enforce.
Troubleshooting
Every call reports a missing key. Some MCP clients filter the environment before
spawning servers, which drops TYPESAFE_API_KEY. Confirm the variable is exported,
then pass it explicitly in the client's server config if it still does not arrive.
Run jev_models to check the key in isolation.
The server connects and then dies. On a stdio transport, anything written to
stdout that is not JSON-RPC breaks the connection. This server routes all logging to
stderr, so TYPESAFE_LOG_LEVEL=debug is safe to turn on while debugging.
When not to reach for this
Jev earns its place on a decision that repeats thousands of times inside software, where code can enumerate the options first and you need a number to threshold on.
For a one-off judgment during a conversation, an ordinary model answer is usually better, because it comes with reasoning you can argue with. Jev gives you a number and a label. That is a feature at scale and a limitation in dialogue.
If deterministic code already decides the case correctly, keep the deterministic code. Typed output guarantees the interface, not the truth. Measure before adopting.
Do not ask Jev to compute. It is a one-pass chooser with no scratchpad, so counting,
arithmetic, date comparison, and threshold cutoffs are unreliable, and the answer still
comes back with a confident probability. Do that work in code and pass the result in as
a fact. Add a reference date to state for any question about "today". See TypeSafe's
numeric and date limitations.
Development
npm ci
npm run build
npm run typecheck
npm test # offline: unit tests plus regression tests against a local stand-in
npm run test:e2e # live, requires TYPESAFE_API_KEYInside this repo the plugin's server fails to connect. npx jev-mcp@<version> sees a
local project already named jev-mcp at that version, skips the registry, and looks
for a bin that is never linked into the project's own node_modules. Every other
directory is fine. For work in this checkout, register the local build directly and
skip the plugin, since the plugin always launches the published version:
claude mcp add --scope user jev -- node /absolute/path/to/jev-mcp/dist/index.jsReleasing: bump version in package.json, .claude-plugin/plugin.json, and
.claude-plugin/marketplace.json together, then npm publish. The plugin cache is
keyed by version, so an unbumped plugin keeps serving the old snapshot.
The offline suite runs the real built server over stdio against a local stand-in for the TypeSafe API and asserts on the request bodies it actually sends, so a regression in what reaches the model fails the build.
License
MIT
Available Tools
5 toolsjev_askAsk many questions about one stateA
Ask several independent questions about the same state in ONE request. Jev prefills the state once and scores every question in a single forward pass, so extra questions add almost no latency. Prefer this over repeated single-question calls: on a document-dominated workload it is dramatically cheaper and faster with no change in answers. Questions cannot see each other's answers, so state any speculative premise explicitly and let your own logic decide which answers apply.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | The content to evaluate. A plain string for text, or an object/array for structured data such as a record, a diff, or a chat log. | |
| act_above | No | Confidence at or above which the answer is marked 'act'. Default 0.8. Calibrate on your own data and the cost of being wrong. | |
| questions | Yes | ||
| review_above | No | Confidence at or above which the answer is marked 'review' rather than 'abstain'. Default 0.5. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| usage | Yes | |
| answers | Yes | Keyed by your question ids. Choice and Score answers also carry an 'action' gated on confidence. |
| none_options | Yes | For each 'classify' question, the key carrying the no-match meaning, or null. |
TDQS
A3.8/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It does not disclose the exact behavior of the scoring mechanism, how confidence thresholds work (act_above/review_above) beyond the schema, or the output format (which is not in the schema). The description mentions batching but leaves critical operational details (e.g., how to interpret results, whether 'abstain' is possible) implicit.
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?
The description is concise, with a clear lead sentence stating the primary benefit, followed by a specific usage recommendation and a caveat about question independence. Each sentence earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple question types, confidence thresholds, no annotations) and the presence of an output schema (which is not provided), the description is insufficient. It does not explain the return format, how confidence levels map to answers, or how to handle 'abstain' vs 'act' vs 'review'. The description covers batching but misses critical behavioral details for correct usage.
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 75%, and the description adds significant context: it notes that extra questions add little latency, which implies questions is a list. However, it does not elaborate on the 'state' parameter's flexibility or the confidence thresholds' calibration. Since the schema already describes each parameter well, the description's marginal value is limited but not absent.
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 clearly states the tool's purpose: asking several independent questions about the same state in a single request. It distinguishes itself from siblings by emphasizing batching multiple questions, which is unique among the sibling tools (jev_classify, jev_score, jev_check handle single questions). The verb 'ask' and resource 'state' are specific.
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 description explicitly says to prefer this over repeated single-question calls, citing cost and speed benefits. It also mentions a key constraint: questions cannot see each other's answers, so speculative premises must be stated explicitly. This provides clear when-to-use guidance and warns about a behavioral limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jev_checkYes/no with a probabilityA
Ask a yes/no question. Returns the probability that the answer is yes, from 0 to 1, plus a verdict. There is no separate confidence: a value near 0.5 means yes and no are close to equally likely, not that the answer is 'medium'. Use one check per label when several labels may apply at once.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | The content to evaluate. A plain string for text, or an object/array for structured data such as a record, a diff, or a chat log. | |
| no_means | No | What a no means. | |
| question | Yes | The judgment to make. A string, or an object/array when the question has several labelled parts. This is the only instruction Jev sees, so state it in full. | |
| yes_means | No | What a yes means. Sharpens the judgment. | |
| no_at_or_below | No | Probability at or below which the verdict is 'no'. Default 0.3. Between the two the verdict is 'uncertain'. | |
| yes_at_or_above | No | Probability at or above which the verdict is 'yes'. Default 0.7. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| usage | Yes | |
| verdict | Yes | |
| thresholds | Yes | |
| probability_yes | Yes |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does explain the meaning of probability near 0.5 ('not medium') and that there is no separate confidence, which is helpful. However, it doesn't mention side effects (likely none) or any operational constraints like rate limits. The description covers the output interpretation but lacks broader behavioral context.
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?
The description is three sentences, front-loaded with the core purpose, and every sentence adds value. It efficiently conveys the output, the probability interpretation nuance, and a usage tip. No wasted words or redundancy.
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?
Given the tool's moderate complexity (6 params) and the presence of a full output schema and complete parameter descriptions, the description covers the essential behavioral nuances (probability interpretation, multi-label usage). It doesn't discuss thresholds (no_at_or_below/yes_at_or_above) but those are in the schema. The absence of annotations is partially compensated by the description's clarity on output meaning. Overall adequate.
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 description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific information beyond what the schema already provides. The note about 'the only instruction Jev sees' appears in the schema for 'question', not in the description. Thus, the description adds no extra parameter semantics.
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 tool's purpose: ask a yes/no question and get a probability plus verdict. It uses a specific verb ('ask') and resource ('yes/no question'), and clarifies the output format. However, it does not explicitly differentiate from siblings like jev_classify or jev_ask, though the yes/no framing implies a binary judgment.
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 some usage context: 'Use one check per label when several labels may apply at once.' This advises on handling multi-label scenarios but does not explicitly state when to choose this tool over alternatives or when not to use it. There's no mention of exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jev_classifyClassify into one of your optionsA
Pick exactly one option from a set you define. Returns the chosen option, the probability of every option, a confidence value, and a recommended action gated on confidence. Use when the answer is one of a fixed set. The options must be supplied by you: Jev selects among them and cannot invent a new one. Up to 255 options.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | The content to evaluate. A plain string for text, or an object/array for structured data such as a record, a diff, or a chat log. | |
| options | Yes | Map of option name to a description that separates it from the others. Both the name and the description are sent to the model, so keep names short and distinct. A description may be an object or array when structure clarifies it, or null to leave it undescribed. | |
| add_none | No | Add a no-match option meaning none of yours fits. Defaults to true. Turn off only when one option must always apply. If you already use the name 'none', the added option takes a different key and it is reported back as none_option. | |
| question | Yes | The judgment to make. A string, or an object/array when the question has several labelled parts. This is the only instruction Jev sees, so state it in full. | |
| act_above | No | Confidence at or above which the answer is marked 'act'. Default 0.8. Calibrate on your own data and the cost of being wrong. | |
| review_above | No | Confidence at or above which the answer is marked 'review' rather than 'abstain'. Default 0.5. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| usage | Yes | |
| action | Yes | |
| choice | Yes | |
| confidence | Yes | |
| thresholds | Yes | |
| none_option | Yes | The key carrying the no-match meaning, or null when none was added. |
| probabilities | Yes |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses the return values (chosen option, probabilities, confidence, recommended action) and the constraint that Jev cannot invent new options. However, it does not explicitly state that the tool is read-only or has no side effects, though that is implied for a classification tool. It also lacks details on error behavior or edge cases, but the core behavioral traits are covered.
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?
The description is compact and front-loaded: it opens with the core action, then lists returns, then gives usage context, then a key constraint, then a limit. Every sentence adds value with no redundancy or filler.
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?
Given the output schema exists, the description doesn't need to detail return formats, but it does anyway. It covers the essential usage guidance, constraints, and limits. The only missing piece is a note on what happens with add_none behavior, but that is in the schema. Overall it is sufficiently complete for an agent to invoke correctly.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds a useful constraint ('Up to 255 options') not present in the schema, and mentions the confidence-gated action, which maps to act_above and review_above. However, it does not describe individual parameters, relying on the schema. Baseline 3 is appropriate, with a slight bonus for the 255-option limit.
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 states a specific verb ('Pick') and resource ('one option from a set you define'), and clearly distinguishes the tool from siblings like jev_score or jev_check by focusing on classification among a fixed set. The return values are also mentioned, making the purpose unambiguous.
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?
It explicitly states when to use: 'Use when the answer is one of a fixed set.' It also clarifies a key usage requirement: the options must be supplied by the user, and Jev cannot invent new ones. It doesn't explicitly mention when not to use or name alternatives, but the context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jev_modelsList available modelsA
List the models this API key can use, with their release dates. Use it to confirm the key works and to find a model id for JEV_MODEL before assuming one exists.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| models | Yes | |
| active_model | Yes | The model these tools send requests to. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool lists models and can be used to verify the API key works, implying an authentication check. It does not mention any side effects or destructive behavior, but for a simple list operation this is sufficient. The description adds value beyond the bare 'List available models' title by noting the key-verification aspect.
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?
Two sentences with no redundancy. The main action is front-loaded, and the second sentence explains practical usage. Every word earns its place.
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 has no parameters, an output schema exists (per context), and the description explains both what it does and when to use it, nothing essential is missing. An agent can call this tool correctly without additional information.
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?
The tool has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameters, and the empty input schema with 100% coverage means there is nothing to compensate for.
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 clearly states the verb 'List' and the resource 'models this API key can use', and mentions release dates. It distinguishes itself from sibling tools (jev_classify, jev_ask, jev_score, jev_check) which are all operations, not listing tools. An agent can immediately understand the tool's function and scope.
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?
The description explicitly states when to use the tool: to confirm the key works and to find a model ID before assuming one exists. This gives clear usage context, though it doesn't explicitly mention when not to use it or name alternatives. However, the purpose is clear enough that an agent knows this is a preliminary step before other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jev_scoreRate on an ordered scaleA
Rate the state along an ordered scale you define. Returns a probability-weighted score that can land between levels, the distribution, confidence, and a recommended action. Use for degree or severity, not for picking a category.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | The content to evaluate. A plain string for text, or an object/array for structured data such as a record, a diff, or a chat log. | |
| levels | Yes | Ordered level descriptions, lowest first. At least two. Each level must describe a concrete situation and stand on its own. | |
| question | Yes | The judgment to make. A string, or an object/array when the question has several labelled parts. This is the only instruction Jev sees, so state it in full. | |
| act_above | No | Confidence at or above which the answer is marked 'act'. Default 0.8. Calibrate on your own data and the cost of being wrong. | |
| review_above | No | Confidence at or above which the answer is marked 'review' rather than 'abstain'. Default 0.5. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| score | Yes | |
| usage | Yes | |
| action | Yes | |
| legend | Yes | |
| confidence | Yes | |
| thresholds | Yes | |
| probabilities | Yes |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the tool returns a probability-weighted score, distribution, confidence, and a recommended action, which is valuable. However, it doesn't explain how the confidence thresholds (act_above, review_above) affect the recommended action or any edge cases. The description adds some behavioral context but not comprehensive detail.
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?
The description is three concise sentences with zero filler. The core purpose is front-loaded in the first sentence, followed by the return summary and usage guidance. Every sentence contributes value, and it's appropriately brief.
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?
The tool has a moderate complexity with 5 parameters and an output schema. The description covers the purpose, return behavior, and usage constraints. The output schema provides return structure, so the description doesn't need to repeat that. It's complete enough for an agent to understand when and how to use the tool, though it could benefit from a note on how to frame levels or question, but those are covered in the schema.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter-specific meaning beyond the schema. It mentions 'ordered scale you define' which loosely relates to levels, but doesn't elaborate on state, question, or threshold parameters. Given high coverage, a baseline of 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 tool rates a state along an ordered scale defined by the user, which is a specific verb and resource. It also differentiates from sibling tools by explicitly stating 'not for picking a category', which suggests a contrast with jev_classify. However, it doesn't name the sibling explicitly, so it's clear but not maximally distinct.
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?
The description provides explicit usage guidance: 'Use for degree or severity, not for picking a category.' This tells the agent when to use the tool and what not to use it for. It also implies the user must define the scale, which is useful. It doesn't mention alternatives by name, but the exclusion is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
v0.3.0- First observed
jev_ask - First observed
jev_check - First observed
jev_classify - First observed
jev_models - First observed
jev_score
TDQS
A4.1/5.0
Scored across 5 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: listing models, picking one from a set, scoring on a scale, yes/no checking, and batching multiple independent questions. The descriptions clarify boundaries (e.g., jev_check is specifically for yes/no, while jev_classify handles arbitrary options). No overlap that would cause an agent to misselect.
Naming Consistency4/5
All tools share the consistent 'jev_' prefix, but the second part is mostly verbs (classify, ask, score, check) except for 'models' which is a noun. This is a minor deviation from a strict verb pattern, but still predictable and readable.
Tool Count5/5
Five tools is well-scoped for a classification/scoring API. Each tool earns its place and covers distinct operations without redundancy. This is within the ideal 3-15 range and appropriate for the server's purpose.
Completeness5/5
The surface covers the core operations: model discovery, single-label classification, ordered scoring, binary checks, and batched multi-question inference. There are no obvious gaps for the apparent domain; agents can perform all necessary workflows without workarounds.
Related MCP Connectors
Calibrated world model for AI agents. 40 tools: world state, markets, trading. Kalshi + Polymarket.
Calibrated probabilistic foresight for AI agents, powered by live prediction-market signal.
Sentiment, toxicity, entity extraction, PII, translation, summary, QA, fraud scoring, safety audit.
Live trading-pipeline intelligence for AI agents: signal scoring, calibration, recorded outcomes.
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables agents to perform typed judgments—classify, score, check, match, and screen—over closed answer sets with confidence scores, without text generation.74MIT
- AlicenseAqualityBmaintenanceEnables agents to verify claims against cited evidence, screen content for prompt injection and relevance before reading it, and rank candidates by meaning, all with calibrated probability verdicts.345MIT
- AlicenseAqualityCmaintenanceEnables coding agents to make cheap, fast probabilistic decisions on every turn, with tools for coding-loop checks, review, verification, screening untrusted input, and ranking candidates.6MIT