jev

Overview Schema Source Related Servers Discussions Admin

Find the lines that answer a question

jev_locate

Read-onlyIdempotent

Find which lines of a large file answer your questions. Returns ranked line numbers and a probability the file contains the answer, judging lines in context and batching many questions in one pass.

Instructions

Find which lines of a large file (a log, a long doc, a big source file) answer or address a question, without reading the file yourself. Returns line numbers only, ranked, plus the probability the file answers the question at all. Jev reads the lines in windows of up to 254 with their neighbours, so each line is judged in context. Then open just the returned line ranges. Across a whole directory, use jev_search. Pass every question you have about the file in one call: the file is read once for all of them.

Input Schema

TableJSON Schema

Name	Required	Description
`top`	No	How many lines to return per question.
`path`	No	A file read inside the server. Same rules as jev_triage paths. Supply exactly one of path or text.
`text`	No	The content, when you already hold it.
`questions`	Yes	Every question you have about this text, each stated in full (up to 16). They are judged in one pass over the same text, so extra questions cost almost nothing: batch them rather than calling again. Questions cannot see each other's answers.
`no_at_or_below`	No	Probability at or below which a check's verdict is 'no'. Default 0.3. Between the two the verdict is 'uncertain'.
`yes_at_or_above`	No	Probability at or above which a check's verdict is 'yes'. Default 0.7.

Output Schema

TableJSON Schema

Name	Required	Description
`file`	No
`model`	Yes
`usage`	Yes
`results`	Yes	One per question, in the order asked.
`windows`	Yes
`latency_ms`	Yes	Wall-clock milliseconds for the API round trip, for your own calibration logs.
`thresholds`	Yes
`lines_considered`	Yes	Non-empty lines judged.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.14.0Sep 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (read-only, idempotent), it discloses how the tool works: reading in windows of up to 254 lines with neighbours so line judgments have context, returning ranked line numbers plus a probability, and reading the file once per call. This gives an agent accurate expectations of cost, output, and processing behavior.

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?

Six short sentences, front-loaded with purpose, followed by output, behavior, and usage guidance. Every sentence earns its place, and there is no filler or repetition of structured data.

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?

With a rich 100% schema coverage, an output schema present, and a description that explains output, algorithm, and the relevant sibling alternative, an agent has enough to call the tool correctly. Return-shape details are covered by the output schema.

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 applies; the description does not add parameter-level details beyond the schema. The batching advice for questions mirrors what the schema already documents, so the description adds no additional parameter semantics.

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 names a specific action and resource: finding lines of a large file that answer a question, and specifies the return scope (ranked line numbers plus an overall probability). It clearly distinguishes itself from the sibling jev_search by noting the file-level vs directory-level use case.

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?

Explicitly says to use jev_search across a whole directory, establishing the main alternative. It also gives when-to-use context ('without reading the file yourself') and batching guidance ('pass every question... one call'), so an agent knows how to invoke it efficiently.

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

Deploy Server