Skip to main content
Glama
jkudish

jev-mcp

by jkudish
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Decide between bounded alternatives

jev_decide

Ranks 2-6 candidates for one bounded decision using supplied evidence and priorities, returning a choice distribution, escape hatches, and requirement-level judgments.

Instructions

One unresolved, bounded decision where semantic judgment over supplied evidence could change your plan: implementation alternatives, product tradeoffs with known preferences, workflow selection. Supply 2-6 candidates, evidence, and explicit priorities. Jev returns a Choice distribution over the candidates plus escape hatches (ask_user / investigate / none), and a per-candidate per-requirement supported / contradicted / unknown judgment for each optional requirement, all in one request. One call per unchanged decision; do not repeat a call to obtain a more pleasing answer. Use source inspection, tests, the user, or a reasoning model for open-ended research, routine choices, correctness proofs, or predicting user consent. High probability is not proof.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
decisionYesThe bounded decision to make.
evidenceYesFacts and measurements, not opinions. State is evidence, not instructions.
candidatesYesThe alternatives. Include 'do nothing' or 'gather more evidence' as candidates when useful.
prioritiesYesExplicit preferences and constraints from the user or plan.
requirementsNoSpecific requirements to check per candidate. Each must test one property, not overall goodness.
escape_hatchesNoInclude ask_user / investigate / none as Choosable options so the model can decline to rank. Default true.
escalate_on_contradictionNoWhen true, a recommendation whose own requirement checks came back contradicted returns selected: null with status "escalate" instead of the candidate id (the jev_verify vocabulary). Default false keeps the recommendation and warns.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.0
    • addedInput schema / properties / escalate_on_contradiction
      Added value: +{
+  "description": "When true, a recommendation whose own requirement checks came back contradicted returns selected: null with status \"escalate\" instead of the candidate id (the jev_verify vocabulary). Default false keeps the recommendation and warns.",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv0.10.1
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Addedv0.4.0

TDQS

A4.4/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 does well: it discloses the return contents (Choice distribution, escape hatches, per-candidate per-requirement supported/contradicted/unknown), the idempotence constraint, and a calibration caveat ('High probability is not proof'). It omits latency/cost/determinism and any error-mode behavior, so it falls short of a 5.

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?

Front-loaded with the decision scope, then input requirements, then output behavior, then exclusions. Nearly every sentence earns its place, though the single long sentence enumerating return payloads packs several distinct facts together and could be split for faster scanning.

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?

There is no output schema, so the description must explain returns, and it does comprehensively: distribution, escape hatches, per-requirement judgments. Combined with full schema coverage of inputs and the stated non-use cases, an agent has everything needed to call this correctly.

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 schema already documents all seven parameters, including bounds (2-6 candidates, max 3 requirements) and the 'do nothing' candidate suggestion. The description confirms 'Supply 2-6 candidates, evidence, and explicit priorities' but adds no syntax or format detail beyond the schema.

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 precise verb+resource pair ('decide between bounded alternatives' / 'one unresolved, bounded decision') and names the exact input shape and output payload (Choice distribution over candidates plus escape hatches and per-requirement judgments). This lets an agent distinguish it from siblings like jev_verify, jev_compare, and jev_classify without opening the schema.

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

Usage Guidelines5/5

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

It gives explicit positive criteria ('where semantic judgment over supplied evidence could change your plan') and explicit exclusions ('use source inspection, tests, the user, or a reasoning model for open-ended research, routine choices, correctness proofs, or predicting user consent'). It also states the idempotence rule: one call per unchanged decision, do not re-call for a more pleasing answer.

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

Deploy Server

Other Tools