Jev-MCP is a Model Context Protocol server that provides fast, no-text-generation typed judgments over supplied state using TypeSafe Jev models.
Run typed questions with jev_ask: mix Choice, Score, and Noul (yes/no) questions over arbitrary state.
Classify with jev_classify: pick one label from a closed list, optionally with an order ensemble for disagreement detection.
Score with jev_score: place state on an ordered rubric/levels.
Check with jev_check: evaluate independent yes/no propositions.
Match with jev_match: find the best candidate for a query with an explicit abstention signal (exists).
Screen with jev_screen: filter untrusted or instruction-like text (as a filter, not a security boundary).
Inspect with jev_health: list available models and measure round-trip latency.
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 classify these support tickets as bug, billing, or account access"
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 provides typed judgments over a closed answer set in about 130 ms, with no text generation, through TypeSafe.
Set TYPESAFE_API_KEY in the environment used by your MCP client, then run:
uvx --from git+https://github.com/blakestone-x/jev-mcp@v0.2.1 jev-mcpClaude Code:
claude mcp add --scope user jev -e TYPESAFE_API_KEY=... -- uvx --from git+https://github.com/blakestone-x/jev-mcp@v0.2.1 jev-mcpCodex (~/.codex/config.toml):
[mcp_servers.jev]
command = "uvx"
args = ["--from", "git+https://github.com/blakestone-x/jev-mcp@v0.2.1", "jev-mcp"]
env = { TYPESAFE_API_KEY = "..." }Cursor or another MCP client:
{
"mcpServers": {
"jev": {
"command": "uvx",
"args": ["--from", "git+https://github.com/blakestone-x/jev-mcp@v0.2.1", "jev-mcp"],
"env": { "TYPESAFE_API_KEY": "..." }
}
}
}Replace ... with the key value. Passing it through the client environment keeps it out of tool arguments and request state.
The scripts/register.sh helper requires Bash 4+; do not run it with sh. Apply mode reads
TYPESAFE_API_KEY from the environment and refuses to change client configuration when it is unset. --apply writes
the plaintext key into ~/.codex/config.toml and the Claude Code user config. The key is briefly visible in the process
list while claude mcp add runs because that command receives it as an argument. On Windows, use
scripts/register.ps1; it restricts the resulting configuration files to the current user and keeps a .bak copy
before rewriting an existing Codex configuration.
The install examples pin the public v0.2.1 tag. Omitting the tag tracks the repository's default branch instead.
Related MCP server: decompose
This call classifies one state containing five support-ticket texts against one label map. It returns one label for the combined state; send one request per ticket when you need an individual label for each ticket:
{
"state": [
"The password reset link expired before I could use it.",
"I do not recognize the charge on my statement.",
"My order arrived two days late.",
"The export button shows a blank screen.",
"Please add a dark theme."
],
"labels": {
"account_access": "Login, password, or sign-in problems.",
"billing": "Charges, invoices, or payment questions.",
"delivery": "Late, missing, or damaged deliveries.",
"bug": "Unexpected product behavior.",
"feedback": "Suggestions or general comments."
},
"question": "Which category best fits the combined state of these five support tickets?",
"add_other": true
}The response is an ordinary MCP structured result with a stable envelope:
{
"ok": true,
"model": "jev-latest",
"answers": {
"choice": "account_access",
"confidence": 0.91,
"probabilities": {
"account_access": 0.91,
"billing": 0.03,
"delivery": 0.02,
"bug": 0.02,
"feedback": 0.01,
"other": 0.01
},
"band": "act"
},
"usage": {
"input_tokens": 420,
"output_tokens": 0,
"est_cost_usd": 0.00001764
},
"latency_ms": 130.0
}tool | use it for | not for |
| Your own Choice, Score, and Noul question map | Text generation or numeric extraction |
| Selecting one label from a closed list | Open-ended writing or ranking without labels |
| Placing state on an ordered rubric | Returning a number extracted from text |
| Independent yes/no propositions | Treating a probability as proof |
| Matching a query to candidates with abstention | Assuming the closest candidate is genuine |
| Filtering instruction-like or untrusted text | A security boundary or authorization decision |
| Listing served models and measuring round-trip latency | Evaluating application content |
The key stays in the environment and never in the agent's context.
All policy thresholds live in one file: jev_mcp/questions.py.
Confidence is distribution concentration, not correctness.
Screening is a filter, not a security boundary.
Gate consequential decisions on the Score.
Order-ensemble turns disagreement into a cheap review signal.
Matching includes abstention through the exists Noul.
examples/triage.questions.json and examples/route.questions.json are generic, complete jev_ask request examples. They contain a state object and a questions map in the wire shape accepted by jev_ask; replace state with your own data and send the whole object as the tool arguments. Jev intentionally does not load profiles for you.
import json
with open("examples/triage.questions.json", encoding="utf-8") as file:
request = json.load(file)
result = await session.call_tool("jev_ask", request)See RECIPES.md for comparison, reference-in-state, descriptions, batching, calibration, and order-ensemble patterns.
The measurements below come from a field-service company's production data.
measurement | result |
Clean labels at confidence 0.8 to 1.0 | 95% agreement |
One-line label descriptions | 81.0% agreement; 1,689 tokens/request |
Rich label descriptions | 84.5% agreement; 4,745 tokens/request |
Reversing criteria order | 32 of 200 choices flipped; flipped confidence averaged 0.42 |
Candidate matching | 8 of 11 picks matched when a candidate existed; misses had low |
Amount comparison | 100% on 64 cases where displayed amounts differed |
Past-date comparison | 100% for “is it past”; 98% on a four-level overdue Score |
The default serialized request budget is 120,000 characters for the state and questions sent to the service. Set
JEV_MCP_MAX_REQUEST_CHARS to use a different positive limit. JEV_MCP_MAX_STATE_CHARS remains accepted as a
compatibility alias for one release. For jev_match, the budget applies to the full candidate input and to each
serialized candidate window.
The service provider has not published rate limits. What we observed on one early-access key: small requests ran at
160 per second with flat latency and no rate-limit responses, while a sustained run of about 40 requests per second
at 1,700 tokens each drew 429s after three minutes. Treat the limit as tokens per minute rather than requests per
second, keep bulk jobs resumable, and back off for seconds on a 429, not milliseconds. This server's retry policy
backs off from 1 second to 20 seconds and honors Retry-After. A Noul carries evidence strength, not confidence. Jev is early access:
validate thresholds and outputs against your own data, and keep consequential actions behind your normal review controls.
jev_match accepts a window from 20 through 254 and up to 2,000 candidates by default. Set
JEV_MCP_MATCH_MAX_CANDIDATES to change the candidate cap. For n candidates, the normal billed request count is
ceil(n / window) + 1: one request per window plus one finalist-selection request. A single-window call may need
only its initial request, and a call with no finalists may omit the extra request. exists is the maximum of the
per-window values, so more windows can inflate it; inspect windows and exists_by_window too. The match deadline is
45 seconds by default and can be changed with JEV_MCP_MATCH_DEADLINE_S.
Set JEV_MCP_MODEL to select the model; it defaults to jev-latest. The timeout contract is: a single tool call can take up to about 30 seconds when the service is degraded; jev_classify(ensemble=true) can take about 60 seconds because it makes two sequential evaluations; jev_match can take up to its deadline. SDK attempts use an 8-second HTTP timeout and a 20-second retry budget.
MIT. See LICENSE.
Use Jev for typed judgments over supplied state; it is not for text generation or numeric extraction.
Confidence is distribution concentration, not correctness. The default est_cost_usd uses the published early-access input price and may change.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| questions | 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 and adds two genuinely useful disclosures: confidence is distribution concentration not correctness, and the default cost uses a changeable early-access price. These are valuable caveats, but core behavioral aspects — how the tool responds to invalid questions, determinism, error behavior — are left unstated.
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?
Three sentences, each earning its place: purpose plus exclusion first, then two high-value caveats. Front-loaded and free of repetition or padding. This is a model of efficient description writing.
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?
The output schema covers return values, and the discriminated-union schema structure carries some explanatory weight. But for a tool with 0% parameter documentation, no annotations, and a complex nested schema, the description leaves meaningful gaps — particularly around what constitutes a valid state and when to use each question type. Adequate but not complete for the complexity level.
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. It only loosely maps 'supplied state' to the state parameter and 'typed judgments' to questions, adding little real semantic meaning. The nested questions schema with three discriminated types (noul, choice, score) is structurally self-documenting but semantically unexplained; the description leaves the agent to infer what each question type means.
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 ('typed judgments over supplied state') with an explicit scope exclusion ('not for text generation or numeric extraction'). This distinguishes it from more specific sibling tools like jev_classify or jev_score, though it doesn't name them directly, so it falls short of a 5.
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?
The negative clause 'it is not for text generation or numeric extraction' provides a when-not-to-use signal, and 'typed judgments' implies when to use it. However, no sibling alternative is named and no explicit condition for choosing this tool over jev_classify, jev_score, etc. is given. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use Jev for independent yes/no checks over state; it is not for text generation or numeric extraction.
Confidence is distribution concentration; Noul probability is evidence strength. The default est_cost_usd uses the published early-access input price and may change.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| propositions | 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. It mentions confidence and Noul probability, hinting at output semantics, and notes the cost estimate may change, but it does not disclose whether the tool is read-only, has side effects, requires authentication, or how it handles the state input. This is a significant gap for a tool that likely inspects state.
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 the main purpose is front-loaded in the first sentence. The second paragraph adds technical jargon that may be useful but is not essential, keeping it relatively lean.
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?
Given the tool has an output schema and nested objects, the description should explain how to structure the propositions and state, but it does not. It also lacks details on the output semantics beyond a brief mention of confidence and Noul probability. An agent would struggle to use this tool correctly without additional documentation.
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 what 'state' or 'propositions' mean, what formats are expected, or how they relate. The only clue is 'over state', which is too vague to guide an agent in constructing valid arguments.
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 performs 'independent yes/no checks over state', a specific verb and resource, and explicitly excludes text generation and numeric extraction, distinguishing it from sibling tools like jev_ask and jev_classify.
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 a clear negative scope ('not for text generation or numeric extraction') which helps an agent rule out this tool for those tasks, but does not explicitly mention positive use cases or alternative tools by name, leaving some inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use Jev to select one label from a closed list; it is not for text generation or numeric extraction.
Confidence is distribution concentration, not correctness. With order-ensemble enabled, order flips concentrate at low confidence, so disagreement is a second, cheap reason to route to a person. The default est_cost_usd uses the published early-access input price and may change.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| labels | Yes | ||
| ensemble | No | ||
| question | No | ||
| add_other | No |
| 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 and does so excellently. It discloses that confidence is distribution concentration not correctness, explains how order-ensemble flips concentrate at low confidence and are a reason to route to a person, and warns that the cost estimate may change. These are non-obvious behavioral traits that go far beyond the schema.
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?
Three sentences, each earning its place. The first states purpose and exclusions, the second provides critical behavioral caveats, the third discloses a cost caveat. No fluff, front-loaded with the most important information.
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?
The tool has an output schema (so return values are covered) and a moderate parameter count. The description gives essential behavioral context but omits explanations for 'question' and 'add_other'. However, these are likely secondary options, and the core usage is clear. It is nearly complete for a classification tool.
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. It indirectly explains 'labels' (the closed list) and 'ensemble' (order-ensemble behavior), but leaves 'state', 'question', and 'add_other' unexplained. Some parameters are inferable from the tool name and purpose, but the description does not fully document them.
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 explicitly states the tool selects one label from a closed list and explicitly excludes text generation and numeric extraction, which distinguishes it from likely siblings. It is specific about the verb ('select') and resource ('one label from a closed list'), making the purpose unmistakable.
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?
The description clearly states what the tool is for and what it is not for, giving a strong when-not guidance. It does not name specific alternative tools, but the exclusions (text generation, numeric extraction) imply when to avoid it. It also provides contextual guidance on interpreting confidence and ensemble behavior, which helps in deciding when to route to a person.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use Jev health to inspect the configured model and the account's available models and release dates.
Health checks report zero estimated cost; the published early-access input price may change for other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 behavioral burden. It adds useful context beyond the name by disclosing that health checks report zero estimated cost and that the published early-access input price may change for other tools. This is relevant, non-obvious behavioral information.
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 two sentences with no filler. The main purpose is front-loaded, and the cost caveat earns its place as a meaningful behavioral note.
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 zero-parameter health inspection tool, the description is complete: it states what is inspected, notes the cost behavior, and an output schema exists to document return structure. Nothing essential 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?
The tool has zero parameters and 100% schema coverage, so there are no parameter semantics to document. This meets the baseline for tools with no parameters.
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 uses a specific verb ('inspect') and names the resources: the configured model and the account's available models and release dates. This clearly states what the tool does, though it does not explicitly contrast itself with sibling tools.
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?
The phrase 'Use Jev health to inspect...' gives a clear intended usage context, but it does not mention when not to use it or name any alternatives among the sibling tools. Usage 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.
Find the best candidate with an explicit abstention signal; it is not text generation.
Candidates are evaluated in windows, and exists is the maximum of the
per-window Noul probabilities. More windows can therefore inflate exists;
inspect exists_by_window and windows before using the result. The
default est_cost_usd uses the published early-access input price and may change.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| window | No | ||
| question | No | ||
| candidates | 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 behavioral burden and does so well: it discloses windowing behavior, that `exists` is the maximum per-window probability, that more windows can inflate `exists`, and that `est_cost_usd` is based on an early-access price that may change. These are non-obvious, decision-relevant details beyond the schema.
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, front-loaded with the primary purpose, and every sentence adds useful information. The cost caveat and inflation warning are non-obvious and earn their place.
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?
The description strongly covers algorithm behavior and caveats, but for a tool with 0% parameter schema coverage, an opaque `candidates` object, and no annotation context, it leaves key invocation details unexplained. An agent could still misuse `candidates` or `question` without further documentation, making this minimally viable but not complete.
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 never explains `query`, `candidates`, `window`, or `question`. The `candidates` object is especially opaque, and the description only indirectly references windows through output fields like `exists_by_window` and `windows` rather than clarifying the `window` parameter.
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 opens with a specific verb and resource: 'Find the best candidate with an explicit abstention signal.' It also explicitly distinguishes itself from text generation, which helps an agent separate it from sibling tools like jev_ask.
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?
The description implies this is for candidate matching with an abstention signal and states what it is not ('not text generation'), but it does not name alternative tools or provide explicit when-to-use versus when-not-to-use guidance. The usage context is clear enough, though no exclusion or alternative is fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use Jev to place state on an ordered situation rubric; it is not for text generation or numeric extraction.
Confidence is distribution concentration, not correctness. The default est_cost_usd uses the published early-access input price and may change.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| levels | Yes | ||
| question | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden, and it does add value: the confidence caveat ('distribution concentration, not correctness') and the volatile cost default are genuinely useful non-obvious traits. It does not disclose return behavior or side effects, but the presence of an output schema partially covers the former.
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?
Three short declarative sentences with the core purpose front-loaded and the caveats kept compact. Nothing is redundant; both caveats earn their place even if terse.
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?
The output schema covers the return shape, but the tool has three required parameters with zero schema descriptions and no annotations, and the description is too sparse for an agent to confidently construct a valid levels array or phrase an effective question. Adequate but with clear gaps.
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 schema properties carry only titles, so the description must compensate. It loosely maps 'state' and 'levels' to the rubric idea but never explains what levels should contain, how ordering is determined, exactly what forms state may take, or how question drives the scoring.
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 names a specific operation — 'place state on an ordered situation rubric' — and adds negative scope ('not for text generation or numeric extraction'), which helps separate it from text-y siblings like jev_ask. It stops short of naming the exact sibling it competes with, so differentiation is partial rather than complete.
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?
The 'not for text generation or numeric extraction' clause gives one exclusion, and 'ordered situation rubric' implies the intended context. But there is no positive when-to-use guidance and no explicit routing against siblings like jev_match, jev_screen, or jev_classify; the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use Jev to screen untrusted text; it is a filter, not a security boundary.
Confidence is distribution concentration, not correctness. The default est_cost_usd uses the published early-access input price and may change.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| source | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It discloses useful behavioral traits: it is a filter, not a security boundary; confidence reflects distribution concentration, not correctness; and est_cost_usd may change. However, it does not cover operational behaviors like side effects, latency, or failure modes.
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 and front-loaded: it states the purpose first, then adds high-value caveats. Each sentence earns its place, with no repetition or 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?
The output schema covers return values, and the description provides important caveats, but it omits the meaning of the 'source' parameter and does not clarify how this tool relates to sibling Jev tools. For a two-parameter tool, this is adequate but has clear gaps.
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 description coverage is 0%, and the description does little to compensate. 'Text' can be inferred from 'screen untrusted text,' but the optional 'source' parameter is completely unexplained, leaving the agent without semantic guidance for an important input.
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: 'screen untrusted text,' and adds a meaningful caveat that it is a filter, not a security boundary. It does not explicitly differentiate from sibling tools like jev_classify or jev_check, so it stops short of a 5.
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?
The description gives a clear context for use ('screen untrusted text') but does not explain when to choose this tool over alternatives or when not to use it. The 'not a security boundary' caveat implies a limitation, but no sibling routing or exclusion criteria are provided.
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.2.1jev_askjev_checkjev_classifyjev_healthjev_matchjev_scorejev_screenScored across 7 tools
Each tool maps to a distinct judgment mode: open typed judgment, closed-list classification, ordered scoring, yes/no checking, candidate matching, text screening, and health inspection. The generic jev_ask could broadly overlap with the more specific modes, but the descriptions clarify when each should be used.
All tools share the consistent jev_ prefix and use short lowercase names matching their action or purpose. The naming convention is uniform and predictable across the entire set.
Seven tools is a well-scoped set for a single Jev judgment API. Each tool covers a distinct operation without redundancy, and the count feels neither thin nor bloated.
The tool surface covers the core judgment types Jev appears to support: ask, classify, score, check, match, and screen, plus health for configuration introspection. The repeated exclusions of text generation and numeric extraction indicate those are intentionally out of scope rather than missing.
Human judgment for AI agents: discover capabilities, get quotes, and track paid human tasks.
Sentiment, toxicity, entity extraction, PII, translation, summary, QA, fraud scoring, safety audit.
Get a real human to verify, decide, or improve an AI agent's work.
Preflight QA for AI-agent deliverables with structured verdicts and repair guidance.
