General Decision MCP

jev_risk

Read-only

Assess bounded infrastructure changes and flag required human-review floors for security or unknown facts, returning advisory risk signals only; no authorization or execution.

Instructions

Assess bounded infrastructure changes with deterministic human-review floors for security and unknown facts. 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": {
      "request": "<request>",
      "change": "<change>",
      "change_type": "<change_type>",
      "environment": "<environment>",
      "evidence": "<evidence>"
    },
    "name": "jev_risk"
  }
}

Input Schema

Name	Required	Description
`facts`	No
`scope`	No	Known consequence scope; omitted means unknown and requires human review.
`change`	Yes
`request`	Yes
`evidence`	Yes	Supplied text only; no files or URLs are fetched.
`change_type`	Yes
`environment`	Yes
`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

B3.4/5.0

Behavior4/5

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

Annotations already cover the read-only, non-destructive profile, and the description adds genuinely new behavior: assessment is deterministic, human-review floors are applied for security and unknown facts, and the tool never grants authorization or executes actions. That is meaningful beyond the structured hints, though it doesn't state response shape, timing, or what a "floor" means in output terms (the output schema carries that).

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?

Two sentences, no filler, and the core purpose is front-loaded before the advisory caveat. The phrase "deterministic human-review floors for security and unknown facts" is dense internal jargon that costs a little parsing, but nothing is redundant.

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 output schema is present and annotations cover safety, so return values need not be described. However, for an eight-parameter tool with a nested facts object and five required fields, the description leaves the agent without guidance on what "bounded" operationally means or how the attributes it cites map onto the inputs, and it never distinguishes this from the decision/gate/review siblings.

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

Parameters2/5

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

Schema description coverage is only 38%: the seven booleans in the nested facts object, plus change, change_type, environment, and request, carry no schema descriptions. The description gestures at concepts ("bounded", "security", "unknown facts") that vaguely map to broad_change/irreversible and to an omitted scope, but it never explains any parameter, its required/optional status, or how evidence differs from evidence_complete. It does not compensate for the coverage gap.

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?

"Assess bounded infrastructure changes" names a specific verb and resource, and the second sentence clarifies the tool is an advisory assessor rather than an enforcement point. It does not name or distinguish itself from plausible siblings such as jev_gate or jev_classify, so an agent must infer the boundary from the adjective "bounded" rather than an explicit contrast.

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?

Usage is implied by "bounded infrastructure changes" and by the note that it is advisory only, but there is no explicit when-to-use statement, no exclusion, and no mention of prerequisites or of which sibling to call instead when a decision or gate is actually needed. The agent must reconstruct the routing rule itself.

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

Deploy Server