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-mcp Should we approve this loan? Give me a yes/no probability."
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.
MCP server wrapping TypeSafe's Jev System One models. Instead of prompt-and-parse, agents get typed judgments they can use directly in code: yes/no probabilities, multiple-choice selections with distributions, and rubric-based scores.
Tool | What it does | Returns |
| Evaluate |
|
| Yes/no judgment |
|
| Pick one option from |
|
| Rate along 2–10 ordered level descriptions |
|
| List models your key can use |
|
Every tool takes state (string, object, or array — the content to judge),
an optional model (default "jev-latest"), and an optional endpoint
("direct" or "zen", default "direct").
Related MCP server: jev-eval-mcp
Python 3.10+ and uv (or plain pip)
A TypeSafe API key → TYPESAFE_API_KEY
Optional: an OpenCode Zen key → OPENCODE_API_KEY, only if you want endpoint="zen" (models jev-1.13 / jev-1.13-free)
git clone https://github.com/rajasekharponakala/jev-mcp.git
cd jev-mcp
cp .env.example .env # then put your key in .env (never commit it)
uv run --with fastmcp --with httpx server.pyOr with an installed environment:
pip install -e .
export TYPESAFE_API_KEY=...
jev-mcp~/.config/opencode/opencode.json){
"mcp": {
"servers": {
"jev": {
"type": "local",
"command": ["uv", "run", "--with", "fastmcp", "--with", "httpx", "server.py"],
"cwd": "/path/to/jev-mcp",
"environment": {
"TYPESAFE_API_KEY": "{env:TYPESAFE_API_KEY}"
}
}
}
}
}claude mcp add jev -e TYPESAFE_API_KEY=... -- uv run --with fastmcp --with httpx /path/to/jev-mcp/server.py~/.codex/config.toml)codex mcp add jev --env TYPESAFE_API_KEY=... -- uv run --with fastmcp --with httpx /path/to/jev-mcp/server.pyor manually:
[mcp_servers.jev]
command = "uv"
args = ["run", "--with", "fastmcp", "--with", "httpx", "/path/to/jev-mcp/server.py"]
env = { TYPESAFE_API_KEY = "..." }~/.gemini/settings.json){
"mcpServers": {
"jev": {
"command": "uv",
"args": ["run", "--with", "fastmcp", "--with", "httpx", "/path/to/jev-mcp/server.py"],
"env": { "TYPESAFE_API_KEY": "..." }
}
}
}~/.cursor/mcp.json){
"mcpServers": {
"jev": {
"command": "uv",
"args": ["run", "--with", "fastmcp", "--with", "httpx", "/path/to/jev-mcp/server.py"],
"env": { "TYPESAFE_API_KEY": "..." }
}
}
}~/.codeium/windsurf/mcp_config.json){
"mcpServers": {
"jev": {
"command": "uv",
"args": ["run", "--with", "fastmcp", "--with", "httpx", "/path/to/jev-mcp/server.py"],
"env": { "TYPESAFE_API_KEY": "..." }
}
}
}~/.cline/mcp.json, or cline mcp wizard){
"mcpServers": {
"jev": {
"command": "uv",
"args": ["run", "--with", "fastmcp", "--with", "httpx", "/path/to/jev-mcp/server.py"],
"env": { "TYPESAFE_API_KEY": "..." },
"disabled": false
}
}
}~/.config/goose/config.yaml)goose session --with-extension "jev:TYPESAFE_API_KEY=... uv run --with fastmcp --with httpx /path/to/jev-mcp/server.py"or persist in config:
extensions:
jev:
name: Jev
cmd: uv
args: ["run", "--with", "fastmcp", "--with", "httpx", "/path/to/jev-mcp/server.py"]
enabled: true
envs: { "TYPESAFE_API_KEY": "..." }
type: stdio
timeout: 300{
"mcpServers": {
"jev": {
"command": "uv",
"args": ["run", "--with", "fastmcp", "--with", "httpx", "/path/to/jev-mcp/server.py"],
"env": { "TYPESAFE_API_KEY": "..." }
}
}
}(VS Code: same shape in ~/.vscode/mcp.json.)
The server object is named mcp, so FastMCP can install it directly:
fastmcp install claude-code /path/to/jev-mcp/server.pythen add TYPESAFE_API_KEY via that client's config.
// tool call: jev_choice
{
"state": "Help! My payouts have been failing for 3 days.",
"instructions": "Which team should handle this?",
"criteria": {
"billing": "Payments, invoicing, refunds",
"technical": "Bugs, outages, integrations",
"sales": "Pricing, upgrades, new accounts"
}
}
// → {"choice": "billing", "probabilities": {"billing": 0.88, ...}, "confidence": 0.81}See the TypeSafe docs (source of truth) and the API reference for question design: one narrow judgment per question, batch independent questions, keep policy and thresholds in your code.
uv run --with fastmcp --with httpx python -c "
import asyncio, server
print(sorted(t.name for t in asyncio.run(server.mcp.list_tools())))
"AGPL-3.0-only. Copyright (c) 2026 rajasekharponakala.
Pick one option. criteria: {"option": "rubric..."}. Returns choice + probabilities + confidence.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | jev-latest | |
| state | Yes | ||
| criteria | Yes | ||
| endpoint | No | direct | |
| instructions | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the return shape (choice, probabilities, confidence), but it does not disclose how the model arrives at the choice, whether state/instructions influence the decision, or whether there are side effects or endpoint-specific behaviors. This is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the core action and return value. The inline example JSON for criteria is awkward and unclear, but the overall length is appropriate and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, three required ones, nested objects, and no annotations, this description is incomplete. It omits parameter semantics and usage differentiation, although the output schema may cover return structure. The agent would need to infer too much about state, instructions, and criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions 'criteria' with a confusing example and never explains 'state', 'instructions', 'model', or 'endpoint'. Three of the five parameters are required, and the description provides almost no guidance on how to populate them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Pick one option') and the output ('choice + probabilities + confidence'), which gives the agent a usable sense of the tool's function. However, it never explains where the options come from or how this tool differs from siblings like jev_evaluate and jev_score, and the inline 'criteria: {"option": "rubric..."}' is cryptic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent should call this when a single option needs to be chosen. There is no explicit guidance about when not to use it, no mention of alternatives among the sibling tools, and no exclusion criteria, leaving the agent to infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate state against typed questions. Returns {model, answers, usage}.
questions: {"id": {"type": "noul"|"choice"|"score", "instructions": ..., "criteria": {...} or [...]}}. Batch independent questions in one call; they run in parallel. endpoint: "direct" (TYPESAFE_API_KEY) or "zen".
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | jev-latest | |
| state | Yes | ||
| endpoint | No | direct | |
| questions | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It reveals that questions run in parallel and returns usage information (part of the return object), which is useful. However, it does not disclose potential side effects, authentication requirements beyond the 'TYPESAFE_API_KEY' hint, or rate limits, which are important for an API call. It could be more transparent about error behavior or response schema details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using a code-like format for the questions structure and front-loading the return type. It packs significant information into a few sentences, but the nested JSON notation in the description might be slightly cryptic for some agents, though it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with nested objects and an output schema, but the description covers key aspects: what it does, how to batch questions, and endpoint options. The output schema exists, so return values are documented separately. Gaps include lack of detail on 'state' formats and exact handling of 'zen' endpoint, but overall it is fairly complete for an agent to make basic calls correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains the 'questions' parameter structure with examples of types and nested fields, and mentions 'endpoint' values and 'model' default. However, it does not elaborate on 'state' beyond saying it can be various types, or provide detailed syntax for 'criteria' and 'instructions', leaving some gaps for complex usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates state against typed questions and returns a structured result, which distinguishes it from siblings by focusing on batch evaluation rather than single-question tools. However, it does not explicitly differentiate from siblings like jev_noul, jev_choice, or jev_score, relying on the name 'evaluate' to convey the aggregated nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage guidance: batch independent questions in one call for parallel execution, and mentions endpoint options ('direct' vs 'zen') with a hint about API key for 'direct'. It does not explicitly say when not to use it or name alternatives, but the batching advice implies it is for multi-question scenarios, which are better handled here than with single-question siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List models your key can use (GET /v1/models on direct; static list on zen).
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | No | direct |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It usefully discloses that 'direct' performs a live GET /v1/models call while 'zen' returns a static list. It does not discuss errors or rate limits, but for a simple listing operation the key behavioral distinction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the verb and resource front-loaded. The parenthetical adds the important endpoint nuance without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter listing tool with an output schema, the description covers purpose, key-based scope, and endpoint-dependent behavior. Nothing essential for correctly invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The parenthetical names both 'direct' and 'zen' behaviors, giving meaning to the endpoint parameter beyond the schema's default. It stops short of explicitly saying the parameter accepts these two string values, but an agent can infer it confidently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List models your key can use.' It also distinguishes the tool's scope (models available to the key) and the direct/zen behavioral split, making it easy to tell apart from the evaluation/scoring siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: use this tool when you need models accessible with the current key, and it explains the direct vs zen behavior. It does not explicitly name alternatives or when-not-to-use cases, but the sibling tools are clearly different operations, so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Yes/no judgment. Returns {type, noul (0=no..1=yes)}. Near 0.5 = uncertain.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | jev-latest | |
| state | Yes | ||
| endpoint | No | direct | |
| true_means | No | ||
| false_means | No | ||
| instructions | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains the output shape and the uncertainty interpretation, but omits side effects, authentication, rate limits, and the meaning of parameters like 'state' and 'instructions'. The disclosed information is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the core purpose front-loaded in the first sentence and the output format in the second. It avoids redundancy, though its brevity contributes to incompleteness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, two required, and zero schema descriptions or annotations, the description is grossly incomplete. It does not explain what 'state' or 'instructions' are, what true_means/false_means do, or any prerequisites. The presence of an output schema does not compensate for the missing parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the six parameters (state, instructions, model, endpoint, true_means, false_means). It adds no semantic value beyond the schema, leaving the agent to infer parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a yes/no judgment, with a specific return format and interpretation of the noul value. This distinguishes it from siblings like jev_choice or jev_score, though it does not name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the sibling tools (jev_evaluate, jev_choice, jev_score, jev_models). It implies a yes/no use case but does not specify exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rate along ordered levels (2-10 concrete descriptions). Returns score + legend + probabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | jev-latest | |
| state | Yes | ||
| criteria | Yes | ||
| endpoint | No | direct | |
| instructions | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear full behavioral disclosure. It mentions the output (score + legend + probabilities) but omits side effects, whether it calls a model, determinism, permissions, or rate limits. The schema hints at model and endpoint parameters, but the description does not clarify these behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the primary purpose, which is good. However, the parenthetical '(2-10 concrete descriptions)' is cryptic and could be misinterpreted. The structure is acceptable but not exemplary—it is concise but not optimally clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 3 required, and no annotations, the description is under-specified. It fails to explain parameter semantics, usage context, and behavioral nuances beyond output. Even accounting for the output schema, the description does not equip an agent to call this tool correctly in varied situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameter meaning. It hints that the tool uses '2-10 concrete descriptions' (likely for the criteria parameter) but does not explain 'state', 'instructions', 'model', or 'endpoint'. This leaves several parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Rate') and a specific resource ('along ordered levels'), and mentions it returns score, legend, and probabilities. This distinguishes it from general evaluation tools, though it does not explicitly name sibling differentiators like jev_choice or jev_evaluate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No conditions, prerequisites, or situational context are provided, leaving the agent without explicit decision criteria for selecting this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0jev_choicejev_evaluatejev_modelsjev_nouljev_scoreScored across 5 tools
jev_evaluate subsumes the other evaluation tools, creating potential overlap. The descriptions clarify that evaluate is for batched/mixed types while the specialized tools handle single questions, but an agent could still be unsure which to use for a one-off noul or choice query.
All tools share the 'jev_' prefix in lowercase snake_case, making them easily recognizable as a family. The names mix verbs and nouns (evaluate, models vs noul, choice, score), but the uniform prefix and short, predictable tokens keep the pattern strong.
Five tools is a well-scoped size for an evaluation API wrapper. It includes a general evaluator, three specialized question types, and a model discovery utility without unnecessary bloat.
The toolset covers all declared question types (noul, choice, score) and provides the necessary model listing capability. It lacks history or configuration management, but those are not implied by the server's focused purpose.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Human judgment for AI agents: discover capabilities, get quotes, and track paid human tasks.
A paid remote MCP for Pydantic AI structured output, built to return verdicts, receipts, usage logs,
Deterministic contextual decision arbitration and action routing for autonomous software. Takes current state, context, or intent plus caller-supplied candidate actions, state transitions, routes, refusals, escalations, tools, or models and returns a deterministic ordered candidate field. Also provides persistent machine representations for memory, retrieval, indexing, and downstream coherence measurement.
