Skip to main content
Glama

jev_route

Read-only

Recommends a suitable Unreal tool for a goal, using optional candidate lists from other servers. Defers when no reliable match exists.

Instructions

Recommend one candidate tool or defer. Sends supplied goal/candidates to Jev.

Omit candidates for built-in Unreal workflows. Supply a shortlist from another Unreal or future Blender MCP server to route its tools without loading every schema into the agent. Missing/low confidence defers. Thresholds are initial defaults, not accuracy claims.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYes
candidatesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already mark the tool as read-only, open-world, and non-destructive; the description adds that it defers when confidence is missing/low and that thresholds are 'initial defaults, not accuracy claims.' This is extra behavioral context and does not contradict the annotations.

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 five short sentences with the core behavior front-loaded. Each sentence adds operational detail, though 'Thresholds are initial defaults...' reads as a caveat that could be folded into the deferral statement.

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 two-parameter routing tool, the description covers purpose, candidate nullability/omission, external-server shortlisting, and deferral behavior; the output schema covers return values. It is slightly incomplete only in not distinguishing this from jev_decide/jev_triage as a routing path.

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?

With 0% schema description coverage, the description must carry parameter meaning. It explains goal/candidates as a pair sent to Jev and when candidates should be omitted vs supplied, but it does not define the expected goal format or the Candidate id/description fields beyond what the schema's type/constraints show.

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 ('Recommend one candidate tool or defer') and identifies the resource (the supplied goal/candidates sent to Jev). It doesn't explicitly contrast with similarly named siblings like jev_decide or jev_triage, so it falls short of a 5.

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?

It gives concrete usage rules: omit candidates for built-in Unreal workflows, and supply a shortlist from another Unreal or future Blender MCP server to avoid loading every schema. 'Missing/low confidence defers' also says when the tool should fall back. It does not name alternative sibling tools, so it is explicit but not fully comparative.

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