Skip to main content
Glama

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

jev-studio MCP server – quality and maintenance score on Glama M8ven Score

Related MCP server: jev-mcp

Install

pip install jev-studio

Two 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 a supporting_evidence back-reference when there is more than one evidence item.

  • jev screen — flag prompt injection, empty/boilerplate content, and irrelevance before an agent reads text. Recommends pass / review / block / skip.

  • jev classify — one label (single), several (--multi), or a hierarchy (--taxonomy). Confidence-gated auto vs review.

  • 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 via name=/regex/:description.

  • jev match — decide if record pairs are the same, different, or unclear. 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-level answered / partial / absent verdict.

  • 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.9

Exit codes

Code

Meaning

0

Command completed and no --fail-on condition matched.

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 colors

Configuration

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 error

Scriptability

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

jev auth login

OS keychain, or credentials.json (0600) next to the config file / $JEV_CREDENTIALS. Prompts for the key on stdin unless --key is given.

jev auth logout

Removes the key from the same store.

jev config set / unset

Config file (jev config path).

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 stdio

Point an MCP host at it:

{
  "mcpServers": {
    "jev": { "command": "jev-studio" }
  }
}

Exposes:

  • Prompt jev — the Jev ruleset as a user message. Optional mode: lite, full, ultra. Omit for full.

  • Tool jev_instructions — same text plus structured output ({mode, instructions}) for hosts that pull context via tools. Read-only.

Develop

pip install -e ".[dev]"
pytest

Ship to PyPI:

python -m build
twine upload dist/*

Claude Code

/plugin marketplace add utk2103/jev-Studio
/plugin install prompt-studio@jev-studio

Two 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-studio

Codex

codex plugin marketplace add utk2103/jev-Studio
codex plugin add prompt-studio@jev-studio

Try 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 tool
jev_instructionsA

Return the Jev ruleset for the given intensity (lite, full, or ultra).

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNo

TDQS

A3.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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. 1 tool updatev0.2.0
    • First observedjev_instructions

TDQS

A3.9/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlapping purposes. The tool's purpose is singular and unambiguous.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    An 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 npm
    2
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables 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.
    1
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables MCP clients to get machine-readable yes/no, choice, and score decisions from TypeSafe Jev, bridging fast classification to Cursor and other clients.
    MIT