Jev MCP Server
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 ServerUse Jev to classify this support ticket and score its urgency."
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 MCP Server
Give Codex, Claude, and other MCP clients a tool for typed decisions with TypeSafe Jev.
Classify documents. Triage tickets. Score relevance. Review content against a rubric. Ask several independent questions in one call and get structured answers instead of generated prose.
Independent, community-maintained project. Not affiliated with TypeSafe. No database, application backend, or project-specific integration is required.
What it exposes
One tool: jev_evaluate.
Question type | Use it for | Result |
| A yes/no judgment | Probability of yes, from 0 to 1 |
| Selecting one of your named options | Choice, probability distribution, confidence |
| Rating against ordered descriptive levels | Fractional score, probability distribution, confidence |
Each response also includes the actual model, token usage, total latency, and attempt count. Questions may be mixed in one call. The server uses the native TypeSafe API shapes, including structured instructions and criteria.
Jev evaluates the content you supply. It does not fetch URLs, search the web, write explanations, or perform actions. Confidence describes the model's distribution; it does not prove factual accuracy. Keep consequential decisions with the calling agent or a human reviewer.
Related MCP server: Prompt Compass MCP
Install from source
Requires Node.js 22+ and a TypeSafe API key.
git clone https://github.com/MattiooFR/mcp-server-jev.git
cd mcp-server-jev
npm ci --ignore-scriptsCreate a private environment file outside the repository, for example ~/.config/jev/credentials.env:
TYPESAFE_API_KEY=your-typesafe-api-keyOn macOS/Linux, restrict its permissions with chmod 600 ~/.config/jev/credentials.env. Do not commit this file. Use absolute paths in client configuration: most MCP clients do not expand ~ in arguments.
The server starts over stdio. No HTTP port or background daemon is needed; each MCP client launches its own process.
Codex
codex mcp add jev -- node \
--env-file=/absolute/path/to/credentials.env \
/absolute/path/to/mcp-server-jev/src/cli.mjsThis adds a user-level server, available across projects. Start a new Codex session after registration.
Claude Code
claude mcp add --scope user --transport stdio jev -- node \
--env-file=/absolute/path/to/credentials.env \
/absolute/path/to/mcp-server-jev/src/cli.mjsStart a new session, then check /mcp.
Claude Desktop and other MCP clients
Add this entry to the client's MCP configuration, preserving its existing servers:
{
"mcpServers": {
"jev": {
"command": "node",
"args": [
"--env-file=/absolute/path/to/credentials.env",
"/absolute/path/to/mcp-server-jev/src/cli.mjs"
]
}
}
}If a desktop client cannot find Node, set command to its absolute path. Restart that client to load the server. Local stdio configuration does not expose the server to hosted web clients such as claude.ai.
Example
Ask your agent:
Use Jev to route this support ticket, detect whether it requests a refund, and score its urgency.
The tool takes a state and a map of questions:
{
"state": "I was charged twice for one order. Please refund the duplicate.",
"questions": {
"department": {
"type": "choice",
"instructions": "Which department should handle this ticket?",
"criteria": {
"billing": "Payments, invoices, refunds",
"technical": "Bugs and broken features",
"other": "Neither category fits"
}
},
"refund": {
"type": "noul",
"instructions": "Does the ticket explicitly request a refund?"
},
"urgency": {
"type": "score",
"instructions": "How time-sensitive is this ticket?",
"criteria": [
"Routine request without a deadline",
"Time-sensitive issue with a workaround",
"Immediate deadline or blocked critical activity"
]
}
}
}A three-level score ranges from 0 to 2, not 0 to 3. It may fall between levels. Define concrete descriptions rather than labels such as “low / medium / high”.
For a batch, put items with stable IDs in state and ask questions that explicitly reference each item. Question IDs are output keys only; Jev does not see them. For example, use instructions like Does item A17 contain a deadline?, not just a question named A17_deadline.
Do not expect one question to use another question's answer. Questions run independently against the same state. Send a second call when a decision depends on a previous result.
See examples/support-ticket.json and examples/content-review.json.
Configuration and limits
Setting | Default |
| Required; read from the server environment |
|
|
The model is pinned for reproducibility. Set JEV_MODEL=jev-latest to follow the provider alias, or specify another jev-x.y.z version. Recheck your thresholds when changing models.
Local limits: 1–100 questions per call, 1–255 choices, 2–10 score levels, and a 256 KiB serialized request. The byte limit is not a token estimate: the provider can still reject a request over its context limit. Split large batches instead of truncating content silently.
The server allows three concurrent calls per process. It retries HTTP 429/5xx responses up to three attempts, honors short Retry-After values, and returns longer cooldowns to the caller. Network errors and timeouts are not automatically replayed because the provider may already have processed the request. Each attempt has a 30-second timeout. Configure the MCP client timeout to at least 120 seconds for retries. Separate client processes share your upstream account quota.
Malformed, incomplete, or mismatched responses return a tool error instead of a usable decision. No fallback model is substituted.
Privacy and cost
Calls send the supplied state and questions to
https://api.typesafe.ai/v1/systemoneusing your API key. TypeSafe's terms, retention policy, and pricing apply.This server does not log or persist input content, answers, or API keys. Your MCP client may retain tool arguments and results in its own history.
The endpoint is fixed; callers cannot redirect credentials to another host. HTTP redirects are rejected.
Tool results include token usage, not an estimated dollar cost. Calls and retries may consume provider quota.
Treat evaluated documents as untrusted data. Scores do not authorize file deletion, publication, payment, or any other action.
Development
npm ci --ignore-scripts
npm testTests run offline with mocked provider responses and real MCP client/server protocol exchanges. CI runs on Node 22 and 24.
An optional live test makes one API evaluation using a synthetic support ticket:
node --env-file=/absolute/path/to/credentials.env scripts/smoke.mjsDistribution
The project provides a standard npm executable, mcp-server-jev, with a restricted package file list. It is not yet published to npm. To build and install a distributable tarball:
npm pack
npm install -g ./mcp-server-jev-0.1.0.tgzAfter installation, MCP clients can run mcp-server-jev when TYPESAFE_API_KEY is supplied in their server environment. The source installation above works without a registry release.
Contributing
Bug reports and focused pull requests are welcome. Include a minimal synthetic example and run npm test. Never include API keys, private documents, or customer data in issues or fixtures. Live API tests must remain opt-in.
License
MIT.
Available Tools
1 tooljev_evaluateEvaluate with JevARead-only
Evaluate supplied text or JSON with TypeSafe Jev: classify records, triage tickets, score quality, judge relevance, compare options, or audit content. Mix independent noul (probability of yes), choice (named options), and score (ordered rubric) questions in one call. Returns typed answers, probabilities, confidence where available, model and token usage. For batches, include all items in state and explicitly identify each target item in its question instructions; question IDs are not seen by the model. Does not fetch URLs, browse, generate explanations, or modify data. Sends supplied content to the external TypeSafe API and consumes quota. Review uncertain or consequential results.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Content to evaluate: text, records, documents, code, or other JSON. Only this supplied content is evaluated; URLs are not fetched. | |
| questions | Yes | Named independent questions. Noul: probability of yes. Choice: option descriptions. Score: 2–10 ordered descriptive levels, indexed from 0. IDs are only output keys: identify the target item in instructions, not just in its question ID. |
Output Schema
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| usage | Yes | |
| answers | Yes | |
| attempts | Yes | |
| latency_ms | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover readOnly, openWorld, idempotent, and destructive hints, but the description adds critical behavioral context: it sends supplied content to an external API and consumes quota (a side effect not captured by annotations), returns probabilities/confidence/token usage, and notes that question IDs are not seen by the model. No contradiction with annotations.
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 information-dense but every sentence earns its place: purpose, use cases, question mixing, output details, batch guidance, behavioral limitations, and side-effect warning. It is front-loaded with the core purpose and there is no redundant 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 nested objects and three question types, the description covers everything an agent needs: input semantics, output characteristics, constraints, side effects, and caution for consequential results. It is fully self-sufficient and leaves no major gap.
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?
Even though the schema describes both parameters at 100% coverage, the description adds meaningful semantics: explains the three question types (noul, choice, score), clarifies that IDs are only output keys and that the target item must be identified in instructions, and instructs on batch state usage. This goes well beyond the schema structure.
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 ('Evaluate') and the target resource ('supplied text or JSON with TypeSafe Jev') and enumerates concrete use cases (classify, triage, score, judge, compare, audit). It also clearly differentiates by listing what it does not do (fetch URLs, browse, generate explanations, modify data), so an agent can distinguish it from other tools even without 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?
Provides explicit when-to-use guidance (evaluate text/JSON) and explicit exclusions (does not fetch URLs, browse, generate explanations, or modify data). It gives batch-specific instructions (include all items in state, identify target item in question instructions) and a safety instruction (review uncertain or consequential results). This is far beyond a bare 'use for evaluation' statement.
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.1.0- First observed
jev_evaluate
TDQS
Scored across 1 tool
There is only one tool, so an agent cannot confuse it with another tool. Its name and description clearly identify it as the evaluation entry point.
The sole tool uses a clear snake_case verb_noun convention ('jev_evaluate'), consistent with a single-tool surface. No conflicting naming patterns exist.
One tool is appropriate because the server is a focused wrapper around a single Jev evaluation operation. The tool is broad enough to handle classification, scoring, choice, and batch use cases, so additional tools would add little value.
For its stated scope—evaluating supplied text/JSON—the tool covers all core needs: multiple question types, batch evaluation, typed answers, confidence, and usage metadata. The explicit exclusions (fetching URLs, generating explanations) are outside the server's purpose, not missing features.
Maintenance
Related MCP Connectors
Evidence-readiness MCP server: validate, audit, and score briefs, memos, and evidence packs.
A paid remote MCP for HyperFrames, built to return verdicts, receipts, usage logs, and audit-ready J
A paid remote MCP for Equibles, built to return verdicts, receipts, usage logs, and audit-ready JSON
Append-only decisions with provenance, supersession, retrieval, and audited MCP actions.
Related MCP Servers
- AlicenseAqualityBmaintenanceProvides MCP tools for lead qualification, enabling evidence gathering from CRM, scoring, and knowledge base with role-based access and deterministic decision gating.4AGPL 3.0
- AlicenseNot gradedqualityBmaintenanceProvides MCP clients a single decision-only tool to classify prompts as safe for local or cloud models, or as containing PII or jailbreak content, without executing actions or calling AI models.18 npmCryptographic Autonomy 1.0 (Combined Work Exception)
- AlicenseAqualityCmaintenanceEnables agents to perform typed judgments—classify, score, check, match, and screen—over closed answer sets with confidence scores, without text generation.74MIT
- AlicenseNot gradedqualityCmaintenanceEnables MCP clients to call TypeSafe's JEV classifier and receive structured, typed judgments with probabilities for binary, choice, and scoring questions.MIT