Skip to main content
Glama

Predict the most likely runtime failure in a file

predict_failures

Identifies the most likely runtime failure in JS/TS code, returning line and reason from an independent model review. Flags only actionable defects, clarifying uncertain or clean results.

Instructions

Combine static analysis with a second-opinion verdict from the signed-in Claude Code, Codex, or GitHub Copilot CLI, returning the most likely runtime failure with a line number and reason. status distinguishes actionable, uncertain, no-finding, and unavailable results. checked lists the bug categories the model reports having considered, so a clean file weighed against the whole catalogue is distinguishable from one where it stopped early; it is a self-report, and an empty list means no coverage was reported. Pass multi: true to get every finding the model can demonstrate, ranked, in a findings array instead of one verdict — experimental, and more findings per call is also more surface for false positives per call. Treat it as a defect only when actionable is true; that applies the measured score >= 0.7 precision gate. This spawns another model and takes 5-15 seconds, so only call it when you specifically want an independent second opinion. If you are yourself reviewing the code, use analyze_file and read the source instead. Reviewing several files? Pass them all as files in one call rather than calling once per file: the verdicts run concurrently, so the batch costs the same and takes about as long as a single file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNoAbsolute path to a .js/.jsx/.ts/.tsx file
filesNoAbsolute paths to review in one call, run concurrently. Prefer this over one call per file when checking a change set: the verdicts are independent, so a batch bills the same as the same files one at a time but finishes in roughly the time of the slowest one. Replies carry a `results` array in the order given. Supersedes `file`.
modelNoModel override passed to the CLI
multiNoReturn every finding the model can demonstrate, ranked by score, rather than the single most likely one (default false). Experimental: the precision gate was measured on one-finding replies, so `actionable` is less well characterised here.
logFileNoOptional log file to fold into the combined score
verboseNoInclude the static metric counts and the full log breakdown (default false)
providerNoWhich CLI to ask (default: whichever is installed)
concurrencyNoVerdicts in flight at once for a batch (default 4). Lower it if the provider starts rate-limiting.
calleeContextNoAlso send bounded imported definitions and referenced type contracts so the model can check dependency behavior (default true). Turning this off reduces input tokens but removes that evidence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.2

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and fully discloses behavior: it spawns another model and takes 5-15 seconds, `checked` is a self-report (empty means no coverage), and `actionable` gates on a 0.7 precision gate. It also flags `multi` as experimental and notes that more findings increase false-positive surface. This is exceptional transparency.

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 longer than typical but highly structured: core purpose first, then output semantics, then usage guidance and batching tips. Every sentence adds unique information, though it could be tightened slightly without losing substance. It's efficient but borderline verbose.

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?

For a complex tool with 9 parameters, no output schema, and heavy reliance on external model calls, the description covers all essential aspects: what it returns (status, checked, actionable), how to interpret `actionable` (precision gate), performance (5-15 seconds), batching behavior, and alternatives. Nothing an agent needs is missing.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant semantics beyond auto-generated docs. It explains the `file` vs `files` relationship (files supersedes file, concurrency), the trade-offs of `multi` (experimental, precision gate less characterized), and `concurrency` usage for rate-limiting. This enriches parameter meaning substantially.

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 states a specific verb ('predict'), a defined resource ('most likely runtime failure with a line number and reason'), and a distinguishing mechanism ('second-opinion verdict from Claude Code, Codex, or GitHub Copilot CLI'). It clearly differentiates from siblings like analyze_file, which reviews code directly rather than via an external model.

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 guidance is given: only call for an independent second opinion, and 'If you are yourself reviewing the code, use analyze_file and read the source instead.' It also advises batching multiple files into one call versus per-file calls, and discloses that a batch costs the same. This directly addresses when and when not to use the tool relative to alternatives.

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