General Decision MCP

jev_classify

Read-only

Classify supplied items into bounded, caller-defined classes, with an investigate option for uncertain cases. Returns advisory results only and never grants authorization or executes actions.

Instructions

Classify supplied items into bounded caller-defined classes, with an unavoidable investigate option. 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": {
      "purpose": "<purpose>",
      "items": "<items>",
      "classes": "<classes>"
    },
    "name": "jev_classify"
  }
}

Input Schema

Name	Required	Description
`items`	Yes
`scope`	No	Known consequence scope; omitted means unknown and requires human review.
`classes`	Yes
`purpose`	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.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true and idempotentHint=false, so safety is largely covered; the description reinforces this with 'never grants authorization or executes actions'. However it never explains what the 'unavoidable investigate option' actually does, nor why a read-only classifier is non-idempotent, which is the behavior an agent most needs disclosed.

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 tight sentences with the operative constraint front-loaded and no filler, but the second clause about the 'investigate option' spends words on something never made concrete, so brevity comes at the cost of comprehension.

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

Completeness2/5

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

An output schema exists, so return values need not be explained, but for a 5-parameter classifier with enum scope and attestation flags, the description leaves the investigate behavior, the classes constraint, and the meaning of evidence_complete entirely to the schema. The advisory framing helps but does not fill the gaps.

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 40%, so the description should compensate but does not: it never mentions scope (local/production/security/external/unknown), evidence_complete attestation, or the purpose parameter, and the classes minimum of 2 is undocumented. It also references an 'investigate' option that has no corresponding parameter, which could mislead an agent mapping description to schema.

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?

States a specific verb and resource: classify supplied items into caller-defined classes, bounded in count, and adds the scope boundary 'advisory only; never grants authorization or executes actions'. That distinguishes it from action-taking siblings like jev_gate or jev_verify, though 'unavoidable investigate option' is introduced without definition, leaving part of the core behavior opaque.

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 'advisory only' and by the existence of a caller-supplied class set, but there is no explicit when-to-use versus siblings such as jev_rank or jev_screen, and no stated preconditions or exclusions beyond the advisory disclaimer.

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

Deploy Server