Skip to main content
Glama
jiawei686

jev-domain-mcp

by jiawei686
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

jev-domain-mcp

⚠️ Superseded by single-purpose servers. This aggregated "two tools in one server" repo is kept only as a reference example of the bundled approach. The recommended layout is one MCP = one function. Use these instead:

Domain-specific MCP tools powered by TypeSafe Jev — the System One decision model. The agent gets typed decisions, not prose: each tool pre-builds the Jev questions (candidate sets, rubric, thresholds), so the host never needs to know Jev's API.

This fills the gap identified in the Jev ecosystem: the generic Jev MCP layer is already crowded (burnigtm/jev-mcp, hangarbay/jev.mcp, mcp-typesafe), but the domain apps in the gallery are standalone CLIs — none expose their decision function as an MCP tool. This server wraps two of them.

Tools

Tool

Domain

What it decides

review_patch

Dev workflow

Patch verdict (approve / request_changes / needs_discussion), safety probability, severity, auto_merge vs human_review

screen_content

Content safety

Spam & toxicity probabilities, category, severity, allow / review / block

Both return a confidence (calibration concentration, not truth) and an action the agent can branch on directly.

Related MCP server: jev-mcp

Install

npm install
npm run build

Set your key (optional — without it the server runs in deterministic mock mode, no network):

export TYPESAFE_API_KEY=ts_xxx      # live Jev calls
# or
export JEV_MCP_MOCK=1               # force deterministic mock (no key needed)

Diagnostics:

node dist/index.js doctor
node dist/index.js doctor --json

Use

Register the server with any MCP client (Cursor, Codex, Claude Code, WorkBuddy):

{
  "mcpServers": {
    "jev-domain": {
      "command": "node",
      "args": ["/absolute/path/to/jev-domain-mcp/dist/index.js"],
      "env": { "TYPESAFE_API_KEY": "ts_xxx" }
    }
  }
}

Then the agent can call review_patch and screen_content like any other tool.

How a tool works

state (diff / text) ──► Jev: one request, parallel typed questions ──► structured result

  • Noul → 0..1 probability (is it safe? is it spam?)

  • Choice → pick from a fixed candidate set (verdict, category)

  • Score → ordinal rubric (severity)

The result includes probabilities + confidence, and an action derived from a simple confidence gate. Low confidence always routes to a human / stronger model — that is the whole point of a calibrated decision model.

Constraints (from Jev)

  • Pure text input: no image / audio / video.

  • State + all questions must fit ~64k tokens total; a single question ≤ 32k.

  • Do arithmetic / date math in host code, not in Jev.

  • Output is free; you pay only for input tokens.

License

MIT

Available Tools

2 tools
review_patchA

Code-review gate powered by Jev (System One decision model). Given a git diff and optional context, returns a verdict (approve / request_changes / needs_discussion), a safety probability, a severity score, a calibrated confidence, and an action (auto_merge / human_review). Only execute auto_merge on high confidence.

ParametersJSON Schema
NameRequiredDescriptionDefault
diffYesThe git diff or patch to review.
contextNoOptional surrounding context (file purpose, PR description).

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and discloses that this is an AI decision gate returning a verdict, safety probability, severity, confidence, and action. The caution 'Only execute auto_merge on high confidence' implies the tool itself does not execute the merge and warns about the risk, adding behavioral context beyond annotations.

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?

The description is compact and front-loaded with the core purpose. Every sentence contributes: the first defines the tool, the second lists inputs and outputs, and the third gives a critical safety instruction. There is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because there is no output schema, the description correctly explains all return values (verdict, safety probability, severity score, calibrated confidence, action). It also covers the required and optional inputs and the action condition, making the tool fully invocable by an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description rephrases the inputs ('git diff and optional context') but adds no new detail beyond the schema's own parameter descriptions, so it does not elevate the score.

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 opens with 'Code-review gate powered by Jev (System One decision model)', which immediately states the tool's purpose with a specific verb and resource. It then enumerates the exact inputs and outputs, clearly distinguishing this from the sibling screen_content, which is unrelated.

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 clearly indicates when to use the tool (given a git diff and optional context) and gives an explicit instruction on how to act on its result: 'Only execute auto_merge on high confidence.' It does not name alternative tools or exclusions, but the only sibling is screen_content, so no routing conflict exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

screen_contentA

Content-moderation & classification gate powered by Jev. Given text, returns spam and toxicity probabilities, a category, a severity score, a calibrated confidence, and an action (allow / review / block). Low confidence routes to review; clear, severe violations route to block.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesThe text to screen.
categoriesNoOptional custom category list (replaces defaults).

TDQS

A4/5.0
Behavior4/5

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 clearly states the outputs and the routing rules (low confidence → review, severe → block), which is valuable. However, it does not mention potential side effects (e.g., data persistence, rate limits) or any prerequisites like authentication. For a classification tool, this is a minor omission, but the transparency is strong overall.

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?

The description is two sentences, with the core purpose front-loaded in the first sentence and decision logic in the second. There is no wasted language; every clause contributes to understanding the tool's behavior. It is optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple outputs, routing logic) and the absence of an output schema, the description provides a comprehensive overview of what is returned and the action logic. It does not detail the exact output format (e.g., JSON structure) or severity scale, but those may be inferable or dynamic. For an agent to call the tool correctly, the description is sufficient and complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both 'text' and 'categories' are already documented. The description does not add any new meaning beyond the schema; it only refers to 'text' implicitly and does not elaborate on 'categories'. Since the schema already does the heavy lifting, a baseline of 3 is appropriate.

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 ('screen'), a specific resource ('text'), and clearly enumerates the outputs (spam/toxicity probabilities, category, severity, confidence, action). It also conveys the decision logic (review vs block), making its purpose unambiguous. While it does not explicitly contrast with the sibling review_patch, the name and description make it distinct enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but provides no explicit guidance on when to use it versus the sibling review_patch, nor any conditions for when it should not be used. The intended context (content moderation) is implicit, but an agent would have to infer when this tool is the right choice relative to alternatives.

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. 2 tool updatesv0.1.0
    • First observedreview_patch
    • First observedscreen_content
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored across 2 tools

Disambiguation5/5

review_patch and screen_content operate on entirely different inputs (git diffs vs. text) and produce different domain-specific verdicts. There is no realistic ambiguity about which tool to select for a given task.

Naming Consistency5/5

Both tool names follow the same lowercase verb_noun pattern: review_patch and screen_content. The naming is concise, predictable, and clearly conveys the action being performed.

Tool Count3/5

Two tools is at the low end of acceptable for an MCP server. Each tool is substantive, but the server feels thin for something labeled a 'domain' MCP and would benefit from additional related decision gates.

Completeness3/5

The two exposed gates are self-contained for their specific inputs, but the broader Jev decision-model domain is not fully mapped. There are no tools for configuration, audit feedback, or other content types, which could be notable gaps depending on the intended use.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers