Skip to main content
Glama

local_file_scout

Read-onlyIdempotent

Read repository files directly from disk and extract verbatim signatures, imports, and logic with exact line citations to verify disk state before answering or editing.

Instructions

ZERO-TRUST MEMORY TOOL: Read repository files directly from disk on the server side and use the Local GPU LLM (0x cloud quota) as a strict forensic disk-evidence extractor. Outputs verbatim signatures, imports, and logic with exact 1-based <file>:L<line> citations (<300 tokens), or "NOT_FOUND_ON_DISK: [symbol/query]" if absent (automatically escalating to Gemini 3.8 Flash if the local GPU is offline). WHEN TO USE: Always call before raw Read on unfamiliar/large files (>150 lines) or whenever verifying disk state before answering or editing. DO NOT USE FOR: Multi-directory architectural synthesis across 10+ files (use agy_delegate_research after scouting). RETURNS: Concise markdown bullet digest with <file>:L<line> citations and telemetry footer.

Input Schema

NameRequiredDescriptionDefault
cwdNoOptional working directory path (defaults to workspace root).
queryYesSpecific symbols, function signatures, imports, or behavior to extract from the numbered files.
file_pathsYesList of relative or absolute file paths to inspect on disk (skips binary files and `.env*` secrets).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.2.1
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / cwd / description
      Previous value: -"Optional working directory (defaults to workspace root)."New value: +"Optional working directory path (defaults to workspace root)."
    • changedInput schema / properties / file_paths / description
      Previous value: -"List of relative or absolute file paths to inspect on disk."New value: +"List of relative or absolute file paths to inspect on disk (skips binary files and `.env*` secrets)."
    • addedInput schema / properties / file_paths / minItems
      Added value: +1
    • changedInput schema / properties / query / description
      Previous value: -"Specific symbols, control flow, signatures, or architectural questions to extract from the files."New value: +"Specific symbols, function signatures, imports, or behavior to extract from the numbered files."
    • addedInput schema / properties / query / minLength
      Added value: +1
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, yet the description still adds real behavior: zero cloud quota consumption, a hard <300 token output cap, a NOT_FOUND_ON_DISK sentinel for missing symbols, and automatic escalation to a cloud model when the local GPU is offline. The remaining gap is the vague 'telemetry footer' it promises without explaining.

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?

Structured as WHEN TO USE / DO NOT USE FOR / RETURNS with the core identifier front-loaded, and nearly every clause carries operational information. It loses a point for shouting caps and branding ('ZERO-TRUST MEMORY TOOL', '0x cloud quota') that adds emphasis rather than new meaning.

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?

There is no output schema, so the RETURNS section properly compensates with the digest format, citation style, and the failure sentinel. Minor omissions remain: behavior with multiple file_paths, and what happens when a path itself does not exist versus when a symbol is absent.

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 schema already documents cwd, query, and file_paths fully — baseline 3 applies. The description only marginally extends this, tying 'query' to the NOT_FOUND_ON_DISK sentinel and reiterating the file-type exclusions that the schema already states.

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?

States a concrete verb and resource ('Read repository files directly from disk') plus the processing model (local GPU LLM as forensic extractor) and the exact output shape ('verbatim signatures, imports, and logic with exact 1-based <file>:L<line> citations'). It also names its boundary against the sibling 'agy_delegate_research', so an agent can distinguish it without opening any 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 WHEN TO USE ('always call before raw Read on unfamiliar/large files (>150 lines) or whenever verifying disk state') and explicit DO NOT USE FOR ('multi-directory architectural synthesis across 10+ files (use agy_delegate_research after scouting)'). Both the positive trigger and the hand-off alternative are named, leaving nothing to inference.

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