Skip to main content
Glama

infer_imports

Read-only

Infers static import edges across TS/JS, Python, Rust, and Go files, then diffs them against vault depends_on relations to surface missing or stale edges for review.

Instructions

R17 (autonomous ingest deeper) — walk TS/JS files in a code repo and infer file-level + module-level import edges. It also walks bounded root Python packages, bounded src/source-layout Python packages, and deterministic Rust use/file-module/literal-include dependencies. A valid root Go module additionally exposes typed local package-import evidence; it stays separate from legacy file edges and never self-approves a semantic relation. Structured coverage names the supported languages; Rust support is bounded static text evidence and does not expand macros, evaluate cfg, resolve symbols, or prove runtime impact. side effect 0 (vault frontmatter NOT modified). moduleEdges are source-backed review candidates, never self-approving semantic depends_on relations. When you know an implementation file, set focusPath (or reviewMode:"focus") before considering full: Atlas returns bounded exact incoming/outgoing static import receipts, counts, and a cursor without requiring a vault. This focused source boundary is not runtime impact or a semantic relation. Omit reviewMode for size-safe automatic delivery: scans whose estimated full MCP result is at most 128 KiB keep the complete response; larger reconciled scans return exactly one compact, non-writing nextRelationReview:v1 packet plus a delivery receipt and stateless cursor. Use reviewMode:"next" to request that bounded packet explicitly. reviewMode:"full" preserves the complete shape, but a result over 128 KiB additionally requires allowLargeResponse:true; this second confirmation prevents coding agents from accidentally opting into a multi-megabyte response. Oversized raw scans without a loadable reconciliation vault fail with an actionable error instead of emitting an unbounded default response. Every compact candidate carries absentEndpoints. If an endpoint is missing, nextCalls is empty and endpointModelling separates an evidence-only analysis call from the complete rootPath + proposal validation contract, source-bound drafts, and queue resume. It never calls get_concepts or relation_check on a missing slug, never claims the analysis call created an endpoint, and never promotes a path-derived slug into a business kind or definition. Each module edge includes whole-edge source-role/import-usage counts, productValueCount, kindCounts, and a bounded exact file-edge evidence receipt. Missing vault edges remain rationale_review_required: inspect both concepts and the observed direction, ask the user, then call add_relation with an explicit why. Test-only or type-only evidence stays visible but must not be framed as a product depends_on approval question without separate product meaning evidence. Detects:

  • relative imports (./, ../) → resolved to file paths

  • dynamic import() / require() / export ... from

  • bare side-effect imports (import "X")

  • apps/* and packages/* workspace imports collapse to analyzer-compatible element slugs

  • bounded static Python import / from ... import statements in root or src/source-layout packages with init.py; imports nested under an explicit TYPE_CHECKING guard are type_only; source is parsed as text and never executed

  • external package imports listed separately

  • tsconfig.json compilerOptions.paths aliases first, then fallback common @/* aliases → resolved to internal files when the target exists; otherwise unresolved as alias-not-found

Use after analyze_repo_structure to pull real dependency edges from the code, not just suggestedRelations heuristics. Unless reconcile:false, also returns reconciliation (+ reconciliationSummary counts): the module edges diffed against the vault's compiled depends_on edges into inBoth / review-required missing edges / inVaultNotInCode (possibly-stale vault edges). Missing edges carry source evidence and a rationale_review_required gate, never a write action. Single source of truth preserved — inspect both concepts, explain why the semantic dependency holds, and ask the user before one explicit add_relation call with why.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ignoreNoExtra folder names to skip (added to defaults: node_modules, dist, build, …).
maxFilesNoPositive integer cap on files walked (default 5000, max 50000). Hard stop to avoid pathological monorepos.
rootPathNoRepository root to analyze. Defaults to the active resolved repository root from connection_info.
focusPathNoRepository-relative implementation file to inspect. Supplying focusPath with omitted reviewMode selects focus mode automatically. Returns bounded incoming/outgoing supported static import receipts; it does not claim runtime or semantic impact.
reconcileNoDefault true. When true, diff the inferred module edges against the vault's compiled depends_on edges and include `reconciliation` + `reconciliationSummary`. Set false to skip (raw scan only / no vault).
focusLimitNoFocus mode only. Maximum exact import receipts returned in one page (default 50, max 100).
reviewModeNoOmit for automatic delivery unless focusPath is present. `focus` returns a bounded exact file-level import neighborhood for focusPath. Otherwise responses estimated at or below 128 KiB keep the complete scan, while larger reconciled scans return one compact, non-writing review packet. `full` requests the complete scan; when it exceeds 128 KiB, also pass allowLargeResponse:true. `next` explicitly requests one compact packet and requires reconciliation.
afterReviewIdNo`reviewMode:"next"` only. Pass the prior packet cursor.nextAfterReviewId to advance deterministically; omit to start at the first current candidate.
sourceFoldersNoSource folders to walk (default: ['src','source','lib','app','apps','packages']). Nested scopes preserve repository-relative ontology endpoints. If none exist, falls back to rootPath.
focusDirectionNoFocus mode only. Which exact file-level import direction to page (default both).
focusAfterEdgeIdNoFocus mode only. Pass the prior focusReview.cursor.nextAfterEdgeId to advance deterministically; omit to start at the first current edge.
allowLargeResponseNoConfirmation for reviewMode:"full" only. Required when the estimated complete MCP result exceeds 128 KiB. It never changes scan contents or writes the vault.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
edgesNo
contractNo
coverageYes
deliveryNoPresent only when omitted reviewMode was automatically compacted because the estimated full MCP result exceeded the safe delivery boundary.
rootPathYes
nextReviewNo
unresolvedNo
focusReviewNo
moduleEdgesNo
reviewQueueNo
scanSummaryNo
filesScannedYes
reconciliationNoModule edges diffed against the vault's compiled depends_on edges (alias-normalized). null when no vault is loadable (e.g. scanning a foreign repo). Absent when reconcile:false.
externalImportsNo
staleEdgeFollowUpNo
packageImportEvidenceNoRoot Go module-only, bounded package import evidence. It is observed static source evidence, never a runtime claim or semantic relation approval.
reconciliationSummaryNo
packageImportEvidenceSummaryNoBounded Go package-import census. Call fullEvidenceCall to retrieve the complete typed receipt; focusReview itself contains legacy file edges only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnlyHint=true and destructiveHint=false annotations, the description explicitly states side effect 0 (vault frontmatter NOT modified), that it never performs write actions, never self-approves semantic depends_on relations, never executes source code, and does not expand macros or evaluate cfg for Rust. It also discloses failure behavior for oversized scans without a reconciliation vault, which is valuable behavioral context not present in annotations.

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

Conciseness2/5

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

The description is an extremely long, dense wall of text that repeats several key ideas multiple times (never self-approving, never a write action, source-backed review candidates). It contains a useful bulleted list of detected import types, but overall the structure is not front-loaded and would be hard for an agent to parse quickly. Significant trimming and sectioning could preserve the same information with much less noise.

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?

Given the tool's complexity, the description is remarkably complete. It covers supported languages, import detection variants, mode behavior, response size limits, reconciliation semantics, missing-edge handling, and write-safety guarantees. An output schema exists, and even though the description explains return details more than necessary, it does not leave critical gaps for an agent attempting to select or invoke the tool 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?

The input schema already covers all 12 parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantic context beyond the schema: it explains the automatic vs. focus vs. next delivery model, when allowLargeResponse is required, how focusPath interacts with reviewMode, and what reconcile:false skips. This is more than the schema alone provides, though some per-parameter semantics are still left to the schema.

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 and resource: walk TS/JS files and infer file-level and module-level import edges, plus Python/Rust/Go variants. It clearly distinguishes itself from analyze_repo_structure by calling out that it produces real dependency edges rather than suggestedRelations heuristics, and it names related tools like add_relation and get_concepts to clarify what it is not.

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?

The description explicitly says to use this tool after analyze_repo_structurecreates a clear workflow position. It also explains when to set focusPath, when to omit reviewMode, when to use reviewMode:"next" or "full", and what to do when vault edges are missing (inspect concepts, ask user, then call add_relation). It does not exhaustively enumerate all sibling alternatives, but provides strong practical guidance for the main decision points.

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