Skip to main content
Glama
hanshs474

jevx-mcp

by hanshs474
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Jevx MCP

Run Jev AI typed decisions from any MCP client — Claude, Cursor, Cline, Codex. Give it a state and the questions you branch on, get back a choice, a score or a yes/no, with a calibrated probability on every option.

Jev AI is a zero-shot decision model from TypeSafe: text or JSON in, typed values out — no dataset, fine-tune or retrain when the label set changes. Jevx is an independent playground and API for Jev AI and is not affiliated with TypeSafe AI.

Tools

Tool

What it does

decide

Send a state and up to 16 typed questions, get back choices, scores and noul values with probabilities

validate_questions

Check a question's shape locally, free and without an API key, before spending credits on a malformed request

open_in_jevx

The URL to try or continue a decision in the browser playground

Related MCP server: jevcore-mcp

Install

npx jevx-mcp

Claude Desktop / Claude Code

{
  "mcpServers": {
    "jevx": {
      "command": "npx",
      "args": ["-y", "jevx-mcp"],
      "env": { "JEVX_API_KEY": "sk-..." }
    }
  }
}

Create a key at jevx.org/settings/apikeys. There is no anonymous decisions endpoint — a key is required, same as running the playground signed out.

Cursor / Cline

Point the client at npx -y jevx-mcp (stdio transport) and set JEVX_API_KEY in its environment.

Question shapes

type

criteria

returns

choice

object of option to meaning, two or more options

choice, probabilities, confidence

score

ordered array, low to high

score, probabilities, confidence

noul

exactly the keys true and false

value between 0 and 1, where exactly 0.5 means the model declined

The API answers HTTP 200 with a non-zero code on a refusal (bad key, malformed request); decide and validate_questions both surface that as a normal tool error, not a silent success.

License

MIT

Available Tools

3 tools
decideRun a Jev AI decisionA

Send a state (text or JSON) and up to 16 typed questions to Jev AI on jevx.org, and get back the choice, score or yes/no for each — with a calibrated probability on every option. Needs JEVX_API_KEY. Branch your own code on the returned probabilities, not just the top label; a noul of exactly 0.5 means the model declined to answer.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoPin a dated model id for reproducible answers; omit to use the floating alias.
stateYesThe thing being judged: plain text, or a JSON object/array.
questionsYesUp to 16 named questions, all judged against the same state.

TDQS

A4/5.0
Behavior4/5

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

No annotations are present, so the description carries the full burden. It discloses the API key requirement and, crucially, the sentinel behavior 'a noul of exactly 0.5 means the model declined to answer,' plus the calibrated-probability output. This is highly useful beyond what the schema shows.

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 dense sentences, each earning its place: the core action, the auth requirement, and the pivotal output-semantics warning. The purpose is front-loaded, and there is zero fluff.

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?

With no output schema, the description explains the return kinds and the 0.5 sentinel, which is sufficient for an agent to consume the result. It does not describe the exact response JSON shape or the model parameter's pinning behavior, but the 100%-covered input schema compensates for those aspects.

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 repeats 'state (text or JSON)' and 'typed questions' but does not add any parameter-specific semantics beyond what the schema already defines. The calibration and 0.5 mention concern output behavior, not parameter meaning.

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 and resource: 'Send a state ... and up to 16 typed questions to Jev AI on jevx.org, and get back the choice, score or yes/no for each.' This clearly distinguishes it from siblings like validate_questions (pre-check) and open_in_jevx (UI launch), making the tool's role unmistakable.

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?

It gives an auth prerequisite ('Needs JEVX_API_KEY') and advice on consuming results ('Branch your own code on the returned probabilities'), but it never explicitly says when to use this tool instead of validate_questions or open_in_jevx. No exclusions or alternative routing are provided.

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

open_in_jevxOpen the Jevx playgroundC

The URL to try or continue a decision in the browser playground.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.7/5.0
Behavior1/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 only states 'The URL to try or continue a decision' without any information about side effects (e.g., opening a new tab, navigation, authentication requirements) or what the tool actually does beyond providing a URL. This is a significant gap for an action-oriented tool.

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

Conciseness3/5

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

The description is a single short sentence, which is concise. However, it is poorly structured: the opening phrase 'The URL to...' is grammatically awkward and doesn't clearly lead with an action verb. The meaning is not immediately transparent, and the sentence could be more effectively front-loaded.

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 there is no output schema and no annotations, the description should fully explain the tool's behavior. It fails to clarify what 'try or continue a decision' means, what the URL is used for, or what the tool returns or does. Even for a simple tool, this is incomplete.

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 input schema has zero parameters, so schema description coverage is trivially 100%. The baseline for 0-parameter tools is 4, and the description adds no parameter-specific information because there are none to describe.

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 names the resource (Jevx playground) and the purpose (try/continue a decision), which distinguishes it from siblings like validate_questions and decide. However, the phrasing 'The URL to...' is a noun phrase rather than a clear verb action; it doesn't explicitly say 'opens' or 'launches', making the exact behavior slightly ambiguous.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus the sibling tools validate_questions or decide. The description doesn't mention any conditions, alternatives, or exclusions, leaving the agent to infer usage from the tool name and title alone.

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

validate_questionsCheck a Jev AI question shapeA

Run the same shape checks the Jev API enforces, without spending credits or needing an API key. Use this first when writing questions by hand — a malformed question otherwise comes back as a deeply nested validation error.

ParametersJSON Schema
NameRequiredDescriptionDefault
questionsYesUp to 16 named questions, all judged against the same state.

TDQS

A3.8/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. It usefully discloses that the tool runs the same checks as the API, does not spend credits, and does not need an API key. However, it does not describe the tool's own return format, whether it is purely read-only, or what an error response looks like, leaving some behavioral ambiguity.

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, zero filler, and the most important facts (same checks, no credits/key, use first) are front-loaded. The second sentence justifies the recommended usage, making every word earn its place.

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?

For a tool with a nested input schema and no output schema, the description sufficiently explains why it exists, when to use it, and what it avoids. It does not detail the return value, but output schemas are absent and the rubric says descriptions needn't explain return values in that case. The main gap is lack of explicit sibling differentiation, which is minor given the tool's clear standalone purpose.

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 input schema already documents the single 'questions' parameter and its nested structure in detail. The description adds no parameter-specific meaning beyond implying the tool validates question shape, so a baseline score 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 states a specific verb ('Run') and resource ('the same shape checks the Jev API enforces'), and clearly identifies the tool's role as a pre-flight validation step. It does not explicitly contrast with siblings 'decide' and 'open_in_jevx', but the purpose is unambiguous and the no-credits/no-key distinction sets it apart.

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 guidance: 'Use this first when writing questions by hand' and explains the consequence of not doing so (deeply nested validation error). It does not mention when to choose siblings instead, but the stated usage context is clear and sufficient for the main workflow.

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.

  1. 3 tool updatesv0.1.0
    • First observeddecide
    • First observedopen_in_jevx
    • First observedvalidate_questions
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinct role: validate_questions is a pre-flight shape check, decide is the core inference call, and open_in_jevx is a browser handoff utility. There is no meaningful overlap or chance of selecting the wrong tool for a given task.

Naming Consistency3/5

All names are lowercase snake_case, but the patterns vary: validate_questions is verb_noun, decide is a bare verb, and open_in_jevx is a verb phrase with a product name. The names are readable and intuitive, yet they do not follow a single predictable convention.

Tool Count5/5

At three tools, the server is tightly scoped to the Jev decision workflow: validate, run, and hand off to the playground. Every tool earns its place and the small count is appropriate for such a narrow API.

Completeness4/5

The core validate-decide-open flow is fully covered with no dead ends for typical usage. Minor gaps exist around decision management or account/credit introspection, but they are not required for the server's stated purpose.

Resources

Related MCP Connectors

Related MCP Servers

  • jev-mcp

    arunav25
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables MCP clients to call TypeSafe's JEV classifier and receive structured, typed judgments with probabilities for binary, choice, and scoring questions.
    MIT

  • jevcore-mcp

    PerryLink
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables MCP hosts to query Jev's typed decision model—yes/no, choice, and score—with calibrated probabilities, while defaulting to an offline mock and disclosing all egress unless explicitly enabled.
    Apache 2.0

  • jev-judge-mcp

    gecm0
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables MCP clients to consult TypeSafe's Jev through a judge tool, answering narrow typed questions with calibrated probabilities instead of prose.
    MIT

  • typesafe-mcp

    MarkChu-git
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables any agent to ask typed questions (Noul, Choice, Score) against Jev's decision model and receive structured answers with probabilities, confidence, and an auditable act/review/abstain decision.
    MIT