jev-studio
Provides access to the Jev ruleset via a single read-only MCP tool.
Call
jev_instructionsto retrieve the Jev ruleset as instructions.Specify optional
modeintensity:lite,full, orultra(defaults tofullwhen omitted).Get structured output containing
{mode, instructions}for MCP hosts that pull context via tools.No mutating or state-changing operations are exposed.
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-studioClassify this support ticket as billing, technical, or sales"
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.
One-stop kit for playing with TypeSafe's Jev: MCP tools for Choice/Noul/Score, ready-made prompt libraries, and slash commands for every cookbook.
Badges
Related MCP server: jev-mcp
Install
pip install jev-studioTwo commands are installed:
jev— the CLI for TypeSafe's Jev decisions (verify, screen, classify, extract, match, route, ask, find, rerank, compact, batch).jev-studio— the MCP server that serves the Jev ruleset over stdio.
The CLI: jev
Jev turns natural-language state and a set of typed questions into typed answers (yes/no, choice, or score) with probabilities. The CLI wraps it in one-command judgments over text you pipe in.
Authenticate
Any one of these is enough (first found wins):
jev auth login # store TYPESAFE_API_KEY in the OS keychain (or 0600 file)
export TYPESAFE_API_KEY=... # from https://console.typesafe.ai/settings/keys
export OPENROUTER_API_KEY=sk-or-...
export CLOUDFLARE_API_TOKEN=... CLOUDFLARE_ACCOUNT_ID=...Inspect what's live: jev auth status.
Commands
Every command speaks JSON (--json), Markdown (--md), JSONL, CSV, TSV, or a colored text table. Use --pluck to lift one field. Use --fail-on <list> to make the process exit 2 when a judgment condition trips (great for CI gates).
Judgments
jev verify— check claims against evidence. Verdict + probabilities per claim, with asupporting_evidenceback-reference when there is more than one evidence item.jev screen— flag prompt injection, empty/boilerplate content, and irrelevance before an agent reads text. Recommendspass/review/block/skip.jev classify— one label (single), several (--multi), or a hierarchy (--taxonomy). Confidence-gatedautovsreview.jev extract— pull typed values out of text. Regex proposes candidates, Jev picks, code normalizes. Builtins:email,phone,url,amount,date,percent,number. Custom regexes vianame=/regex/:description.jev match— decide if record pairs are thesame,different, orunclear. Feed pairs, one list, or two lists (cross product).jev route— pick a handler for a request and fill its closed-set arguments in one call.jev ask— raw System One passthrough for any state and any questions (repeated--noul,--choice,--score, or--questions-json).
Ranking
jev find— rank up to 250 candidates against a plain-language query. Returns top-K and a document-levelanswered/partial/absentverdict.jev rerank— score each candidate independently and sort. Several can be relevant, or none.
Pipelines
jev compact— shrink an agent transcript by dropping stale tool calls verbatim; recent turns are always kept.jev batch— run a per-row command (classify,screen,verify) over JSONL or newline-delimited input with a bounded worker pool. Emits JSONL, one line per row.
Account
jev models— list the models available to your account.jev auth—login,logout,status. Keychain-first, file fallback.jev config—show,path,keys,set,unset. Defaults< file < env < flags.jev update— check PyPI for a newer release.
Examples
# Verify a claim against a file
jev verify "Helmets are optional for adults" --evidence @ordinance.txt
# Screen scraped HTML for prompt injection before letting an agent see it
curl -s https://example.com | jev screen --purpose "extract pricing" --fail-on block,review
# Classify a ticket in three labels, JSON output
jev classify "The invoice total is wrong" --labels billing,bug,feature --json
# Extract an email and a date from an invoice
jev extract @invoice.txt --want email --want date --context "an invoice"
# Rank documentation files for a question
jev find "how do I rotate API keys" --files 'docs/*.md' -k 3
# Batch-classify tickets with concurrency 8
jev batch -i @tickets.txt --concurrency 8 -- classify --labels billing,technical,sales
# Route a support request to a handler
echo "cancel my subscription" | jev route --handlers "cancel:cancel plan,upgrade,help"
# Inspect and edit configuration
jev config set verify.autoAccept 0.9Exit codes
Code | Meaning |
0 | Command completed and no |
1 | Usage, configuration, input, or transport error. |
2 | Judgment condition matched (e.g. a contradicted claim, injection blocked). |
Input references
Anywhere the CLI takes a value it accepts text, @path/to/file, or - (stdin). Escape a literal leading @ as @@.
Global flags
-m, --model NAME Jev model, e.g. jev-latest or jev-1.13.0
-P, --provider NAME auto | typesafe | openrouter | cloudflare
--timeout MS per-request timeout
--dry-run print the request that would be sent; don't call the API
--json, --md, --format text|json|jsonl|csv|tsv|md
--pluck PATH print one field (e.g. label, results[].verdict)
-q, --quiet omit the usage/model footer in text output
--no-color disable ANSI colorsConfiguration
Config file: $XDG_CONFIG_HOME/jev/config.json (or ~/.config/jev/config.json). Env overrides file, flags override env. See jev config keys for every settable path.
Environment overrides:
JEV_PROVIDER JEV_MODEL JEV_TIMEOUT_MS JEV_FORMAT
JEV_CONFIG JEV_CREDENTIALS JEV_CREDENTIAL_STORE JEV_NO_STORED_CREDENTIALS
JEV_DEBUG=1 # include stack traces on errorScriptability
Every jev command is safe to run unattended. None of them prompt for confirmation, and none ever will for a non-destructive change.
Read-only — never change stored credentials or config, safe to loop:
verify, screen, classify, extract, match, route, ask, find, rerank, compact, batch, models, update (only checks PyPI), version, auth status, config show|path|keys.
Mutating — write local state, still prompt-less:
Command | Writes to |
| OS keychain, or |
| Removes the key from the same store. |
| Config file ( |
Side effect on any command: the daily update check caches its result at update-check.json beside the config file. Disable with JEV_NO_UPDATE_CHECK=1 or -q.
In automation, prefer env vars (TYPESAFE_API_KEY, JEV_*) over auth login / config set so runs never touch shared state. Set JEV_NO_STORED_CREDENTIALS=1 to ignore stored keys entirely.
Convention: any future destructive command (e.g. a hypothetical auth purge or config reset) will require --yes to run non-interactively. Non-destructive mutations stay prompt-less.
The MCP server: jev-studio
jev-studio # speaks MCP over stdioPoint an MCP host at it:
{
"mcpServers": {
"jev": { "command": "jev-studio" }
}
}Exposes:
Prompt
jev— the Jev ruleset as a user message. Optionalmode:lite,full,ultra. Omit forfull.Tool
jev_instructions— same text plus structured output ({mode, instructions}) for hosts that pull context via tools. Read-only.
Develop
pip install -e ".[dev]"
pytestShip to PyPI:
python -m build
twine upload dist/*Claude Code
/plugin marketplace add utk2103/jev-Studio
/plugin install prompt-studio@jev-studioTwo separate prompts. Start a new session; the ruleset lands in system context on SessionStart.
Local clone:
/plugin marketplace add /path/to/jev-Studio
/plugin install prompt-studio@jev-studioCodex
codex plugin marketplace add utk2103/jev-Studio
codex plugin add prompt-studio@jev-studioTry something fun
A curated collection of 726 Jev use cases plus 50 runnable evals — every build linked to its project and source post. Search it, copy a brief, hand it to your agent.
Browse: jev-directory.netlify.app
Credits
The CLI is a Python port of the TypeScript jev-cli, rebuilt on the standard library with the same command surface and question shapes.
Contributing
See CONTRIBUTING.md.
License
MIT License — see LICENSE.
Available Tools
1 tooljev_instructionsA
Return the Jev ruleset for the given intensity (lite, full, or ultra).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Return' which implies a read operation, but it does not disclose side effects, error behavior, rate limits, or what happens if the mode is invalid or null. The schema allows null by default, which conflicts slightly with the description's 'given intensity' phrasing, but this is not a direct contradiction. The lack of behavioral context is a significant gap.
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?
A single sentence with no waste. The action, resource, and parameter domain are all front-loaded. Perfectly concise for the tool's simplicity.
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 one parameter, no annotations, and no output schema, the description explains the parameter but not the return format. The word 'ruleset' is vague; the agent might need to know whether it returns text, a list, or a structured object. With no output schema, this is a notable gap that could affect correct invocation expectations.
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 provides only a type and default for 'mode' with zero description coverage. The description adds meaning by enumerating the acceptable values (lite, full, ultra), which directly informs the agent what to pass. It does not explain what happens for other inputs, but the core semantics are covered.
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 (Return) and resource (Jev ruleset), and enumerates the valid intensity values (lite, full, ultra). It is immediately clear what the tool does, and with no siblings there is no differentiation burden.
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 when to use the tool: when you need the ruleset for a given intensity. It does not explicitly state exclusions or alternatives, but no siblings exist, so the context is sufficiently clear. A minor gap is that it doesn't specify that mode may be null (per schema) or how to handle an unsupported value.
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 tool update
v0.2.0- First observed
jev_instructions
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlapping purposes. The tool's purpose is singular and unambiguous.
The single tool name 'jev_instructions' follows a clear pattern with a prefix and a noun. Since there is only one name, there are no inconsistencies to evaluate.
A single tool feels too thin for a server named 'jev-studio', which implies a broader set of capabilities. Even for a specific function, one tool is on the extreme low end and likely insufficient for common agent workflows.
The tool covers all mentioned intensity levels (lite, full, ultra) and fulfills its stated purpose of returning a ruleset. No obvious gaps exist for this narrow scope, though additional related operations (e.g., listing available intensities) could enhance completeness.
Maintenance
Related MCP Connectors
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Read-only MCP server for the OPERANT AI operating-agent calibration benchmark.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides portable working rules and tooling instructions as MCP resources, ensuring consistent agent behavior across clients.MIT
- AlicenseNot gradedqualityBmaintenanceAn MCP server that exposes eleven typed decision tools—check, choose, score, judge, route, triage, guard, grep, rank, compact, and ask—so agents can make fast, branchable yes/no, option-pick, score, and filtering decisions on text via TypeSafe's Jev model.20 npm2MIT
- AlicenseNot gradedqualityCmaintenanceEnables MCP-capable agents to run TypeSafe's Jev judgment model as typed yes/no, choice, and score tools, with calibrated probabilities, confidence thresholds, escalation for uncertain or non-judgment tasks, and an optional action gate that fails open.1MIT
- AlicenseNot gradedqualityBmaintenanceEnables MCP clients to get machine-readable yes/no, choice, and score decisions from TypeSafe Jev, bridging fast classification to Cursor and other clients.MIT