decide
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., "@decideFind feature requests in these 500 app reviews"
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.
decide
Your agent reasons. Jev sorts.
Bulk decisions for Claude and Codex. Keep the pile out of your agent’s context.
Get started · Workflows & benchmarks · Tool reference · All evaluations
A backlog of issues. Hundreds of product reviews. A wall of logs. Your agent needs to decide what matters before it can do useful work.
Give it a path and a rubric. decide sends each record to
Jev, saves the decisions locally, and
returns a compact summary plus a review queue. Your agent can inspect the
exceptions and use scripts to act on the rest.
You: “Find feature requests in these 500 app reviews.”
│
Claude / Codex defines the criteria and passes the file path
│
decide → Jev
│
┌────────────────┴────────────────┐
Accepted decisions Needs a closer look
results.jsonl review.jsonl
Process with code Review with your agentOne MCP tool. One server file. Your rubric, your data. Works with UTF-8 files, log lines, JSONL records, or inline items.
Put it to work
You are… | Give decide this job | What you get |
A UX researcher | Extract reports of product failures from app reviews | Candidate friction points and uncertain cases to inspect before deeper research |
A product manager | Separate feature requests, bugs and general feedback | Signals to feed discovery and the backlog; use separate questions for overlapping labels |
A developer | Sort incoming issues into bugs, features and questions | Structured labels for automation and a queue for ambiguous reports |
In support | Route customer messages into your team's intent taxonomy | A routing file and messages requiring judgment |
On call | Categorize log events and always escalate urgent labels | An investigation queue; group multiline events first |
These are sorting jobs. UX synthesis, prioritization, incident diagnosis and code
changes still need judgment. decide produces labels; it never executes them.
Related MCP server: Jev MCP
Measured against GPT-4.1 mini
Cut the bill while protecting the quality your task needs. On 1,000 new UX reviews, the selected policy improved all four frozen quality metrics and reduced total inference cost by 48.9%.
UX feature-request extraction | mini alone | decide + mini |
Accuracy | 84.2% | 90.2% |
Macro-F1 | 0.7803 | 0.8577 |
Precision | 58.4% | 72.0% |
Recall | 76.8% | 84.7% |
Complete tool-loop cost | $0.04993 | $0.02551 |
Mini input tokens across all turns | 92,167 | 14,228 |
Jev handled the whole file. Mini checked 123 uncertain negative answers; valid positive answers stayed with Jev. The cutoff was selected on older data and committed before these 1,000 exact-disjoint reviews were sent to either model. Both agents wrote complete output files and verified every input ID.
New UX records, frozen policy, all mistakes and reproduction →
The cost includes reading data, real MCP, retained history, writing results and the final answer, plus both providers. Both arms discard completed batches. This is a guided workflow with host-enforced completion, not a native Codex/Claude session. Results are observed sample comparisons, not a future quality guarantee or proof of the globally cheapest policy.
Developer workflow: on 300 OpenCV issues, an error-only fallback policy cut tool-loop cost 77.3% and raised accuracy from 68.0% to 74.7%, with higher macro-F1. Feature-label recall fell, so that policy suits a different quality tradeoff. Developer results and class metrics →
Less review is not the goal. The earlier UX policy was cheaper but missed more feature requests. The new policy spends more on review and recovers that recall. The nine-task comparison also includes jobs where mini preserves quality better and where review makes results worse. An agent stopping before the job was done remains published too.
The workflow study covers 3,500 Jev decisions on UX feedback and issues from five projects. The earlier evaluations cover another 8,340 records across ten tasks. Reference labels, predictions, failures and baselines are published throughout.
Review rate is an outcome, not a quota. Choose the greatest savings your task's quality allows; there is no universal “only review 5%” setting.
Get started
You need uv, Git and a TypeSafe API key. No clone required.
Connect Codex or Claude Code / Desktop with this MCP launch command:
uvx --python 3.11 --from git+https://github.com/alsoleg89/decide@v0.1.0 decide-mcpSet TYPESAFE_API_KEY in the server environment and DECIDE_ROOT to the
folder containing your data. The client launches the stdio server; the first
launch installs dependencies, then uvx reuses its cache.
Local checkout and installation check →
Then ask your agent:
Use decide on feedback.jsonl to find feature requests. Pass the file path directly without reading the whole file first. Use yes/no criteria with a global confidence threshold of 0 and a threshold of 0.9 for no. Read every case in the review queue and save one final decision per input ID. Verify complete coverage before reporting success.
Each JSONL row needs an ID and content:
{"id":"review-1","content":"Please let me export my workout history as CSV."}
{"id":"review-2","content":"The app closes every time I open the activity screen."}{
"question": "Does this app review request a new or changed capability?",
"criteria": {
"yes": "Requests a new or changed function, content, interface, or capability",
"no": "Does not request a new or changed capability"
},
"source": {"kind": "jsonl", "paths": ["feedback.jsonl"]},
"confidence_threshold": 0,
"confidence_thresholds": {"no": 0.9}
}This reproduces the routing from the new UX validation: accept valid positive answers, review uncertain negatives and errors. Validate it on your own labeled sample; a confidence cutoff does not guarantee accuracy.
Small context. Full audit trail.
The default response contains counts and file paths, with no input previews.
Every decision, confidence, probability distribution and provider error stays
in results.jsonl. Every case needing review keeps its full original input
in review.jsonl. Both live under DECIDE_ROOT/.decide/<run-id>/.
Read from disk: files and globs, individual log lines, or JSONL records.
Control escalation: global and per-label confidence cutoffs, plus labels that always need review.
Keep failures visible: invalid responses and oversized items enter the review queue.
Stay inspectable:
decide.pyis the entire production server.
Input content is sent to TypeSafe. Scope source paths accordingly. A confidence score is not a probability of correctness. Limits, retries and data handling →
Try your own workload
The best benchmark is the job you want to delegate. Label a sample and run the real-data evaluator, then compare accepted errors against the bytes and review work saved.
Found a task that works beautifully—or fails badly? Open an issue with the rubric and a small, shareable example. Both belong in the benchmark suite.
Available Tools
1 tooldecideA
Bulk decisions via Jev. Supply either inline {id,content} items or source.
source: {kind: lines|jsonl|files, paths: [...]}, relative to DECIDE_ROOT. lines = one log line per item; jsonl = {id,content} records; files = one UTF-8 file per item, supports globs such as src/**/*.py. No shell commands. criteria maps labels to descriptions. confidence_threshold uses Jev's confidence, NOT selected-label probability. confidence_thresholds overrides the cutoff for specified labels; others use confidence_threshold. review_labels always escalate chosen labels (e.g. other). Returns counts and paths to full JSONL results. Content stays on disk by default; opt into bounded previews with review_limit. Read review_path from the beginning: previews are not completed reviews. Does not execute decisions. All selected content is sent to api.typesafe.ai.
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | ||
| source | No | ||
| context | No | ||
| criteria | Yes | ||
| question | Yes | ||
| concurrency | No | ||
| review_limit | No | ||
| review_labels | No | ||
| confidence_threshold | No | ||
| confidence_thresholds | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing important behaviors: content is sent to api.typesafe.ai, decisions are not executed, content stays on disk by default, and previews are bounded. It also clarifies threshold semantics ('Jev's confidence, NOT selected-label probability') and that review_labels always escalate chosen labels. No contradiction with the annotations exists.
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 dense and mostly front-loaded, with each line adding a distinct behavior or constraint. The line-break organization aids readability. Some statements are cryptic, such as 'Read review_path from the beginning' and the unexplained reference to Jev, but overall the text is compact and purposeful.
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 10 parameters, nested objects, and an output schema, the description covers the most error-prone parts: source formats, globs, threshold semantics, side effects, and preview caveats. It does not provide an overarching example or explain question, context, and concurrency, but those are comparatively self-evident. The key operational warnings are present.
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?
With 0% schema description coverage, the description compensates substantially: it explains items, source kinds, criteria, confidence_threshold, confidence_thresholds, review_labels, and review_limit. However, it omits question, context, and concurrency entirely, and some details like review_path are mentioned without being defined in the schema. Strong but not complete coverage.
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 the vague phrase 'Bulk decisions via Jev,' but the surrounding text clarifies that the tool labels/decides on items according to criteria, applies confidence thresholds, and can read from inline items or source files. It is reasonably clear what the tool does, though an explicit verb like 'classify' or 'evaluate with labels' would sharpen it.
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 explains the two input modes ('Supply either inline {id,content} items or source'), how source kinds differ, and warns against using shell commands. It also advises reading review_path from the beginning because previews are not completed reviews. There are no siblings to distinguish from, so the lack of alternative-selection guidance is acceptable.
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
decide
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion between tools. The single tool's purpose is clearly defined in its description, so an agent cannot misselect among alternatives.
The tool name 'decide' is a single, simple verb with no conflicting conventions. Since there is only one name, there is no inconsistency to evaluate, and it follows a clear imperative style.
The server has exactly one tool, which feels thin for a general-purpose utility. However, the tool itself is quite comprehensive, covering multiple input sources and options, so it is not trivial. The count is on the borderline of being too sparse.
The single tool covers the full decision-making workflow including input handling, criteria, thresholds, and review options. Minor gaps exist such as no dedicated retrieval tool for prior results, but the tool returns paths to full results, making the surface reasonably complete for its stated purpose.
Maintenance
Related MCP Connectors
Verified AI-agent outcomes: secret scanning, JSON cleanup, dedupe, anomaly and schema checks.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
- openhelmOAuthai.openhelm
Autonomous cloud agent tasks: real browser + your tools, structured evidence-backed results.
Deterministic AI agent microtools, no accounts/API keys. fetch_extract: 98% token cut. 38 tools.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI coding agents to receive continuous, structured software-quality feedback from Jev across multiple quality dimensions while working locally.79MIT
- AlicenseAqualityBmaintenanceEnables frontier coding agents to delegate routine probabilistic judgments to TypeSafe Jev, providing calibrated triage signals for failures, attempts, completion, context ranking, findings, risk, and generic evidence-grounded questions.7MIT
- AlicenseAqualityAmaintenanceEnables agents to get fast, calibrated probabilistic answers from Jev (Typesafe AI) to yes/no, scale, or choice questions about provided material, without using a generative model.1MIT
- AlicenseBqualityBmaintenanceEnables coding agents to obtain probabilistic decisions from Jev AI via OpenRouter for classification, scoring, and validation, with tools like jev_check, jev_classify, jev_score, and jev_evaluate.5MIT