Skip to main content
Glama

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 agent

One 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-mcp

Set 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.py is 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.

Setup & reference · Reproduce the benchmarks · Development

MIT license · Download v0.1.0 · Local release checks

Available Tools

1 tool
decideA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
itemsNo
sourceNo
contextNo
criteriaYes
questionYes
concurrencyNo
review_limitNo
review_labelsNo
confidence_thresholdNo
confidence_thresholdsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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. 1 tool updatev0.1.0
    • First observeddecide

TDQS

A4.2/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    Enables 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.
    7
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    Enables 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.
    1
    MIT
  • A
    license
    B
    quality
    B
    maintenance
    Enables 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.
    5
    MIT