Skip to main content
Glama

Jev find files

jev_find_files
Read-only

Find the files that implement a behavior you describe in plain words, ranked by relevance. Use it when you do not know file names or exact identifiers and need a starting point in unfamiliar code.

Instructions

Find the files for a goal you describe in plain words, ranked; known names → your file-name search tool, known strings → your text search tool. Use for: starting a task in unfamiliar code ("where is proration computed", "what handles webhook retries") when you do not know file names or exact identifiers. Not for: known strings, regexes or symbols → your text search tool. Files by name → your file-name search tool. Questions about files you already have → jev_ask_files.

How Jev sees it: names first, then a short passage of the best candidates — never whole files. Write the goal as one behavior sentence of at least 5 words (shorter goals are capped at unsure); prefer a full sentence of behavior over a few keywords. Put identifiers you already know in keywords, where they steer the pre-filter and the passage Jev reads. Jev cannot count or grep.

goal: what you are trying to do or find, as one sentence of at least 5 words. Describe behavior, not a guessed identifier: in our tests a full sentence found the right file in 49 of 51 cases, two or three keywords alone in 16 of 21. keywords: identifiers or terms you already know that should appear in the code; [] if none. They steer the pre-filter and the passage Jev reads. scope: directories to search instead of the whole repo. An empty scope produces no judgment; a judged "none" means no supplied candidate fit, not proof about unseen files. exclude: globs to skip. Excluding tests keeps the entry point but drops the tests and docs from the list. effort: quick searches fewer candidates for a first look, default, thorough searches more (wider net, slower). max_calls: cap on Jev calls; beyond it the search stops at the best-ranked files so far and says so.

Result: the primary entry decision names the file to open with its actual probability and fresh/cache provenance; auxiliary rankings, controls and native read actions remain distinct. Unsure means two files are plausible, the answer depends on candidate order or the goal is short: read the leading candidates. A judged none means nothing supplied fit: inspect the goal or admitted scope before deciding the next action. Empty collection or missing responses are unjudged, never synthetic none probabilities. A goal under 5 content words is capped at unsure. You receive paths and scores, never file contents. Typed diagnostics name limits, omissions and useful next actions. The reading guide defines every mark once.

Use Jev for a bounded semantic judgment when its answer could change an open decision or focus the next inspection, and the relevant evidence is available. Use decisive reading, search or authorized execution directly when it settles the question. Exact lookup, counting and runtime causality belong to native tools. A Jev call is not a prerequisite for a conclusion, a review or task completion; no explanation is needed for choosing native tools.

After an unavailable, refused or out-of-scope result, continue natively within the existing permissions; do not widen sharing or confinement to obtain a judgment. For uncertainty or missing evidence, inspect or obtain the decisive piece, or leave the conclusion open. Revisit Jev only when new evidence, a material context change or a new useful question makes the judgment useful; rewording unchanged evidence is not a reason to retry. There is no retry quota for genuinely changed evidence, and no certification is needed once decisive evidence settles the question. A reached cap or an unjudged result is not evidence of safety or zero affected tests.

Input Schema

NameRequiredDescriptionDefault
goalYes
rootNo
scopeNo
effortNo
excludeNo
keywordsNo
max_callsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already establish read-only, non-destructive, open-world, non-idempotent, but the description adds substantial behavior the annotations cannot: paths and scores only, never file contents; "names first, then a short passage"; fresh vs cache provenance; max_calls truncation behavior; empty collection or missing responses are unjudged rather than synthetic "none"; and a sub-5-word goal is capped at unsure. Retry policy after unavailable/refused results is also spelled out.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loading is excellent — purpose, then use/not-for, then mechanics. But the text is roughly 450 words for a file-finder and repeats itself: the ≥5-word goal rule is stated three times, the uncertain/unsure capping twice, and the unjudged-vs-none distinction twice. The trailing retry/policy paragraph is largely generic doctrine that a per-tool definition need not carry.

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?

With an output schema present the description need not enumerate return fields, yet it still explains what the primary entry decision contains and how diagnostics read. Annotations cover safety. What is left is `root` (undocumented) and some redundancy rather than missing guidance; an agent has everything it needs to call this correctly.

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

Parameters4/5

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

Schema description coverage is 0% across 7 parameters, so the description carries the load and mostly does: goal (one behavior sentence, ≥5 words, with test evidence), keywords (steer pre-filter and passage), scope (empty scope yields no judgment; a judged "none" is not proof about unseen files), exclude (globs, excluding tests keeps the entry point), effort (quick/default/thorough trade-off), max_calls (cap behavior). The `root` parameter is not mentioned anywhere, leaving one gap.

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?

Opens with a specific verb and resource: "Find the files for a goal you describe in plain words, ranked." It immediately contrasts itself with the file-name search tool and the text search tool, and names jev_ask_files for questions about files already held, so an agent can place it among siblings without reading a schema.

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?

Explicit "Use for" / "Not for" blocks name the alternatives (text search for strings/regex/symbols, file-name search for names, jev_ask_files for existing files) and give concrete starting-a-task scenarios. It goes further with a general decision rule — use Jev only when a semantic judgment could change an open decision, otherwise use decisive native reading/search — and states that a Jev call is never a prerequisite for a conclusion.

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