General Decision MCP

jev_decide

Read-only

Chooses among 2–6 bounded alternatives using supplied evidence and priorities, checks requirements, and returns advisory guidance without authorizing or executing actions.

Instructions

Choose among 2–6 bounded alternatives using supplied evidence and priorities, with fixed escape options and independent requirement checks. Advisory only; never grants authorization or executes actions.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "decision": "<decision>",
      "evidence": "<evidence>",
      "priorities": "<priorities>",
      "candidates": "<candidates>"
    },
    "name": "jev_decide"
  }
}

Input Schema

Name	Required	Description
`scope`	No	Known consequence scope; omitted means unknown and requires human review.
`decision`	Yes
`evidence`	Yes
`candidates`	Yes
`priorities`	Yes
`requirements`	No
`evidence_complete`	No	Caller attests supplied evidence is complete; omitted means incomplete. Not independent verification.

Output Schema

Name	Required	Description	Default
`tool`	Yes
`error`	No
`model`	Yes
`usage`	Yes
`policy`	Yes
`status`	Yes
`answers`	Yes
`summary`	Yes
`evidence`	Yes
`provider`	Yes
`schema_version`	Yes
`requested_model`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Beyond the annotations, the description adds that the tool is advisory only, never authorizes or executes actions, uses fixed escape options, and performs independent requirement checks. These are meaningful behavioral traits for an agent. It does not describe rate limits or detailed failure behavior, but the annotations already cover safety hints.

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 tightly written sentences with the core action and safety boundary front-loaded. There is no unnecessary wording, and every clause contributes useful information.

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

Completeness3/5

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

The description covers the tool's central choice function and its advisory safety boundary, and an output schema exists so return values need not be explained. Still, for a 7-parameter decision tool with low schema coverage, it leaves important gaps around when to use it and how fields such as decision, scope, and evidence_complete should be interpreted.

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?

The description mentions evidence, priorities, bounded candidates, and requirement checks, and the 2–6 bound adds meaning beyond the candidates schema. However, with only 29% schema description coverage, it does not explain the decision field's intended content or adequately compensate for the missing scope and evidence_complete semantics.

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 states a specific action: choosing among 2–6 bounded alternatives using supplied evidence and priorities. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as jev_rank or jev_gate.

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 advisory-only boundary ('never grants authorization or executes actions') gives useful when-not-to-use guidance. However, the description does not say when to prefer this tool over alternatives like jev_rank, jev_review, or jev_gate, leaving usage selection implied.

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

Deploy Server